WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 8 weeks ago

#25219 new enhancement

DISALLOW_FILE_MODS shouldn't remove update notifications

Reported by: iandunn Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: has-patch ui-feedback
Focuses: ui Cc:

Description

I think there are valid use cases where an admin would want to set DISALLOW_FILE_MODS, but still want to get the notifications when core/plugins/theme updates are available.

Instead of using the built-in updater, some installs are setup to use svn:externals (or Git submodules) for updates, and others prefer to use wp-cli. In those cases, it's still very useful to get the notifications, because without them an admin has to remember to manually check for updated. That inevitably leads to situations where important security updates are missed for weeks or months, which makes the site vulnerable.

I understand the logic behind removing the notifications -- because the admin can't actually take action on them through WordPress -- but I think that incorrectly assumes that the notices have no purpose if they can't be acted on from inside WordPress. The notifications are still very useful, even if the admin chooses a different method of actually installing the updates.

My proposed solution is to introduce new meta capabilities for view_core_updates, view_plugin_updates, and view_theme_updates. This would add some granularity to the current approach, so we could distinguish between being able to know that updates are available, and being able to install them.

The new meta caps would default to manage_options, so that all administrators could see them, regardless of DISALLOW_FILE_MODS. If that's undesirable, though, then they could map to their corresponding meta caps (update_core, etc) instead (and then be overridden via the map_meta_cap filter in order to enable the notifications).

Attachments (5)

25219.diff (1.6 KB) - added by iandunn 8 months ago.
25219.2.diff (7.0 KB) - added by iandunn 7 months ago.
25219.3.diff (22.0 KB) - added by iandunn 6 months ago.
plugin-theme-update-tables.png (5.0 KB) - added by iandunn 6 months ago.
25219.4.diff (22.6 KB) - added by iandunn 8 weeks ago.
Refresh

Download all attachments as: .zip

Change History (16)

iandunn8 months ago

comment:1 iandunn8 months ago

  • Keywords has-patch added

I've attached a proof of concept that enables an admin to view plugin notifications in the Admin Bar and on wp-admin/plugins.php. If this looks good to everyone, I can expand it to include the rest of the notifications.

comment:2 SergeyBiryukov8 months ago

  • Component changed from Warnings/Notices to Upgrade/Install

comment:3 johnbillion8 months ago

  • Cc johnbillion added

comment:4 dd328 months ago

I don't think adding a new meta_cap is really needed honestly.

I'd just remove the cap check in wp_plugin_update_rows() myself, the wp_plugin_update_row() function includes a cap check which either notifies about the update, or notifies and links to a update depending on the users auth.
This check in particular was added to replace a if ( is_multisite() && !is_super_admin() ) check in [12753], it seems that the previous check was more appropriate IMHO.

The Core update nag check also tests if ( is_multisite() && !current_user_can('update_core') ) which I also feel should switch to nagging super admins..

The Dashboard -> Updates page is a bit newer though, and allowing access to that would be a little more interesting.

comment:5 SergeyBiryukov8 months ago

  • Milestone changed from Awaiting Review to 3.7

comment:6 nacin8 months ago

I've been meaning to do this for years. I don't hate the idea of a meta capability for this. It would not be terrible to allow for some sort of fine-grained control. On one hand, I hate the idea of being able to specifically hide update nags; on the other hand, there are some decent use cases for doing so.

comment:7 nacin7 months ago

  • Type changed from enhancement to task (blessed)

iandunn7 months ago

comment:8 iandunn7 months ago

Ok, I think I got them all in 25219.2.diff.

There are are few places where we might want to change the text based on if the user has view_[core|plugin|theme]_updates but not update_[core|plugins|themes], though. For example, the footer text says "Get Version 3.6.1" and links to wp-admin/update-core.php. Someone with view_core_updates can open that page, but can't run the updater, so maybe something like "View Available Updates" would be more appropriate. Thoughts on that?

comment:9 nacin6 months ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 3.7 to Future Release
  • Type changed from task (blessed) to enhancement

I like the patch, but there's more to do here. Because being able to see a plugin update is currently tied to being able to execute a plugin update, the UI needs to change. We still need to do things like suppress buttons and other actions.

Automatic background updates have their own controls, so this isn't a super priority at the moment.

comment:10 iandunn6 months ago

I've attached another pass on it to improve the UI when updates are available but can't be installed through WP. Some of it is just changing the text, but there were a few visual changes too:

  • Dashboard > Home > Right Now - replaced 'Download' button with '...please update now' text.
  • Dashboard > Updates - removed header/footer from plugin/theme tables, since it has no purpose.

Any design feedback/suggestions to improve those? I've attached a screenshot of the plugin/theme tables on the Updates screen, which can probably be made a lot better. Maybe splitting the version/compatibility/etc info into columns so that the header/footer can return?

iandunn6 months ago

iandunn8 weeks ago

Refresh

comment:11 iandunn8 weeks ago

  • Focuses ui added
  • Keywords has-patch ui-feedback added; needs-patch removed

I refreshed the patch and would love to get some feedback on the UI.

Note: See TracTickets for help on using tickets.