![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#57310 closed feature request (wontfix)
Possibility to dismiss plugin update notification until next version or forever
| Reported by: | abitofmind | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Upgrade/Install | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
User Story
- On your website you have most of your plugins set to auto-update ON.
- For some critical or less trusted plugins you may set auto-update to OFF.
- Of these for the majority you read the update notes carefully and then trigger a manual update.
- For a minority you may decide to skip the update for now or ignore this update altogether.
- Now mentally you are done with this, but nevertheless this "available update" continues to tax your administrative attention!
- Still adds to the count of available updates (red badge counter over "Plugins" menu entry).
- Shows a quite prominent "updates available" banner in the plugin list.
- You have to deal with something over and over again which for you is already over.
Improvement
- In the fashion of a good "attention economy" and a "get thing done" workflow this situation shall be improved.
- In the banner WordPress offers a button "Hide" plus two nearby radio buttons: (•) until next update ( ) forever.
- When clicking "Hide"
- the banner dissolves,
- and it does not contribute to the update count anymore,
- the red badge over the "Plugins" menu item disappears, if that was the last available update.
- From now there is only a very subtle reminder that a newer version would be available but you chose to ignore it:
- With this simple mechanism all possible scenarios to ignore or to pay attention get possible.
- See the mockup story below.
Attachments (11)
Change History (18)
#3
@
4 years ago
@costdev
1) I agree that the comfort of my proposed solution poses the danger of facilitating (partially) outdated installations for too long or even forever, not as a conscious decision, but due to laziness/carelessness.
2) Revised proposal: Offer this modified behavior via a plugin, e.g. named "Advanced Update Notifications".
- By not shipping this with core ("out of the box") a certain barrier of entry is there. The plugin page will list an explicit warning and list some of the few good reasons where this may be a good idea. Then the site owner gained that responsibility with a higher burden, and so it is more justified.
- Would you give that a try?
- The advantages of this solution in comparison to "mu-plugins" is that all plugin mechanisms continue to work. Just the update notification behavior is changed.
3) My personal use case: I want to stay on "Better Admin Bar" v3.4 as I don't like how the new owner continued from v4 onwards and my feedback remained unanswered. So I tried the wp-content/mu-plugins approach and it failed.
📄 https://wordpress.org/support/article/must-use-plugins/
- 👍 Overall well written.
- ❌ But doesn't address how to proceed if you want to transform an actively used plugin into a must-use plugin.
- 👉 Updating that aspect into the support article would be appreciated!
- 😉 I found out how to do it by trial and error.
Attempt 1: Just moved my activated plugin better-admin-bar from /wp-content/plugins/ to /wp-content/mu-plugins/
- Outcome: Plugin was disabled effectively.
- Going to Dashboard > Plugins gives a warning that plugin files were not found anymore.
- On next visitation that hint is gone. Good design: "We told you once" (but don't annoy you henceforth).
Attempt 2: Did it more carefully in multiple steps
- Copied (not moved!) plugin
better-admin-barfrom/wp-content/plugins/to/wp-content/plugins-off/ - Dashboard > Plugins > Better Admin Bar: First "Deactivate". Then "Uninstall".
- Plugin now gone from list.
- Note: Some plugins have an option "When uninstalling remove plugin settings from database".
- This one not. Indeed its settings remained in the database.
- Moved plugin
better-admin-barfrom/wp-content/plugins-off/to/wp-content/plugins-mu/. - Reloaded pages in frontend and backend multiple times.
- Plugin was not effective in the frontend (aka rendering, aka output).
- Dashboard > Settings: No "Better Admin Bar" entry there (which was there when installed normally).
So this seems to be one of the plugins which are not compatible with the mu-plugin method. Or I did something wrong.
Nevertheless I restored the plugin
- Moved if back from
/wp-content/mu-plugins/to/wp-content/plugins/. - Dashboard > Plugins: Plugins moved to the plugins folder with pre-existing settings in the database (= "ready to go") are nevertheless automatically disabled when detected. This is a good security/safety precaution. I enabled it again.
- It worked again, and my customized plugin settings were still working (as they were never removed from the database).
So I guess I have to live with that notification badge over the "Plugins" menu entry until an "Advanced Update Notifications" plugin may get published one day.
- I'd propose something like "Advanced" in the name instead of "Disable" or "Postpone" to not encourage/attract the forementioned negative use.
- What do you say?
#4
@
4 years ago
Hi @abitofmind, splitting this up with titles as I'm currently limited to mobile use at the moment.
Must-Use plugin
Must-Use plugins load from a single file in the mu-plugins folder, so if you wanted to convert Better Admin Bar to a Must-Use plugin (which I do not recommend but will of course not refuse you the knowledge), you can do the following:
- Copy the
better-admin-barplugin folder fromwp-content/plugins/towp-content/mu-plugins/.
- Create a new file directly in the
mu-pluginsfolder calledbetter-admin-bar.phpwith the following contents:
<?php /* Plugin Name: Better Admin Bar Plugin URI: https://kubiq.sk Description: Better Admin Bar Version: 3.4 Author: KubiQ Author URI: https://kubiq.sk Text Domain: better_admin_bar Domain Path: /languages */ require_once __DIR__ . '/better-admin-bar/better-admin-bar.php';
- Check everything works as expected.
Via Plugin
Options such as those you proposed are very much within the territory of plugins, so this is a good idea for anyone who wants these options.
As you said, as opposed to Must-Use plugins, this would have the benefit that updates would still be possible, but simply be delayed for the selected duration, and all could be restored simply by disabling the options plugin.
I really appreciate that you're mindful of language such as "Advanced" rather than "Disable" to try to minimise negative use. However, despite this, as these options still run counter to Core's philosophy, the plugin wouldn't be a Canonical plugin. That is, it would not be developed by the WordPress Core team.
So, a plugin to offer those options would need to be submitted by a third-party developer - who has either created the plugin using their own initiative, or has been hired to create the plugin.
Of course, anyone coming across this ticket should be mindful that a third-party plugin developer to create such a plugin should be looked for somewhere other than WordPress Core Trac/Slack instances.
#5
@
4 years ago
Thank you soo much for reacting that quickly and that concretely!
- That way I could work on this, and finally solve this, and put it aside mentally!
- It worked. And I can say: The whole process and UX as-is is totally sufficient! No need for a plugin.
- B/c so far, if there had been issues with a plugin, I downgraded and reported, or I first read the changelog and decided against an update, and within a matter of days or weeks, the problem was usually at least addressed (fix a bit later, but at least some reaction).
- And for that period of time the continuous update notification had the purpose of being reminded to check whether that was fixed meanwhile.
- But when there's no reaction for 2 months+, then that update notification really becomes a big annoyance.
- So far this was the absolute exception.
- And for those few exceptions the "Must Use" plugin method as a means to keep a frozen plugin is perfect as-is!
The only remaining followup:
- Please integrate proper keywords into that official search article so that it becomes more prominent in search engine results. Keyword to include:
How do I keep a plugin frozen at a certain version? How do I disable auto-updates? How do I disable update notifications? My updates available badge over the plugins menu entry does not go away, how do I remove that badge counter?
And regarding your hint, the documentation indeed mentions:
WordPress only looks for PHP files right inside the mu-plugins directory, and (unlike for normal plugins) not for files in subdirectories. You may want to create a proxy PHP loader file inside the mu-plugins directory: <code snippet>
Even though I'm somehow tech-savvy, but the term proxy PHP loader file scared me off as too technical. Proxy sounded more sophisticated than what it actually is. Had I read a term like "stub" file or "inclusion" file or similar, I may have even considered it. And being empty it does not convey the idea. Please include a more vivid example, that better conveys the idea, such as your code snippet. Also make use of the description field with a note "Why I keep that plugin frozen in version X.X". Then you as the reader immediately get the idea!
Thanks again for all your input on this subject matter!
#6
@
4 years ago
- Keywords 2nd-opinion removed
- Milestone Awaiting Review
- Resolution → wontfix
- Status new → closed
- Version 6.1.1
@abitofmind No problem! 🙂
Regarding your suggested changes to documentation, I'd recommend opening a ticket on Meta Trac - Select HelpHub as the Component - and discuss this with the Meta team, as the Must-Use plugins article is managed there.
As this ticket will not result in the feature being added to WordPress Core for the reasons mentioned during the discussion, and the remaining issue is related to Meta rather than Core, I'll close this ticket as wontfix.
Thanks for the discussion @abitofmind! 🙂
#7
@
4 years ago
- I submitted my support article improvement request the HelpHub project.
- The only regret I have is that my UX design efforts (the user story above) were too detailed too early on.
- But yeah in retrospect at least it fired up a productive discussion 👍
- And the learning that especially in open source projects, where one as an outsider may not know context/policies/priorities too well, especially in the beginning "less is more". 😉
Thank you for the discussion!
Hi @abitofmind, thanks for opening this ticket and for the very detailed user story!
Here are some thoughts I have about this proposal:
Does this benefit 80%+ of WordPress users now, or in the future?
What is already available?
in_plugin_update_message-{$file}action to add markup to the update notice. This means the functionality could be added by a plugin, rather than being added to Core and every WordPress website.mu-pluginsdirectory if it needs to stay at a certain version and the site owner doesn't want the plugin included in update counts/notices. Note: I do not recommend doing this.Core encourages site owners to keep their websites up to date, and I think making it easier not to update runs counter to that goal. I can empathise with the "tax on administrative attention". I manage a lot of client sites, so I see a lot of plugin update notices as I log into each one (and then proceed to update said plugins).
Where you, I and others might stay informed about the changelog of each plugin update, this is not the case for the majority of site owners, so I'd veer heavily on not introducing this feature to Core.
Adding
2nd-opinionto get others' views on this.