WordPress.org

Ready to get started?Download WordPress

Forums

User Role Editor
[resolved] User Role Editor will not update (23 posts)

  1. gleu
    Member
    Posted 1 year ago #

    I just downloaded the newest version of User Role Editor today and it will not update. So I choose which options to allow my subscribers and when I click on update it appears to have saved. (It says it has). But then when I switch to edit another user and then come back to the one I already edited it, it has returned to the original (reset) version. So it's been basically useless. Please help!

    http://wordpress.org/extend/plugins/user-role-editor/

  2. Knut Sparhell
    Member
    Posted 1 year ago #

    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.

  3. Vladimir Garagulya
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  4. Knut Sparhell
    Member
    Posted 1 year ago #

    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.

  5. Vladimir Garagulya
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  6. Knut Sparhell
    Member
    Posted 1 year ago #

    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.

  7. Ceolmhor
    Member
    Posted 1 year ago #

    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.

  8. Ceolmhor
    Member
    Posted 1 year ago #

    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.

  9. Knut Sparhell
    Member
    Posted 1 year ago #

    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.

  10. Vladimir Garagulya
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  11. Vladimir Garagulya
    Member
    Plugin Author

    Posted 1 year ago #

    Please, try this updated version (quick fix):
    http://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.

  12. Knut Sparhell
    Member
    Posted 1 year ago #

    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.

  13. Ceolmhor
    Member
    Posted 1 year ago #

    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.

  14. Knut Sparhell
    Member
    Posted 1 year ago #

    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.

  15. Ceolmhor
    Member
    Posted 1 year ago #

    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.

  16. Vladimir Garagulya
    Member
    Plugin Author

    Posted 1 year ago #

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

  17. Knut Sparhell
    Member
    Posted 1 year ago #

    I see. This plugin will sett the capabilities value to (int) 1 instead of (bool) true as WordPress initially does. This change happen for alle capabilites for each role, once edited through this plugin. WordPress should not care, as it only checks the values "trueness" or "falseness" (any value casted to bool in PHP).

    Try changing the value 1 at the end of line 132 of ure-options.php to true.

    This should make this plugin more compatible with WordPress, but I'm not sure it will fix your problem. Yet.

  18. Vladimir Garagulya
    Member
    Plugin Author

    Posted 1 year ago #

    Thanks for feedback, Knut. I will take your suggestions into account.

  19. Vladimir Garagulya
    Member
    Plugin Author

    Posted 1 year ago #

    Updated version is available from this link:
    http://shinephp.com/wp-content/downloads/wordpress/plugins/user-role-editor-3.8b.zip
    I changed updated capabilities values from int 1 to bool in case it could help and to correspond to values WordPress uses. PHP uses 0 and 1 integers to operate with booleans and it should not be the reason of Ceolmhor's problem though.
    Ceolmhor, please try this version. One other thought, Ceolmhor, please, try to deactivate all other plugins and make test again. Will you have the same result?

    Other updates:
    - Bug with empty URE page after double saving is fixed;
    - If you see Administrator role, WordPress core capability are in read-only mode now;
    - WordPress core capabilities and custom (plugins or user created) capabilities are shown separately.

  20. Ceolmhor
    Member
    Posted 1 year ago #

    OK, I have good news for you, but not necessarily for me. My problem with URE is, indeed, an interaction with another plugin. I apologize for not being savvy enough to have figured this out before. I can successfully edit my Editor role into the exact set of capabilities that I want so long as I don't have All-in-One Event Calendar by Timely (ai1ec) enabled. If I have the Editor role in the condition I prefer, and then enable ai1ec and go look at the roles using URE, the Editor role is back in its default state, rather than in the state I created using URE. I'm guessing that this means ai1ec is fouling up the role settings, but of course I'm using URE to actually see those settings, so I suppose it's possible that the problem is an actual interaction. Ah, but I see how to test that. I'll be right back. :)

    Yes, indeed, it appears to be a simple problem with ai1ec alone. Here's my test. With ai1ec disabled, I used URE to edit my Editor role into the configuration I want. I verified that that setting was persistent by selecting Subscriber and returning to Editor. I then deactivated URE, activated ai1ec, deactivated ai1ec, activated URE, and selected the Editor role. The role properties had then be returned to the original WordPress default values, rather than my values.

    I'll be happy to go and report this to the ai1ec folks, but I would appreciate any help others here can give me that might help me deal with the issue. For example, is there a flaw in my logic, such that these two plugins might still be interacting even though the two presumably never ran at the same time? How are such interactions usually handled? Is this a situation in which Vladimir should take any role at all (communicating with the designers of ai1ec), or should I be the only one bringing it up to them? Etc.

  21. Vladimir Garagulya
    Member
    Plugin Author

    Posted 1 year ago #

    You are right. While, URE plugin shows you current state of WP roles and saves your changes to the WP database, some plugins redefine WP roles on the fly. "All-in-One Event Calendar" plugin is among them. It adds its own capabilities set to 'administrator', 'editor' and 'author' roles, every time you activate it (app/helper/class-ai1ec-app-helper.php, line 118), if admin role has not 'manage_ai1ec_feeds' capability included. From this point, having such plugin installed, you have not full control on your roles and caps already.
    I will investigate the subject further...

  22. Ceolmhor
    Member
    Posted 1 year ago #

    I've posted a message in the ai1ec support forum. I'll let you know what they say.

  23. Vladimir Garagulya
    Member
    Plugin Author

    Posted 1 year ago #

    I didn't find any additional issue in ai1ec code and I could not repeat your situation on my test site. I can modify Editor role back and forward as expected.

    Previous beta version have a critical bug. If you try to change Administrator role you will lose it, as disabled checkboxes doesn't send its data to the server. So I deleted that file from server.
    I do not disable checkboxes for Administrator role now. I do not allow to turn they off. It's done with little Javascript function.

    Latest Beta is available for download from this link:

    http://shinephp.com/wp-content/downloads/wordpress/plugins/user-role-editor-3.8b1.zip

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic