WP-Members version 3.5.2 has been released with a number of bug fixes and improvements. Some of the bug fixes were reported by users, while a couple of others were bugs that no one noticed (or at least said anything about), but were found when testing the other bug fixes.
The code improvements came while I was working on debugging an exhausted memory issue for some users that I simply could not duplicate (at first). Once I figured out what that was, I was able to fix it, but some other code got improved along the way for a lighter overall plugin where possible.
I want to start off by thanking everyone who uses the plugin. This plugin was the first membership plugin for WordPress way back in 2005(?). I have been working heavily with WordPress for 21 years this year. It has been a lot of fun and there are users who have been with me for well over a decade. Old and new users alike – I thank you.
The 3.5.x release was a major upgrade with a lot of behind-the-scenes work being done. Anytime that happens, for a plugin that has a lot of configuration options and customization ability, a big update like that can come with some bugs. I work hard to squash every bug as quickly as possible while also keeping production updates to a necessary amount. I appreciate everyone’s patience through this period, but I think that here with 3.5.2, we have gotten to all the major bugs. Certainly, all of the reported bugs have been addressed, along with fixing some other things I found while searching out reported bugs. I encourage you all to update to 3.5.2. It is the most efficient version of the plugin for memory and system resources, and it is the most secure. If you were waiting to get through the bug process, then this is the one you need to update to.
For point of reference, here’s what we did in 3.5.0 and 3.5.1:
With that being said, here is what was addressed in 3.5.2:
Key Bug Fixes
- Fixes a bug in the WP_Members_Dialogs::get_text() for unknown keys (reconfirm_link_before & reconfirm_link). These were new keys that were added for a new feature in 3.5.0 that allows a user to request a resend of the confirmation link (if confirmation link is enabled and the user never confirmed before the link expired).
- Fixes a bug in the
Memberships
- Fixes a bug in the membership stack reading that caused an infinite loop (may or may not be a bug, depending on specific local install settings). Man… this one was annoying to find because it was not something reproduced on testing and took stepping through breakpoints in code on a system that had the error. I had only three people report a memory exhaustion specifically, and one other report of a mystery error with JSON and this was the problem.
Basically, the problem was the result of a misconfiguration of the child/parent relationship option in memberships. But that user misconfiguration exposed a possibility of creating an endless loop while trying to build the membership hierarchy stack, thus resulting in exhausted memory in PHP. Without getting into the gritty details that no one really cares about – the important thing is it is fixed.
Now, it was the result of a misconfiguration, so it should be noted that if you use memberships, and you create hierarchies where the users at higher levels have access to lower level content, then you do not need to enable the setting “Access by child membership”. In fact, it’s stricter than that – don’t enable it. That setting is for something else.
This is what that setting means – if you have a variable membership, such as a membership where you offer a monthly and annual subscription – you’re going to assign the expiration membership (monthly or annual) to the user, but the content will be restricted to the parent membership. Thus the user who has the monthly or annual membership will get to see the parent membership when they “access by child membership”. That’s what that setting is for. See the documentation on membership hierarchy that includes an explanation of this setting and when to use it. - Install/upgrade script bugs. There were a couple of problems here. First, transfer of any stylesheet setting other than the default was not being handled in a consistent manner, resulting sometimes in a loss of the setting. The changes in 3.5.0 were intended to make this option simpler, but in the 3.5.0 and 3.5.1 releases, it was anything but – it still had the same issues. This has been reworked and fixed. So this is how you use it: If you want the default, the custom CSS setting should remain blank. If you have a custom stylesheet, enter the full URL path. Upgrading from 3.4.9.7 and earlier should be fine. Upgrading 3.5.0 and 3.5.1 should be OK as well, but if not, blank the setting to get the default and report it as an issue.
The other major bug fix in the upgrade/install script was for new installs. Somehow, the “finalize” dialog box was not properly shutting off, causing some confusion on page reload. If it stayed and you went to another page, it did go away, but if you thought it didn’t register, you could potentially be sitting there submitting the form several times wondering why it was staying there. It was a bug and is now corrected.
Key Improvements
- There was an issue with WooCommerce fields for multiple checkbox and multiple select field types when users register in the WooCommerce checkout form. WooCommerce stores these as serialized data. But WP-Members has always expected delimited strings for this field type. So the user would register in WC checkout and it would appear in the profile (or profile update) as if these were blank.
Meta data handling has been improved so that we don’t have to change the data storage type. WP-Members will check the data when it retrieves it and handle the serialized data accordingly or if it is standard WP-Members delimited string format, it will handle that. Short story long, it’s fixed – or should be (users experiencing this have noted that it is fixed). - Improves all stored settings in terms of what autoloads and what does not. Previously, WP-Members left this as “auto” to have the default local handling decide. But when I was looking for the memory problem, I noticed that I just did not like the way it was in the past. So what I did was update all stored options for the plugin to either specifically autoload or not autoload. There are basically three settings that need to autoload – main settings, memberships, and any hidden posts. The rest of the settings don’t need to load unless needed. For example, you don’t need registration form fields to load every page, nor do you need email content to load every page, either. Those can load only when requested. That’s likely the way it was before, but depending on localized options in WP, that could vary, so I changed it to specifically only get what was necessary when it was needed and try to make the plugin a little lighter (it’s already pretty light).
- Related to the above, I audited what options were left behind on plugin uninstall and found a few transients and other possible settings that may be left behind (not in every situation, but some). I improved the uninstall to scrub anything that was previously missed. There’s nothing I hate worse than some plugin being uninstalled and leaving an autoloaded setting behind. I’ve always tried to make sure WP-Members isn’t one of those. This audit catches a few that were previously missed. This included some transients for custom user views in the Users > All Users screen. They weren’t autoloaded, but they still should be cleaned up when uninstall is run.
- Related to that, memberships were previously handled somewhat individually. In my quest to improve what the plugin loads, I added a setting to store the membership data in a single setting, thus eliminating the need to run get_posts() for the custom post type everytime a membership is needed. This single option storage is more efficient and will update when memberships are updated. It will self-heal if not found.
Other
There are always a few other things that get slipped in because I’ve got them on the dev list and they get added into the bug fix update because they’re ready to go. This time around, I added a WP CLI command in the plugin’s db utilities to check the size of general options that autoload. This isn’t specific to WP-Members, but it serves as a nice utility if needed. Another add is the wpmem_get_user_meta filter hook to handle data being returned from wpmem_get_user_meta() which is a wrapper in the plugin’s API for the get_user_meta() function.