WP-Members 3.3.6 is a bug fix release correcting a few key issues.
WP-Members custom fields in “back end” profile
The “back end” profile view has two different states that WP-Members is concerned with – one that is viewed by admins (or more technically, those with edit_users capability) and the view that is displayed to general users. Somewhere along the line in the last few updates, the “admin only” view of custom fields (leaving “display” unchecked in the field properties) became broken. How broken depends on a few other things, but it primarily was an issue of how fields were handled for view in the form and in validating the submitted form.
This is now fixed and is actually a more simplified process.
Fixed undefined has_access() function
This bug only affects users who are also using WooCommerce, and then only in the renewal state of a membership. The function call was assuming the incorrect object class. This has been fixed in 3.3.6.
WooCommerce registration integration
I had a number of people report an issue with WooCommerce registration, and it stems primarily from some confusion on field meta keys and what keys belong to what plugin. Since so many more users are integrating WP-Members with WooCommerce, this was an important and necessary fix and this is the reason this update is coming out so quickly. It’s only really a “bug” if you use BOTH WP-Members registration AND WooCommerce registration AND have first/last name set as required. (All other cases that only use WooCommerce for registration it’s not really a “bug,” but more of an unclear setting issue).
Regardless of the cause, the problem arises when the WP first_name and last_name fields were set as required in WP-Members. These were then included in form validation when registering through WooCommerce (both the My Account registration and checkout registration).
In a few rare instances, there some other fields that were similarly problematic.
I did an overhaul of the way the various registrations (WP-Members, WP both wp-login.php and Users > Add New, and WooCommerce) to make sure that the fields that are displayed in the registration form are the same fields that are validated upon form submission so no extra field meta keys are in the validation.
This also led to tightening up some other custom field settings when using WooCommerce, such as some improved HTML in the form, and a few other tweaks to improve things.
BuddyPress integration with WP-Members moderated registration
Another fix was an issue that arises if BuddyPress is used with WP-Members moderated registration and the user is added manually. The activation state was not properly set. This was due to some changes in 3.3.0 that were intended to better integrate WP-Members’ registration with general WP processing so that the user_register hook could be more tightly integrated. But that change caused a problem with this particular integration. This is now fixed in 3.3.6.
Other fixes
I improved the admin panel for CAPTCHA settings since we rushed in the updates in 3.3.5.2 to include hCaptcha support. I added the ability to change the captcha type from the captcha tab. Previously, this had to be set only in the main Options tab, then you’d have to go back to the captcha tab to input settings (like your API key). I also corrected an issue where there could be an undefined index error with the hCaptcha when you initially switch over to it.
The WP CLI settings command was updated to correct an error that occurred when viewing content settings.
Lastly, the “pattern” attribute was removed from the “number” field type. The “pattern” attribute for all fields that it appears for is specifically an HTML5 input tag attribute, but this attribute is not part of the “number” input type in HTML5. So it never should have been shown for this field type in the WP-Members field settings. This came to my attention due to a user mentioning that he could not get his regex to work on the field, which would make sense since the number field does not validate a regex pattern (you would have to use a “text” input for this purpose). So this isn’t necessarily a “bug fix,” so much as it is avoiding confusion on an unsupported HTML5 attribute.
Get the update here: https://wordpress.org/plugins/wp-members/