Indicate when the `auto_update_{$type}` filter is being used

[desrosj]

Aside from the new filters and functions that were added in 5.5 for controlling plugin and theme auto-updates, the auto_update_{$type} filter has existed since 3.7.0, and is likely being utilized in the wild today to enable auto-updates.

auto_update_plugin and auto_update_theme can be used to blanket enable or disable auto-updates for all plugins and themes respectively.

add_filter( 'auto_update_plugin', '__return_false' );

In this case, if the UI is not disabled, and the user enables auto-updates for a given plugin, they may be confused when auto-updates do not get applied when available. Site Health may also report that a plugin has auto-updates enabled (based on the setting chosen in the UI), even when the filter is overriding that behavior.

It would be nice if some basic tests could be performed to try and detect when these filters have functions hooked to them and the UI is not disabled so the user can be made aware that "a plugin or custom code may be overriding auto-update settings". It could be really helpful to debug issues with plugin/theme auto-updates.

[desrosj]

Initial proof of concept

[desrosj]

Sorry for the noise, had the wrong patch and then noticed an error.

50662.3.diff​ is an initial proof of concept that flags the following situations:

• The auto_update_{$type} filter returns false and the UI is set to display.
• The auto_update_{$type} filter returns false and there is a function attached to the filter hook.

Noting here that the "Background updates are working" description may be worth updating to reflect that plugin and theme updates may also be affected.

Current string:
Background updates ensure that WordPress can auto-update if a security update is released for the version you are currently using.

Suggested change: Background updates ensure that WordPress can auto-update if a security update is released for the version you are currently using, and that plugin and themes can auto-update when newer versions become available.

[audrasjb]

@desrosj looks great to me. Just found a small typo in the DocBlock

Test if plugin an theme auto-updates appear to be configured correctly.

Should be "plugin and theme auto-updates" ;)

Otherwise, the status messages look perfect to me, thanks @desrosj ! 🙌

[whyisjake]

In 48548:

Site Health: Add tests to check for potential issues with plugin and theme auto-updates.

Fixes #50662.
Props desrosj, audrasjb.

[SergeyBiryukov]

In 48558:

Site Health: Add the test for plugin and theme auto-updates to WP_Site_Health::get_tests().

This ensures that the test actually runs.

Follow-up to [48548].

See #50662.

[SergeyBiryukov]

In 48559:

Site Health: Correct inverted logic for themes in the test for plugin and theme auto-updates.

Follow-up to [48548], [48558].

See #50662.

[SergeyBiryukov]

In 48560:

Site Health: Fix some typos in the test for plugin and theme auto-updates.

Follow-up to [48548], [48558], [48559].

See #50662.

[dd32]

r48548 - FYI, this only passes 1 arg to the auto_update_theme and auto_update_plugin filters which expects 2 args.

Although a common use-case is to blanket return true/false, it's also expected to be able to return conditionally based on the plugin/theme passed to it, for example, see the final example here: ​https://wordpress.org/support/article/configuring-automatic-background-updates/#plugin-theme-updates-via-filter

Causes fatals like this:
Uncaught ArgumentCountError: Too few arguments to function Jetpack_Autoupdate::autoupdate_theme(), 1 passed in wp-includes/class-wp-hook.php on line 287 and exactly 2 expected in /plugins/jetpack/class.jetpack-autoupdate.php:91

[audrasjb]

Thanks @dd32 for spotting this.

Therefore, we must pass the second $item argument.
Should we get the first plugin in active_plugins option? (and same for the active theme)

If active_plugin is empty we could pass the check.
… but It wouldn't handle installations with only not actived plugins/themes.

Hmm. Any thoughts @pbiron?

[desrosj]

I'm thinking it's best to pass a mock plugin object to the filter. That way code targeting a specific plugin (say akismet or hello-dolly), then it would produce inaccurate results. Patch incoming.

[desrosj]

50662.4.diff​ creates two mock objects and passes them to the apply_filter calls.

This should fix the issue, but would love a sanity check.

[pbiron]

Agree with @desrosj that a mock item would be better.

One question about 50662.4.diff​: for the mock plugin you give a non-empty url, but for the mock theme you give an empty url? Was there a specific reason for that?

[desrosj]

Replying to pbiron:

for the mock plugin you give a non-empty url, but for the mock theme you give an empty url? Was there a specific reason for that?

No, I think I was just copying the fields over before I plugged in values and forgot that one. Package url may need to be added too. If everything else looks good I can double check the fields before committing.

[pbiron]

I just checked and I think you got all of the correct fields for both the mock plugin and theme, but it wouldn't hurt for you to double-check as well before committing :-)

And yes, package should be non-empty for the mock theme as well.

Other than that, looks good from here.

[desrosj]

In 48584:

Site Health: Pass all expected parameters to auto_update_{$type}.

This prevents fatal errors when other hooked functions are expecting both parameters.

Props dd32, desrosj, audrasjb, pbiron.
Fixes #50662.

[SergeyBiryukov]

In 48587:

Site Health: Correct the quotes for the tested value of mock plugin data in auto-updates test.

Follow-up to [48584].

See #50662.