WP-Members version 3.3.8 has been released and it has a number of improvements that I am really excited about.
I want to first point out that this update does upgrade the plugin’s database version, so there are some db changes (although minor). They should not affect rollback, though. The new settings would simply be ignored if you rolled back to an earlier version.
New Features/Updates
Email Confirmation Link feature setting
This setting received a round of changes. First, there previously had been a custom user meta key used to store the activation key. Based on user feedback and support troubleshooting after the initial rollout, I decided to change it to utilize the WP user_activation_key field. This should allow for broader compatibility when other applications are in use that might also use that field for the same purpose. It also makes it easier to locate the user (more on this later, as it involves the some of the same changes and improvements to the password reset process).
Also, the process previously used the moderated registration user approved email to send to the user when they confirmed their email via the validation link. But as it turns out, that email doesn’t show up as an editable email when moderated registration is not enabled. If you wanted to customize the email content, you had to activate moderated registration, edit the email, and then deactivate moderated registration. Not exactly user friendly.
So I added a completely new email for use in this process. It will show up in the Emails tab if the Confirmation Link setting is enabled. So if you use this setting, you’ll have the initial registration email that goes out to the user when they register. This will automatically include the confirmation link, or you can customize the content and apply the [confirm_link] shortcode to place the confirmation link into the email where you want it (otherwise, it will be appended to the end of the email by default).
Additionally, this is one of those “you asked, we listened” kind of updates. When the email confirmation feature setting was originally added to the plugin, there were a lot of people that wanted to use that with moderated registration. As initially released, this was not possible – it was an “either/or” kind of setup. That has been taken into consideration and this version provides a user flow to use both.
If you want to use both email confirmation AND moderated registration, the flow goes like this:
- User registers, receives initial email (you can customize if you want). Initial email contains email validation link they need to act on (you may want to customize the registration success message in the Dialogs tab to indicate this).
- User confirms email, receives email confirming this. You can customize this email in the Emails tab, and may wish to include information that their account is now pending approval by an admin.
- If admin notification is enabled, the admin will receive notification AFTER the user completes the email confirmation.
- Admin approves the account, welcome email is sent to the user indicating the account is approved.
Also, if you have users that you want to manually confirm, I’ve added a hover-link in the Users > All Users screen to mark a user as “confirmed”. Confirmed users can be marked “unconfirmed” if necessary.
The next version of the plugin will expand on this and add confirmation to the bulk action menu (just like “activation” is now) as well as the ability to resend a confirmation email to the user.
Password Reset Link feature setting
Similar to the email confirmation setting, the Password Reset Link setting received an overhaul. It seems that in some cases, most of which seem to involve object cacheing, there were issues with the password reset link indicating it was expired. All of the support cases I reviewed indicating this issue involved object caching of the reset key. With the reset key being cached, multiple users would have the same key set and so when we queried by reset key, the wrong user would be retrieved and it didn’t match the reset of the validation process.
I completely overhauled the process to use WP’s user_activation_key field as well as the core WP functions for setting, querying, and validating that information. That has worked on all of the sites that I worked through support with, so it seems to fully resolve the previous problems.
New Feature settings for WooCommerce
A couple of new “feature” settings have been added for when WooCommerce is enabled. Let me remind everyone that the items in the “feature” settings are essentially new and are being worked in for full inclusion in the plugin for version 3.4.0. So some things may change as we work through support issues as these are introduced.
If you use WooCommerce with WP-Members (and many people do), quite often people want to integrate the two so they can add custom fields to the WooCommerce registration. This currently happens automatically.
But some situations have arisen where people have indicated that they do not want that. Up until now, they would have to remove those options by using “remove_action()” to remove the process that WP-Members uses to add the custom fields. This update includes a couple of simple checkbox settings to handle that.
The new settings will default to “on” just as the previous plugin versions did. If you need to remove the WP-Members fields from the WooCommerce registration either on the My Account form or registration during checkout, you can simply uncheck the appropriate setting in the Feature Settings section.
(One related note – WP-Members only adds custom fields to the checkout when it’s a new user who is not logged in. A logged in user just gets the billing/shipping fields you have enabled in WooCommerce. This is because the user is already registered.)
Users > All Users custom columns
There were a couple of updates to the custom columns you can add to the Users > All Users screen.
First, related to the email validation/confirmation setting, when that is enabled, you can know add a custom column for that. It will display the date the user confirmed. The date format will be the format used for WP (set in your WP general settings).
If moderated registration is enabled, and the “Active” column is added to the Users > All Users screen, previously it showed “No” for non-activated users and was blank for activated. This was so that the users needing activation stood out visually (rather than having something for every user). I’ve improved that to use WP’s dashicons, so a green check shows for activated users and a red X shows for non-active users. The column heading was also changed from “Active” to “Activated.”
It was brought to my attention that if you have applied a field to show as a custom column, and later you edit that field’s label text in the WP-Members Fields tab, the custom column text does not change unless you remove it from the custom columns in the Fields tab and then reapply it. This is because they use separate settings. So I have updated the process to use the current label text when the column is applied. Nothing you have to change, but wanted to let people know of this simple improvement.
Lastly, one thing that has come up from time-to-time is that in some situations, the field label may be some very long text (such as “Please indicate if you would like to receive our newsletter”) that does not make for a very useable column heading. You could filter this using WP’s filter hooks that fire during the process (which is how WP-Members gets them in there to begin with), but to make it easier, I ‘ve added the “wpmem_user_columns” filter hook, which will allow you to filter the array of just WP-Members custom columns. They will be in the array keyed by the field’s meta key with the value being the defined label from WP-Members Fields. You can use the filter to change this to something shorter (such as “Newsletter” if sticking with the example above).
Other Improvements
When the WP-Members registration process runs wp_insert_user(), the resulting $user object is captured to be able to send to the wpmem_register_redirect action hook. Previously, this was run at the default priority of “10”. This update moves it to “20” (running later), so that a custom redirect that does not apply a priority will run first.
The plugin’s default folder for uploads in the /wp-content/uploads/ directory is “/wpmembers/”. But you can now filter that to create and use a custom directory. The existing “wpmem_user_upload_dir” filter allows you to filter the “wpmem_dir” value, which is now in the core object as $wpmem->upload_base (and can be changed when the wpmem_settings_loaded action is fired). I’ll look at expanding this in the future to allow more flexibility.
Related to the above update, there had been an open issue for users on multisite that also incorporated file or image field types. The number of users effected were minimal, and actually, the root cause that I assumed to be something in WP-Members had never been specifically tracked down — until now! And it turns out it was NOT WP-Members at fault, but a flaw in WP multisite that adds the site to the URL twice. As far as WP-Members is concerned, this only is an issue for displaying the file in the user’s profile – not with the actual upload (which goes to the correct path). This update grabs the URL from the GUID value for the post attachment, which should resolve the problem, even when the file is updated.