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

[garyc40]

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).

Trac ticket: https://core.trac.wordpress.org/ticket/50825

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

[pbiron]

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.

[chriscct7]

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).

Trac ticket: https://core.trac.wordpress.org/ticket/50825

Fixed in r48703

Merged into WP Core in https://core.trac.wordpress.org/changeset/48704