WordPress.org

Make WordPress Core

Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#50662 closed defect (bug) (fixed)

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

Reported by: desrosj Owned by: whyisjake
Milestone: 5.5 Priority: normal
Severity: normal Version: 5.5
Component: Site Health Keywords: has-patch
Focuses: administration Cc:

Description

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.

Attachments (4)

50662.diff (6.6 KB) - added by desrosj 3 months ago.
Initial proof of concept
50662.2.diff (6.6 KB) - added by desrosj 3 months ago.
50662.3.diff (6.6 KB) - added by desrosj 3 months ago.
50662.4.diff (2.0 KB) - added by desrosj 3 months ago.

Download all attachments as: .zip

Change History (20)

@desrosj
3 months ago

Initial proof of concept

@desrosj
3 months ago

@desrosj
3 months ago

#1 @desrosj
3 months ago

  • Keywords has-patch needs-testing added

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.

#2 @audrasjb
3 months ago

  • Keywords 2nd-opinion removed

@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 ! 🙌

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


3 months ago

#4 @whyisjake
3 months ago

  • Owner set to whyisjake
  • Resolution set to fixed
  • Status changed from new to closed

In 48548:

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

Fixes #50662.
Props desrosj, audrasjb.

#5 @SergeyBiryukov
3 months ago

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.

#6 @SergeyBiryukov
3 months ago

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.

#7 @SergeyBiryukov
3 months ago

In 48560:

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

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

See #50662.

#8 @dd32
3 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#9 @audrasjb
3 months ago

  • Keywords needs-patch added; has-patch needs-testing removed

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?

#10 @desrosj
3 months ago

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
3 months ago

#11 @desrosj
3 months ago

  • Keywords has-patch added; needs-patch removed

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.

#12 follow-up: @pbiron
3 months ago

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?

#13 in reply to: ↑ 12 @desrosj
3 months ago

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.

#14 @pbiron
3 months ago

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.

#15 @desrosj
3 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#16 @SergeyBiryukov
3 months ago

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.

Note: See TracTickets for help on using tickets.