-
Notifications
You must be signed in to change notification settings - Fork 430
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't prompt for plugin updates #489
Comments
Related #414 |
By default the following logic will be used: User < 'publish_posts': no admin notices User < install/update/activate: "contact administrator notice" without disclosing information about the plugins involved and only if there are *required* plugins which require action. User = install/update/activate: "normal" notices The minimum user level for which admin notices are shown at all can be adjusted by using the newly introduced `tgmpa_show_admin_notice_capability` filter. The default is set to 'publish_posts', i.e. Authors. Example: add_filter( 'tgmpa_show_admin_notice_capability', create_function( '$cap', 'return \'edit_pages\';' ) ); To only show the admin notices to network admins on multisite, set it to a super admin capability like 'manage_network_plugins'. Note: the `notices()` function is ugly and in desperate need of refactoring, that is not handled in this PR (which only makes it worse). Fixes #190, #414 Supersedes: https://github.com/INN/Largo/pull/740/files Partially fixes #479, #489 - notice will now only show for required updates for non-admin users with level author or editor. Possibly fixes #492, though more information is needed on the actual case.
By default the following logic will be used: User < `'publish_posts'` (=Author): no admin notices User < install/update/activate: "contact administrator notice" without disclosing information about the plugins involved and only if there are *required* plugins which require action. User = install/update/activate: "normal" notices The minimum user level for which admin notices are shown at all can be adjusted by using the newly introduced `tgmpa_show_admin_notice_capability` filter. The default capability is set to `'publish_posts'`. Example: add_filter( 'tgmpa_show_admin_notice_capability', create_function( '$cap', 'return \'edit_pages\';' ) ); Another example: To only show the admin notices to network admins on multisite, set it to a super admin capability like `'manage_network_plugins'`. Note: the `notices()` function is ugly and in desperate need of refactoring, that is not handled in this PR (which only makes it worse). Fixes #190, #414 Supersedes: https://github.com/INN/Largo/pull/740/files Partially fixes #479, #489 - notice will now only show for required updates for non-admin users with level author or editor. Possibly fixes #492, though more information is needed on the actual case.
By default the following logic will be used: User < `'publish_posts'` (=Author): no admin notices User < install/update/activate: "contact administrator notice" without disclosing information about the plugins involved and only if there are *required* plugins which require action. User = install/update/activate: "normal" notices The minimum user level for which admin notices are shown at all can be adjusted by using the newly introduced `tgmpa_show_admin_notice_capability` filter. The default capability is set to `'publish_posts'`. Example: add_filter( 'tgmpa_show_admin_notice_capability', create_function( '$cap', 'return \'edit_pages\';' ) ); Another example: To only show the admin notices to network admins on multisite, set it to a super admin capability like `'manage_network_plugins'`. Note: the `notices()` function is ugly and in desperate need of refactoring, that is not handled in this PR (which only makes it worse). Fixes #190, #414 Supersedes: https://github.com/INN/Largo/pull/740/files Partially fixes #479, #489 - notice will now only show for required updates for non-admin users with level author or editor. Possibly fixes #492, though more information is needed on the actual case.
This was posted a year ago, is there any update on this? Every user role is getting the plugin installation and activation nags even though these should only be showed to administrators. thanks |
@jrfnl thank you for the help. |
@jrfnl how do i actually go about disabling these notices for non-super-admins? |
@paulcanning You hook into the See the first bullet in Enhancements in the TGMPA 2.6.0 changelog, as well as the detailed description in PR #507. Does that answer your question ? |
Hi,
It would be great to have an configuration option which disables the 'There is an update available' prompt for plugins. It would be even better if this could be selectively disabled, based on whether the user has permission to install plugin updates.
One problem I'm currently faced with is that I have non-administrator users using the WordPress admin interface. If there are updates available for required plugins, they see a prompt which says 'Sorry, but you do not have the correct permissions to update the [...] plugin.'
This message appears at the top of every page for my non-administrator users, until an administrator logs in and performs the necessary updates. Not only is the wording of this message confusing for users – because it suggests that the user has tried to perform an action (update plugins) which they didn't – but it also adds an annoying nag which appears at the top of every page.
In this screenshot I am logged in as an Editor. I have simply loaded the 'All Pages' list, and haven't attempted to perform any plugin updates. But I am greeted with a warning message to tell me that I don't have permission. This is not a good user experience.
I've looked into the TGM class to resolve this, but I can't see any convenient actions or filters for me to hook in to. Nor can I find a configuration option to disable update nags.
Your thoughts and ideas for implementation would be great. I'm thinking either a configuration option, or the ability to hook into a filter (or even both) would provide suitable flexibility. Beyond that, perhaps there is no need to show the 'Sorry' message at all when a user doesn't have permission to perform updates – after all, they didn't try to install anything, so why should they see the message?
The text was updated successfully, but these errors were encountered: