Changing any WordPress user's role resets all Edit Flow user group memberships

[danls]

I set up a new user, User A, with a 'Contributor' role. Then added 2 preexisting editors to one user group and 2 different editors to another user group. I then changed User A's role to 'Author'. A check of Edit Flow's user groups at this point shows that the groups have forgotten their members and now show as having 0 members.

If I duplicate the situation, the same bug presents. It seems to occur no matter what level user's role you change or which role you change them to. A role change on any user erases the membership lists of all user groups (creating or deleting a user does not).

[cojennin]

I haven't been able to reproduce this bug. I've tried the following scenarios, please tell me if I'm attempting to recreate it incorrectly:
First scenario

1. Set up two users, ed1 and ed2, placed them in the editors user group
2. Set up two users, auth1 and auth2, placed them in the authors user group
3. Set up a user, contr1, did not place in group
4. Changed contr1 role to Author
   This did not trip the bug

Second Scenario

1. See step 1 of first scenario
2. See step 2 of first scenario
3. Set up a user, contr2, placed in reporters user group
4. Changed contr2 role to Author
   This did not trip the bug

Is there another scenario that should be tested?

[danielbachhuber]

worksforme

[danielbachhuber]

Reported again in the forums. I'm going to write unit tests for user groups to see if I can catch the edge case where this is happening.

[karucifer]

Two years later, this is still happening for customers. Has Edit Flow been abandoned? A heads-up would be nice so that we can start looking for alternatives...

Happy to provide access to our staging copy to observe this bug if it means a fix, but no activity since Jan suggests that we're on our own here...

[AramZS]

@karucifer Curiosity: have you or a plugin you are running altered the permissions associated with any of the standard WordPress roles? I've found that causes issues like this in other plugins.

[karucifer]

I can reproduce this 100% of the time by simply changing passwords via /wp-admin/user-edit.php

I've also tested it on a fresh install with only Edit Flow present. Each time all user group memberships are eradicated. The only plugin we use that touches users is Force Strong Passwords, mandated by WPEngine.

As I said, happy to offer access to our environment if others want to replicate.

[pixeldynamo]

This issue breaks one of the key features for us, are there any workarounds?

[flacoman91]

@karucifer and @pixeldynamo I am also experiencing this on a production server from one of my clients, but it's not a standard Wordpress install. Our setup has some sort of load balancer in front of it and redirects traffic based on different urls.

We are also using WP Engine. I can't reproduce this locally or on a staging server that has a simple Wordpress install.

Can I get some info about your environments? That may help narrow down what our common factors are that would cause this to break.

[pixeldynamo]

Also a WPEngine customer, although we've replicated it in our staging and Dev installs which don't include any of the varnish/nginx stuff that WPE does.

[flacoman91]

@pixeldynamo thanks! I figured out what is causing the issue.

WP Engine's object cache is causing the problem. If we disable it, user groups don't get blown away.
I'm not sure if there is a way Edit Flow can code around this or it's WP Engine issue that needs to be fixed on their end.

I made a screencast to demonstrate this. It's a brand new site spun up on wp engine with only the edit flow plugin enabled.

https://www.youtube.com/watch?v=jFGN2lJhyLg&feature=youtu.be

edit: You don't even have to make any changes to a user to make the user groups empty. All you have to do is click Save Changes on a user profile page.

[pixeldynamo]

There hasn't been an update to Edit Flow for over a year. I'm not sure about the particulars of the license but automattic appears to be developing it behind closed doors now for WordPress VIP.

Our only hope/option is for WPEngine to implement some kind of fix.

On 2 Jun 2015 18:34 -0700, Richard Dinhnotifications@github.com, wrote:

