[wp-trac] [WordPress Trac] #51827: When a plugin makes use of the 'automatic_updater_disabled' filter, it causes a PHP Warning to be thrown.
WordPress Trac
noreply at wordpress.org
Sat Nov 21 16:53:10 UTC 2020
#51827: When a plugin makes use of the 'automatic_updater_disabled' filter, it
causes a PHP Warning to be thrown.
-------------------------------------------------+-------------------------
Reporter: jamesros161 | Owner: audrasjb
Type: defect (bug) | Status: accepted
Priority: highest omg bbq | Milestone: 5.6
Component: Upgrade/Install | Version: 5.6
Severity: normal | Resolution:
Keywords: has-screenshots has-patch 2nd- | Focuses:
opinion needs-testing |
-------------------------------------------------+-------------------------
Comment (by pbiron):
Replying to [comment:13 azaozz]:
> The logic is/should be that if `AUTOMATIC_UPDATER_DISABLED` is set and
false, it is equivalent to not being set
That's what I meant by "the original logic is incorrect" because it does
**not** do act like that.
> Thinking perhaps this should use `WP_Automatic_Updater::is_disabled()`
instead of trying to duplicate the logic? It already uses the
WP_Automatic_Updater to check for version control.
**YES**: calling `is_disabled()` instead of (incorrectly) recreating
''most'' of it's logic is a great idea.
[attachment:"51827.2.patch"] tests correctly for me.
Note to others testing, if you have `wp-admin/update-core.php` loaded in
your browser and you then make changes that cause `wp_is_file_mod_allowed(
'automatic_updater' )` to return false and then reload in your browser
you'll get a `Sorry, you are not allowed to access this page.` error from
WP...that is to be expected, since the Updates screen is not allowed when
file mods are disallowed :-)
--
Ticket URL: <https://core.trac.wordpress.org/ticket/51827#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list