search

JoryHogeveen / view-admin-as

View the WordPress admin as a different role, switch between users, temporarily change your capabilities, set default screen settings for roles, manage your roles and capabilities.
https://wordpress.org/plugins/view-admin-as/
GNU General Public License v2.0
45 stars 4 forks source link

Dev #57

Closed pbiron closed 7 years ago

pbiron commented 7 years ago

The change you made did not fix the problem because the new WP_User you pass when applying user_has_cap had no roles...hence, the function I hook into user_has_cap didn't do the right thing since it has a if (in_array ('some_role', $user->roles)) check.

This change fixes that by adding roles from the "selectedUser" to the user created via new WP_User. Since you know your code much better than I do you might have a better way of doing that.

I've tested this fix with both the stripped down "test" plugin I sent you and the full private plugin I wrote that originally uncovered the issue.

Note: I'm new to this "pull request" thing. I'm not sure why, but this request includes the last 2 commits you made. I expected it to include only the commit I made in my fork. I'm sure you can reconcile that.

JoryHogeveen commented 7 years ago

Hi @pbiron, I already noticed this and removed these commits shortly after. The reason I did this was because of the plugin Restrict User Access but now I hotfixed that compat issue in https://github.com/JoryHogeveen/view-admin-as/pull/54/commits/5c566f07f85314f72841c13c0dd98292d6fb5229

EDIT: I also think using new WP_User() for every time the filter gets called isn't the right way to go in terms of performance. Calling a new user object will run the whole process of getting user data etc. over and over, resetting all data and setting it again. Especially in combination with add_role() which also invokes update_user_meta().

Thanks anyway and please update!