User Role Editor will not update

I have exact the same problem. The capabilities seems to be updated after a save, but if you go to another screen and returns, al changes are lost. Very confusing.

Yes, as it is, this plugin is worse than useless.

The old Capability Manager plugins still works.

What WordPress version do you have? Is it single-site or multi-site? Do you edit roles or users? Did you tried to repeat the issue with others plugins deactivated? May be some conflict takes place…
Please give me exact scenario, what and where you edit. I need to repeat that at my test environment, in order to fix the issue. Problem could sit at your specific environment as with 300+ this plugin daily downloads I got a couple of bug messages only, yours.
If you have your own test environment where plugin doesn’t work or you could allow me to make test at your site, I’m ready to investigate an issue on place and make fix asap.

Thanks.

Thank you for replying.

Always latest WordPress, single site. The last time I encountered this problem was on IIS7 as server. I have usually used this plugin to create five new capabilities and four new user roles, combining one or two of the new capabilities with different core roles.

I always check with no other plugins active before reporting a problem.

For most of the role editing, the use is in my own plugin, that does a lot of capability checking.

Since you are here and want to fix this, I will very soon do some more testing, to reveal what makes it work and what makes it not. I will get back with the results soon.

Finally, I miss the ability to edit the Administrator role, at least for non-core capabilities.

I develop and make all tests just under Apache. So IIS could be the real subject. Good, I will wait additional information from you.

Administrator role is hidden by default for security reasons. At FAQ section you can find, that if you add the line
define('URE_SHOW_ADMIN_ROLE', 1);
to your wp-config.php, you will see ‘Administrator’ role at URE roles list.

Short notice: I don’t expect this to be server related. I have seen this on Apache, too. I have a lot of sites, both platforms, almost never any such issues, except when file operations are done assuming the plugins runs on Linux.

As noted here:

https://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.

OK, here’s a clue that answers a question above, and might also point out to you where a coding error might be found.

I can check or uncheck “activate_plugins” successfully, with the change retained across sessions.

I cannot successfully uncheck “delete_others_posts”, and have the change retained across sessions. This is true whether or not I also change “activate_plugins” at the same time.

I think this shows that: (1) the problem is not server-related, and (2) the problem is likely something different in the coding among different properties, that fails to set a changed flag. The changed flag doesn’t seem to be a master (global) changed flag, however, as that would be set by changing “activate_plugins”.

Vladimir: I’m hoping that this information will allow you to replicate the problem yourself, because problems go away fast when the programmer can see how to cause them. However, if you need more testing, please let me know.

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.

Thank you Knut, for your kind help in finding this critical bug, and for professional review of my code. It’s very-very useful.

I don’t use any caching plugin on my sites according to their not so large traffic. And it’s my big mistake. As caching technique is spread on WordPress sites widely, testing plugins during development with popular caching plugins together is important requirement.

I will make fast fix for the caching problem and will work more carefully on the whole code re-factoring, as, Yes, general code cleanup is needed, and will be done.

P.S. Thanks, Ceolmhor, for your report. It’s a real help too.

Please, try this updated version (quick fix):
https://shinephp.com/wp-content/downloads/wordpress/plugins/user-role-editor-dev.zip

Really you can take and replace at your URE installation just one file from this package:
ure-lib.php

I replaced direct database update with update_option() call from WordPress API. It should fix existed problem with WordPress data caching. It works for me with “W3 Total Cache” plugin activated.

Thank you for the quick fix on the caching problem.

Don’t forget to increment the version when packing for distribution.

Try saving twice, and the bug I mentioned is still there.

When URE_SHOW_ADMIN_ROLE is defined I can also edit the Administrator capabilities.

My advice is to check for such constants this way:

if ( defned( 'MY_CONSTANT' ) && MY_CONSTANT )

This will work correctly and logically even if a constant is defined and false (off) or when defined as true (on). It also handles the case when MY_CONSTANT == '' (defined, but not true) or MY_CONSTANT == 'foo' (defined and true).

I will also not recommend checking for WP_DEBUG as this is global, for core debugging, and are meant for PHP errors/warnings. Define your own constant URE_DEBUG in the main plugin file, at top. When it is undefined or evaluates to false, the debug output is off.

Just a tip: To make better readable code, for the planned overhaul, follow WordPress coding standards, especially intendation with tabs. You may (should) omit braces for one-line conditionals. Nobody follows all the rules, me included, but it’s a fine standard to have in mind for making cooperation easier among programmers on this WP planet.

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.

Ceolmhor: To find out if there is a caching problem, you could display the values got through the WordPress API with the values fetched directly from the database. Add these two lines i ure-lib.php, just above the return statement of the ure_getUserRoles functon:

echo 'API: <pre>'; var_dump( $ure_roles ) ; echo '</pre>';
global $wpdb; echo 'DB: <pre>'; var_dump( unserialize( $wpdb->get_var("SELECT option_value FROM $wpdb->options WHERE option_name='{$wpdb->prefix}user_roles'") ) ) ; echo '</pre>';

Visit the User Role Editr page and examene he output. Look at the values below ["editor"]=>

If they are the same, no caching problem. If they are different it’s probably caching related. This about what I did to find the problem I had. Your problem is slightly different, it seems.

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.

Thanks for your experiments, Ceolmhor.
I will try to repeat your investigation about fields values type this evening.