User Role Editor will not update

As noted here:

http://shinephp.com/community/topic/edited-role-changes-dont-take

I also have this problem. Now that I know others are having the problem, I’ll try to do a bit more testing and see if I can turn up any clues to the cause.

I have found the cause of this error. Just turn off persistent caching (rename or remove wp-content/object-cache.php, and/or deactivate the caching plugin you have). Then it works, almost as it should.

So why is caching breaking this plugin? Remember that WordPress core actively supports caching, it caches everything even if the cache is actually destroyed once the complete page is loaded, as is the case when no persistent caching is installed.

Every read operation is caching the read values, and every save operation is invalidating the actual cache data involved, in order to force WordPress to retrieve the data freshly from the database the next time the data is needed.

This plugin just saves the updated data to the database by a direct SQL query using SET. $wpdb does not now about caching, not intended to. This way do save WordPress data is not recommended, as it will not invalidate the relevant cache data. This plugin then retrieves the data (user roles) through the WP_Roles class. This class is WordPress core and it, of course, uses the caching mechanism. The result is that the old values are returned for a long time, not the values in the database. WordPress doesn’t know that “someone” has updated the values directly, bypassing the mechanisms of WordPress, and since WordPress has a fresh, valid, cached value, it uses it for populating the WP_Roles object when instantiated.

There are also several bad things about the programming techniques in this plugin, and I have found a few other distinct bugs, one here:

If $wpdb->query() returns 0 (rows affected), on update, the admin page content area becomes completely empty, because of a conditional return in this case. This will naturally happen if the query tries to update a row that already contains the set values. And this will happen when a user tries to re-save (submit) what he just have saved (no change). When there is an error the return value of a query === false, and then you may check for $wpdb->last_error.

Other problems, as I have looked into contributing code to fix this, are, for example, the extensive use of global variables instead of function parameters. It even declares globals (by keyword global) in the global context (outside functions). No need, no effect, and it just looks bad.

I strongly recommend the plugin authors to get a copy of the excellent book WordPress Plugin Development. It’s open here and now, in in almost daily use, right beside my computer, as I develop my (private) plugins. It’s all in there, the “dos” and “don’ts”.

Fix the code, up to standards, review some of the practices, and this will become a great, and very useful plugin.

The new ure-lib.php didn’t fix the problem for me. I still get exactly the behavior I last reported.

I have no caching plugin in my installation.

I find no object_cache.php in my wordpress installation, which is the current version. The file, cache.php, does appear to have object_cache functionality, according to its comments, but I cannot rename or remove it, as there are require_once references to it in WordPress.

The behavior I get (can check or uncheck activate_plugins, cannot uncheck delete_others_pages, all in the Editor role) seems to be very consistent, and I would be surprised if it’s just a random timing issue.

Let me know if there’s other testing I can do for you.

Knut,

This is very interesting. I added your trace output as suggested.

I chose Editor role, unchecked delete_others_pages, clicked Update and OK. Both of the trace array outputs showed delete_others_pages still set to True, but the display showed it unchecked.

I then chose Subscriber Role. At this point, both array outputs show Editor:delete_others_pages as False (i.e., no value is displayed).

I then chose Editor Role again, to see if the change persists. Both of the arrays continue to show Editor:delete_others_pages as False (no display), but the box for delete_others_pages is checked in the regular display.

Still playing, I unchecked a different field, delete_others_posts, clicked Update and OK. At this point, both trace arrays show Editor:delete_others_posts as true, and delete_others_pages as false (no display). However, the regular visual checkbox display still shows delete_others_pages as checked, and delete_others_posts as unchecked.

I chose Subscriber Role again. Both arrays now show Editor:delete_others_pages as true, and delete_others_posts as false.

I chose Editor Role again. Both arrays continue to show Editor:delete_others_pages as true, and delete_others_posts as false. However, the visual checkbox display now shows both fields as checked.

I was curious to look further at my suspicion that there’s something different about activate_plugins, a field which works correctly for me. So I checked activate_plugins, clicked Update and OK, and found that the field did not show as set in either array, but it was still set in the checkbox display.

I selected Subscriber, at which point Editor:activate_plugins was set in both arrays. I selected Editor, and found Editor:activate_plugins set in both arrays, and checked in the checkbox display.

There was a difference, however. When set, the activate_plugins field (which works correctly for me) has its value set to int(1), whereas the other two fields (which don’t work correctly for me) has the value bool(true).

Having noticed this, I looked at the array for other Editor field values that are set to int(1), instead of bool(true). I hypothesized that these fields would all work correctly for me, so that if I uncheck their values and do an update, their values will be correctly, and persistently, turned off.

I was able to perform this test for five fields (read, read_ai1ec_event, read_private_ai1ec_events, unfiltered_html, and upload_files), and they all behave correctly. I was unable to perform this test for edit_files, or all the levels (what are those, anyway?), because they were not displayed in the checkbox display.

So my belief is that all those fields whose “on” value is represented by int(1) are behaving correctly, and those whose “on” value is represented by bool(true) are not.