#50662 closed defect (bug) (fixed)
Indicate when the `auto_update_{$type}` filter is being used
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (20)
#1
@
4 years 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 returnsfalse
and the UI is set to display. - The
auto_update_{$type}
filter returnsfalse
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
@
4 years 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.
4 years ago
#4
@
4 years ago
- Owner set to whyisjake
- Resolution set to fixed
- Status changed from new to closed
In 48548:
#8
@
4 years 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
@
4 years 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
@
4 years 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.
#11
@
4 years 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:
↓ 13
@
4 years 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
@
4 years ago
Replying to pbiron:
for the mock plugin you give a non-empty
url
, but for the mock theme you give an emptyurl
? 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.
Initial proof of concept