The release of WP-Members 3.3.0 was a major event, but it went very smoothly considering the massive changes that were included. As of today, all reported bugs and issues related to 3.3.0 have been addressed and fixed in the various patch releases and/or version 3.3.1 that was released last night.
Most of 3.3.1 was also fixes, all of which are noted below:
- Added empty /inc/dialogs.php file to allow for backwards compatibility with certain custom code snippets and, more importantly, older versions of some of the plugin’s premium extensions.
- Updated user profile screen handling that previously disallowed admins (or users with “edit_users” capability) to edit membership access on their own profile. This was because the profile edit screen is the same for all users (admins and users alike), and general users cannot (for obvious reasons) edit these settings. The screen has been retooled to allow for edit_users capability users to make these edits on the profile screen. (Note: this is not to be confused with the user_edit.php screen. There are not reported issues there.)
- Fixed a bug that caused the activation checkbox for a new user to display as “Reactivate” instead of “Activate”. Functionally, there was no issue. This was just a confusing text display bug.
- Fixed a bug in the membership renewal process that caused the individual date meta to move forward two periods instead of one. This was due to a logic error. The legacy process for storing dates was left in for backward compatibility. But the new value type was added just after and used the same variable name. Because the variable was not reset, the date it was working on was the date that was already moved forward for the legacy value, resulting in adding a second period. This is now fixed, along with some other date improvements that are noted separately below.
- Fixed a bug in the hidden fields lookup that cased hidden posts with a membership restriction to result in a 404 (not found) error for users who did have a matching membership.
Expiration date improvements
In addition to fixing the renewal date issue mentioned in the bug fixes, there was an improvement to the expiration date process along with a new feature.
The renewal process for expiration dates actually set the date from the original expiration regardless of whether the user’s expiration date had passed or not. For example, if today is 1/14/2020 and the user expires 1/30/2020, a 1 year renewal would be 1/30/2021. However, if today was 2/10/2020, a renewal on that day would the same result (1/30/2021), not 2/10/2020.
For the default, the intention is to use “gap” renewal. This is because if the user is expired, they do not have access to the site during the time they are expired. They would receive an expired notice when accessing restricted content and would be encouraged to renew. The default in the related PayPal extension is to allow this gap due to the fact that the user does not have access during the expired period.
So the renewal logic was updated to incorporate this change as the default:
- If the user renews and has not expired, the new date will be one period added to the original expiration.
- If the user renews and has expired, the new date will be one period from the current date.
The new feature is that I’m including an option for “no gap” renewals. I know that not everyone uses the plugin for the same purposes and there are use cases where things are used where no gap in the date is allowed. This is something that has been discussed by users of the PayPal extension, so I’m familiar with the scenarios where this is preferred. It’s especially useful for users who maintain “offline” membership where if the user doesn’t renew online, they are not necessarily restricted from access to whatever the membership is.
The basis of “no gap” renewals is what was described as the unintended default above – the user’s renewal is always set from their current expiration date, regardless of whether the expiration is in the future or the past.
This option is at the membership level, so it can be used for some memberships but not others, depending on the need of the plugin user. To enable “no gap” renewals, check associated checkbox when setting the membership’s expiration period.
Menu feature improvement
Plugin version 3.3.0 had added something to the menus that I’ve wanted to do for a long time – allow individual menu items to be managed based on login state and/or membership access individually. To do so, I wrote a custom “walker” class, which is the only way add these kinds of customizations.
Unfortunately, in doing so, I was unaware that a lot of you already use themes or plugins that do something similar or related already. And (also unfortunately), a custom walker for the menu admin is much like The Highlander – “there can be only one!”
In my walker, I had used a custom action hook with the “wpmem_” stem since… well… it’s custom, and that’s the correct way to do it. But I was also unware (seems there’s a lot of unwareness in this) that there was a movement afoot to implement a standard non-standard official unofficial action hook where there really should be one. In other words, a bunch of the developers who have applied a menu customization using a custom walker got together and all decided to use the same action hook name – “wp_nav_menu_item_custom_fields”. It has the “official” wp_ stem so while it would appear to be an official WP action hook, it is not. These developers are all using is so that their products play nice with other products, and in the process they are lobbying for an official action hook where there really should be one to avoid this entire mess.
I totally agree with them, and if I’d been aware of that prior to 3.3.0’s release, I would have used that hook name instead of the “wpmem_” one that I originally used. But, that’s what updates are for, right? So 3.3.1 shifts to use the “wp_nav_menu_item_custom_fields” action hook.
What does that mean for you? Do you have to change anything? Nope! It’s all just a full explanation of the “what happened and why” kind of thing. All you need to do is upgrade.
Now, keep in mind, that just means the plugin shouldn’t break any functionality for how these themes/plugins add settings to the menus. That does NOT mean the same thing as “it’s compatible with the other theme/plugin’s features. For example, in my testing, I looked at the “Nav Menu Roles” plugin. This also has logged in/logged out settings. If you use both (which you can), the settings would need to be equal as each plugin evaluates its own settings, not the settings of the other plugin. So if you set one to logged in and one to logged out, you’re going to get screwy results. Hope that makes sense to everyone – I’m not sure there’s a better way to explain it.