Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#50825 closed defect (bug) (duplicate)

Custom plugins forcing auto-updates to true getting listed in Auto-updates Disabled view

Reported by: garyc40's profile garyc40 Owned by: garyc40's profile garyc40
Milestone: Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: has-patch
Focuses: administration Cc:


If a plugin hooks into auto_update_plugin and return true for that plugin, then the Plugins list table will show "Auto-updates enabled" on the "Automatic Updates" column. However, currently, the plugin is still listed in "Auto-updates Disabled" view, which can be confusing for the users.

There are three primary use cases here that I can think of:

  1. Prior to this release, a lot of plugins included a setting with the ability to enable or disable updates for that plugin on their settings panel. To do this they would hook into auto_updates_plugin, and find their plugin and return the value of the setting
  2. Imagine a parent plugin like WooCommerce wanting to do the above but have that setting work for WooCommerce + all add-ons (because you wouldn't want to autoupdate for example recurring but not WooCommerce core) -- incompatibility nightmares await
  3. Imagine a service plugin like a managewp type plugin where users can enable or disable autoupdates for a plug-in from the service/SaaS website as opposed to a website.

It's something you find generally when the plugin is not hosted on .org or the service being used is not on .org (the service mu plugin would set the values for each plugin via auto_update_plugin to match the service selected values).

Change History (7)

This ticket was mentioned in PR #445 on WordPress/wordpress-develop by garyc40.

4 years ago

  • Keywords has-patch added

Trac ticket:

Plugins that filter auto_update_plugin and returns true should be listed in Auto-updates Enabled view instead of Auto-updates Disabled view.

#2 @chriscct7
4 years ago

  • Focuses administration added
  • Milestone changed from Awaiting Review to 5.5
  • Owner set to garyc40
  • Status changed from new to assigned

#3 @pbiron
4 years ago

I think this is the same problem as #50808. Before closing this as a dup, @chriscct7, can you please verify whether it the same?

Also, the patch on #50808 covers a few more edge cases than the PR on this ticket does. For example, a plugin hosted on .org that an admin has set to auto-update and then that plugin gets pulled from the repo...that would still show up in up in Enabled with this PR but would corrected show as Disabled with the patch on 50808.

#4 @chriscct7
4 years ago

  • Milestone 5.5 deleted
  • Resolution set to duplicate
  • Status changed from assigned to closed
  • Version trunk deleted

Duplicate of #50808.

@pbiron yep theres a discussion from this morning about this ticket in core-auto-updates that might be worth archiving into the ticket. The initial belief was this was not the same issue but on further inspection it is a variation of it and the patch on 50808 solves this issue as well (tested/confirmed this morning).

whyisjake commented on PR #445:

4 years ago

Fixed in r48703

Note: See TracTickets for help on using tickets.