Hello, according to the github-updater Wiki for Remote Management there is an overload for users with role 'administrator', but my question is .. what capacity (for example it can be: 'update_core') is checked to validate that overload?
I commented, I have created a new role called 'owner' with certain capabilities very similar to the role 'administrator' .. but I want this new role, is not affected to the possible overload that affects the administrators, so so .. what is the capacity that must NOT have the role 'owner' so that there is no possible overload?
Please, I could clarify more details on this topic.
I would appreciate it very much.
Thank you!
GitHub Updater only runs under the following user privileges.
This being said. When WP-Cron is being used, which has been the default for several major releases, even with an administrator there shouldn鈥檛 be a significant slowdown.
@afragen Thank you very much for the quick response.
So if I am looking for Github Updater to only run for users with the ability to update wp .. would it be enough to use this certain filter?
add_filter( 'github_updater_add_admin_pages', function ( $admin_pages ) {
if ( ! current_user_can( 'update_core' ) ) {
return [];
}
return $admin_pages;
} );
There is no filter for this. Only the users who can manage_network or manage_options can run GitHub Updater. Those are capabilities that only network administrators for multisite or administrators on a single site install have.
I understand, could you create a filter to modify the capabilities in a next version of github-updater ?? ..
I would greatly appreciate it.
Actually in looking at how you鈥檙e using the filter it looks like it could work. But this might open it up for individual administrators on a multisite. I haven鈥檛 checked.
The user would still need the above privileges in addition to any other restrictions you鈥檝e just placed.
Adding a filter like that would be a big security risk. Any random plugin could then allow for any user to be able to utilized GitHub Updater.
I understand, what happens is that my role 'owner' has that capacity (manage_options) added .. and I do not want github-updater not to load for users with role 'owner' ..
I consider using the 'update_core' capability instead of 'manage_options' .. I think a user with the 'update_core' capability looks more like a global administrator.
What do you suggest doing to prevent github-updater from loading for users with the 'owner' role?
Out of curiosity what capabilities does owner have that administrator doesn鈥檛. The reverse as well.
These are the capabilities of the role owner.
$capabilities_owner = [
// Administrator
'delete_users' => true,
'edit_users' => true,
'edit_theme_options' => true,
'list_users' => true,
'manage_options' => true,
'promote_users' => true,
'remove_users' => true,
'customize' => true,
'create_users' => true,
// Editor
'moderate_comments' => true,
'manage_categories' => true,
'manage_links' => true,
'edit_others_posts' => true,
'edit_pages' => true,
'edit_others_pages' => true,
'edit_published_pages' => true,
'publish_pages' => true,
'delete_pages' => true,
'delete_others_pages' => true,
'delete_published_pages' => true,
'delete_others_posts' => true,
'delete_private_posts' => true,
'edit_private_posts' => true,
'read_private_posts' => true,
'delete_private_pages' => true,
'edit_private_pages' => true,
'read_private_pages' => true,
'unfiltered_html' => true,
// Author
'edit_published_posts' => true,
'upload_files' => true,
'publish_posts' => true,
'delete_published_posts' => true,
// Contributor
'edit_posts' => true,
'delete_posts' => true,
// Subscriber
'read' => true,
];
From what you said above it seems like you want GHU to load for owner and it will.
Are those only for a single site install?
What I want is the opposite ... that GHU does not charge for owner.. only administrator
Yes, it is a single installation.
If you set manage_options => false for owner then it won鈥檛 run. Otherwise your owner has the same privileges as administrator
It looks like I could just check against the update_core, update_plugins, or update_themes capabilities. I鈥檒l do some testing.
Yes, I know .. but I need owner to see:
Settings> General
Settings> Writing
Settings> Reading
Settings> Discussion
Settings> Permalinks
Settings> Miscellaneous , etc...
A query, when returning an empty array of the pages where GHU is loaded in the filter 'github_updater_add_admin_pages' even though it is possible that owner will experience some overload when using a Remote Manager ????
add_filter( 'github_updater_add_admin_pages', function ( $admin_pages ) {
if ( ! current_user_can( 'update_core' ) ) {
return [];
}
return $admin_pages;
} );
If using the above filter the owner would likely see negligible impact though it might appear that GHU is loaded for them.
Ohh ... I understand.
As I said I think that validating update_core,update_plugins, or update_themes is more logical since the GHU is more about updates and / or installations ... I think 'manager_option' does not necessarily go aligned with the GHU objective.
I hope you can consider it for a future release ... I would appreciate it.
@franzarmas so in testing it all seems to work as expected. I think the following should help you out.
https://github.com/afragen/github-updater/commit/b0751763789dfdb2e76701a4e260361c67b9d797
https://github.com/afragen/github-updater/commit/36c4d9da100452643c9cd21bddc7db9524892151
Thank you very much for this @afragen , GHU is great ...
I remain attentive to the next release, greetings!