WP-Members 3.1 contains some long awaited features, some fixes, and some improvements.
There are no changes to the database with this update so if you are currently at 3.0 or higher, you should be able to roll back without difficulty. (If you are using a version earlier than 3.0, there are changes from 2.x to 3.x that will be implemented in this update that would affect rolling back to 2.x. If that’s the case for you, you should test the update on a development system prior to upgrading.)
This version is currently available on GitHub as version 3.0.10. There will be no official 3.0.10 release on wordpress.org – this is merely a transitional release tag for building and testing leading into the official 3.1.0 release. The 3.0.10 is packaged and available for testing. The full production release of 3.1.0 will be available soon.
Here is a list of new features, improvements, and fixes:
New Features
New Field Types
WP-Members 3.1 will begin the process of some major updates to the form fields. This begins in this version with the addition of a number of field types:
- Radio Group
- Multiple Select
- Multiple Checkbox
- Image Upload
- File Upload
Also, HTML 5 field attributes are better supported, including the required field attribute, as well as some field types (email and url).
IMPORTANT: Some of you use CSS float properties in the forms to do side-by-side layout. Radio Groups and Multiple Select/Checkbox fields will need special attention to the label height for that particular field to get the layout right (basically, you’ll need to manually set this in a custom stylesheet depending on how many selections there are, and thus how high the section is compared to the label). This isn’t a problem if those fields are not used or if the float property is not used. Future versions will probably shift to wrapping the entire row with a div, but I’m holding off on that as that would likely break a number of custom filters that people use on the forms (if they haven’t updated in awhile). This isn’t a big deal – but it does require some effort for implementation and I’d like to avoid people indicating the version is “broken” in the wordpress.org repository when in fact it is not.
New Admin API Class
This version introduces what will become a new API for the admin. Custom admin features can currently be added via custom tabs, but this new API will expand on that. One of the initial features is the ability to hook into the Emails tab to add custom emails for different purposes. This will be utilized by the various extensions available as well as some tutorials on the support site.
Translation Strings
In a process that will hopefully make things easier for translators, I have moved all of the user facing strings into one place in the main WP_Members object class. So all strings that are part of the front end of the plugin will be here. I know this takes them out of context, but my plan going forward is to add some additional documentation for this so that everything is in one place along with an explanation for context. Hopefully this will make translating easier as well as making it easier to maintain existing translations.
As part of this process, I added the field labels for the fields that the plugin installs by default. These had been included in the main translation template even though the string was not specifically in the plugin. Along the way, some of the templates lost this information and with the new pot template being generated automatically for the wordpress.org translation project, these were not getting properly included. So I added them here to be picked up by the pot generator.
In addition, there is a new filter hook, wpmem_default_text_strings, with this part of the object so that custom strings could be added or existing strings could be filtered as needed. I don’t see that being used a lot, but since I was in there, adding a hook here wasn’t a bid deal.
Filter Updates
Along with the new wpmem_default_text_strings filter mentioned above, I added a new filter for the sidebar status, wpmem_sidebar_status_args, which adds the ability to filter specific items in the sidebar logged in status message more like the main body filters do without needing to filter and rewrite the entire string of HTML.
The wpmem_email_filter received an additional parameter in the default array to contain information for the default email footer.
The wpmem_{$page}_links_args filters received an additional parameter for “after_wrapper” (opposite of the existing “before_wrapper”). This is for wpmem_login_links_args, wpmem_register_links_args, and wpmem_member_links_args.
Added “values” key to the wpmem_register_form_rows filter to hold the possible values for a field. This is used by select fields (regular dropdown and multiple), multiple checkbox, and radio groups. Previously, this information was passed in the “value” key. For all other fields, the “value” key contained the field’s set value. For dropdowns, the set value wasn’t available in the filter as the “value” key contained the array of possible values. This new key corrects that so that for the aforementioned field types, the “value” key contains the selected value of the field just like all the other fields and if the possible selections are needed, they will be in the “values” key.
Speaking of wpmem_register_form_rows, I added two new filters for the backend user profile – wpmem_register_form_rows_profile (the user profile) and wpmem_register_form_rows_admin (the admin version of the user profile). There were already filters in these locations, but they lacked the flexibility of what is now available on the front end. The old filters just contain the entire block of HTML for the extra fields section. These new filters are a filterable array of rows, like wpmem_register_form_rows. And the arrays match up so that in many cases, if you filter the registration form, you may be able to apply the same filter to the backend fields.
Code Improvements
This version continues the process of general code cleanup with some review of inline documentation and comments.
The email functions were improved by adding a new container to the main WP_Members object for the email from and email from name settings. These are no longer separately maintained items and will be contained in the $wpmem object. This will make the process work smoother and hopefully avoid some of the general email issues by making sure that a default from address or custom from address is included in the email header.
Use of wpmem_chk_qstr() was deprecated to use the WP function add_query_arg(). wpmem_chk_qstr() dates back to the very early versions of the plugin when there was no specifically documented way for the plugin to add proper query strings to a URL. If permalinks were used, the process needed to be different. But add_query_arg() makes this process much more scalable and improves the plugin for use on multi-language sites (and other situations) where other plugins may be adding query arguments as well.
WP 4.5 will deprecate the use of get_currentuserinfo() to use wp_get_current_user(). WP-Members 3.1 makes this change as well.
The main action for the plugin is handled by the method get_action(). This has always been hooked to WP’s init action. WP-Members 3.1 moves this to the template_redirect action, which comes later. The reason for this change is that a lot of the plugin’s functions that run based on the action being handled (logging in, registration, etc) need to take place early in page execution before headers are sent (for setting cookies, etc), but many of the filter and action hooks in those processes can benefit from knowing the current page or other information from WP that is not generated at init, but is generated by the time it gets to template_redirect (such as the $post object). Moving the execution of get_action() from init to template_redirect should make certain WP-Members filters and actions even more flexible and it should have no affect on the plugin operation itself.
The kubrick stylesheet was removed as an option, but the stylesheet will remain in the download for those that already use it.
Fixes
There are always things to be fixed along the way, and 3.1 is not exception. Most of these are fairly minor and are either just small annoyances that could be improved or only show up in certain situations. A couple (such as the redirects) fix things that just weren’t working as intended.
Fixed the sidebar redirect_to parameter in the widget settings.
Fixed the redirect parameter in the register form shortcode (although I also removed this option from the shortcode menu as many people seem to be setting this without really needing it – redirect should only be used when necessary, and there are better options than redirecting users).
Fixed custom error messages and the email comparison error for profile update so that errors show above the form update state rather than the user profile links page.
Fixed main options tab where checkbox may not display correct setting if unchecked.
Fixed translation issue for required field error where all of the message except the field name was translated (the entire string should translate now provided that both the error message and the field name have a translation).
Fixed confirm password field to bypass the sanitize_text_field that all text fields go through as a security measure. Passwords should not go through this and passing the confirm password through this, while fine if no special characters are used, caused a problem if secure password with special characters was entered – the two fields would not match.
Added logic so that the special user pages (login, register, user profile) are not blocked unintentionally. This had been the case under the old [[wp-members]] shortcode tag, but with the new [wpmem_form] tag, the pages needed to be marked as unblocked if pages were blocked by default. This fix corrects that and makes it function like it did with the old tag, thus preventing admin error when creating and setting these pages.
Changed username field name in the register form from “log” to “user_login” to match the WP native registration form. This will make the label ID correctly match the field. I don’t expect this fix to affect anyone’s filters, but if you are using an older filter on wpmem_register_form that looks for specific HTML in the username field label, you should check that your filter is updated for compatibility (or better yet, use wpmem_register_form_rows which is newer and more powerful).