@pixeldynamo(https://github.com/pixeldynamo)thanks! I figured out what is causing the issue.

WP Engine's object cache is causing the problem. If we disable it, user groups don't get blown away.

I'm not sure if there is a way Edit Flow can code around this or it's WP Engine issue that needs to be fixed on their end.

I made a screencast to demonstrate this. It's a brand new site spun up on wp engine with only the edit flow plugin enabled.

https://www.youtube.com/watch?v=jFGN2lJhyLg&feature=youtu.be

—
Reply to this email directly orview it on GitHub(#116 (comment)).

[joshbetz]

Hey @pixeldynamo. Nothing is happening behind closed doors :). There have been updates, though no official releases on the WordPress.org repo. If you want to submit a pull request for this, we'll be more than happy to review for merge.

[flacoman91]

I've opened a ticket on WP Engine to see what they have to say and I'll update when I get a response.

[jeffwecan]

I believe the source of this issue is strictly object caching related and not tied to a particular host. However @pixeldynamo's mention of this issue not occurring in WP Engine's staging environment (which doesn't have object caching included) may be the result of some other behavior that isn't captured in my noted here below.

The suspicion of object caching being responsible is based on the following:

• The affected plugin settings are stored in the wp_term_taxonomy table
• Data from this table is added to the object cache (when available) by the WordPress core as shown in line 1433 of the taxonomy.php code:

$ cat -n wp-includes/taxonomy.php | sed -n '1404,1455p'
  1404  function get_term_by($field, $value, $taxonomy, $output = OBJECT, $filter = 'raw') {
  1405      global $wpdb;
[...]
  1429      $term = $wpdb->get_row( $wpdb->prepare( "SELECT t.*, tt.* FROM $wpdb->terms AS t INNER JOIN $wpdb->term_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy = %s AND $field = %s LIMIT 1", $taxonomy, $value ) );
  1430      if ( ! $term )
  1431          return false;
  1432
  1433      wp_cache_add( $term->term_id, $term, $taxonomy );

The source of the compatibility issue with object caching appears to ultimately reside in the following code in the plugin's wp-content/plugins/edit-flow/common/php/class-module.php script:

$ cat -n wp-content/plugins/edit-flow/modules/user-groups/user-groups.php | sed -n '831,845p'
   831      function get_usergroup_by( $field, $value ) {
   832          $usergroup = get_term_by( $field, $value, self::taxonomy_key );
   833
   834          if ( !$usergroup || is_wp_error( $usergroup ) )
   835              return $usergroup;
   836
   837          // We're using an encoded description field to store extra values
   838          // Declare $user_ids ahead of time just in case it's empty
   839          $usergroup->user_ids = array();
   840          $unencoded_description = $this->get_unencoded_description( $usergroup->description );
   841          if ( is_array( $unencoded_description ) ) {
   842              foreach( $unencoded_description as $key => $value ) {
   843                  $usergroup->$key = $value;
   844              }
   845          }

The plugin's user group allocation data (in a base64_encoded + serialized form) is kept in the wp_term_taxonomy database table. WordPress will add the results of the get_term_by call in line 832 to the object cache. Consequently the Edit Flow plugin is receiving stale data and then updating all groups with that stale data as part of a user profile update.

I was able to resolve the issue in my testing by adding the following line above this function call:

$ cat -b wp-content/plugins/edit-flow/modules/user-groups/user-groups.php | sed -n '831,833p'
   831      function get_usergroup_by( $field, $value ) {
   832          wp_cache_flush();
   833          $usergroup = get_term_by( $field, $value, self::taxonomy_key );

Though a more robust option would be to find the relevant term id and instead use wp_cache_delete($id, self::taxonomy_key) to selectively delete only the pertinent set of data.

[flacoman91]

Thanks. I just wanted to give kudos to @futuernorn from WP Engine support for being quick to respond and find a solution.

[pyronaur]

Hello everyone 👋
Is this still an issue in 2018 or has it been fixed with core updates (with WordPress term splitting update) or internally at WPEngine?

[rinatkhaziev]

@jeffwecan's explanation is very plausible.

However, there were changes to get_term_by() it doesn't cache results on its own, caching part was moved to WP_Term::get_instance()

I tried to reproduce steps shown in the video locally but couldn't, and looks like the issue was/is isolated to WPEngine.

This issue is very old and without the means to reproduce it, as a part of our maintenance effort I have to close it.

In case this is still happening on WPEngine, or anywhere else, please open a new issue mentioning this one.