DISALLOW_FILE_MODS shouldn't remove update notifications
|Reported by:||iandunn||Owned by:|
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).
Change History (16)
- Keywords needs-patch added; has-patch removed
- Milestone changed from 3.7 to Future Release
- Type changed from task (blessed) to enhancement