Custom Roles not tracking

[lukecarbis]

To replicate:

1. Create a custom user role (any plugin should do)
2. Activate the User Switching plugin (https://wordpress.org/plugins/user-switching/)
3. Create and then switch to a user with custom role
4. Update post draft
5. Switch back to admin user
6. Update post draft again

You will only see entries for the admin user, not the user with a custom role. It seems as though custom roles aren't having any activity records logged.

Reported here: https://wordpress.org/support/topic/custom-roles-not-tracking?replies=4

[marcin-lawrowski]

I tried to reproduce this issue but no effect. I am using WP 4.4.2 and the newest Stream. I created a few custom roles and users for those roles. All activities of those users were properly tracked in Stream either with User Switching plugin or without it.

[marcin-lawrowski]

@lukecarbis Have you tried to replicate it?

[lukecarbis]

I just did, and I can't.

[lukecarbis]

@joelworsham Could there be something else going on here? Do you happen to have an object cache?

[joelworsham]

Yes, we use WP Engine, so there is some caching going on.

[lukecarbis]

Try clearing your object cache. I think the problem is that you're creating a new role, but the object cache isn't cleared. When Stream tries to get the user's role, and unknown role is returned, which results in a silent fail. Not ideal, but can you test by:

1. Create a new role
2. Try logging activities in that role (and see that they don't log)
3. Clearing your cache
4. Try logging activities in that role again

[joelworsham]

Hmmm I tried that and it still does not work. I've recorded a screencast just so you can see it with your own 👀

https://www.dropbox.com/s/3oquayjpm4ghpgo/Stream%20Custom%20Roles%20Example%20-%203-22-16.mov?dl=0

NOTE: If you look closely, it may seem like I'm purging the wrong URI, but that's just how WP Engine works, purging from the live side of the server. It does purge the staging server as well.

[lukecarbis]

Thanks for helping us try to get to the bottom of this, Joel. I can't replicate the same thing on my end at all. Maybe could you post the code you're using to create the user role in a gist? I'll try out the same role with the same capabilities, etc. and see if I can replicate it that way.

[joelworsham]

Sure thing.

https://gist.github.com/joelworsham/f64990299e061aea9896

[tylerhcarter]

I know this has been tried already, but I have been unable to replicate it locally. I'm going to try it on a WP Engine site and see if I get better results.

[tylerhcarter]

Just for clarification, I am using the gist plugin code you've listed above and following the same instructions you've listed to create a user with the custom role, switch to the user, update a post, and switch back.

Upon switching, all the logging happens correctly, and actions are being logged as that user instead of as the admin user.

[tylerhcarter]

@joelworsham Could you see if this is unique to custom roles, or if it applies to all roles? For instance, if you switch to a user with a standard (Contributor, Editor, etc) roles are you getting the same problems?

If this is cache oriented, I would expect to see that it would work the same for both custom and standard roles. In which case, figuring out how to override the cache would be the most important element.

Sidenote: Apparently the free developer site I had attached to the WP Engine account expired. So I'm flying blind as far as working to figure out the problems as they apply to WP Engine. I'll see if they have any docs to help support us.

[tylerhcarter]

We gained access to a WP Engine test site, and I am not able to replicate your bug following the instructions you've provided using the plugin in your gist.

Is there any special caching related plugins you have @joelworsham?

[joelworsham]

It is on WP Engine, so yes there is some caching involved. We have object caching turned off though and most caching is done on the frontend though there is probably still some caching going on. No caching plugins though.

[lukecarbis]

@joelworsham Maybe you could provide a list of plugins which are active on your site?

[joelworsham]

Sure thing.

regenerate thumbnails
stream
wp seo
vaultpress
query monitor
gravityforms
cpt alert
cpt animal
cpt attraction
cpt campaign
cpt event
cpt press release
cpt rental
cpt vendor
dzs alert frontend access
dzs conditional widgets
dzs google analytics
dzs import
dzs roles
dzs slider
dzs help
dzs zfeed
dzs quick info box

All prefixed cpt are custom plugins that simply add new custom post types
All prefixed dzs are custom plugins to achieve various things on the site

[lukecarbis]

@Chacha Would you be available to test this out?

[tylerhcarter]

Attempted again to replicate the issue.

Using the DZS Roles Plugin, I did the following:

1. Created a new user under the Site Manager role.
2. Switched to the new user.
3. Edited a post and saved.
4. Switched back to the administrator.
5. Looked at the Stream log.

Couldn't find any problems. The edit was attributed to the new user.

[joelworsham]

Man... I'm not sure what's going on then. This is absolutely bizarre. I just tested again but found something odd.

I tested logged in with a user with the "Communications Editor" role, and it did not work. Nothing was tracked when editing a post.

I then did the same test but after switching that user's role to "Site Manager" and it did work. It tracked it.

Can you try this test out with the "Communications Editor" role and see if it tracks for you?

[joelworsham]

Hey guys. I know this is low-priority to you, as you can't replicate it. I get that (being a developer myself). I do want to assure you it is happening though and I'm fairly confident it is not due to a weird conflict.

Perhaps it's the combination of stuff. But like I said, I noticed it is not working with the "Communications Editor" role.

[lukecarbis]

@joelworsham I'll look into this again today.

[rheinardkorf]

@joelworsham I had a look at this issue for you too. The answer is a bit odd!

WordPress is truncating the user role id, communications_editor to 20 characters, which is communications_edito, it then matches the original array with the newly altered array and if they don't match, it returns a false data object in which case the database does not record the entry.

The reason we were not able to reproduce the issue earlier was because we were likely using user roles with ID's of 20 or less characters.

Now that we know what the issue is we can start thinking about how to solve it.

Thank you for your patience!

Cheers,
Rheinard

Update: The Stream database limits user roles to 20 characters. We will need to increase the column sizes in the database to resolve your issue.

[joelworsham]

Thanks so much! I'm glad we were able to get to the bottom of this. You guys rock.