[wp-trac] [WordPress Trac] #50280: Enable auto-updates shows for plugins with no support
WordPress Trac
noreply at wordpress.org
Fri Jun 5 23:03:21 UTC 2020
#50280: Enable auto-updates shows for plugins with no support
------------------------------------+-----------------------------------
Reporter: elrae | Owner: audrasjb
Type: enhancement | Status: accepted
Priority: normal | Milestone: 5.5
Component: Upgrade/Install | Version: trunk
Severity: normal | Resolution:
Keywords: has-patch dev-feedback | Focuses: docs, administration
------------------------------------+-----------------------------------
Comment (by pbiron):
Functionally, looks good.
A couple of things, however.
The documentation for `theme_auto_update_setting_template` should give
more "guidance" about what the callback should return (unclear to me right
now whether `documentation` here means the DocBlock, the plugins handbook
or a `dev-note`...certainly the last, but probably the 1st and 2nd as
well).
For example, suppose a plugin manages the auto-update setting for 2
different themes. The callback for `theme_auto_update_setting_html` (the
multisite list table) is pretty straightforward:
{{{#!php
add_filter(
'theme_auto_update_setting_html',
function( $html, $stylesheet, $theme ) {
if ( in_array( $stylesheet, array( 'twentynineteen',
'twentytwenty' ), true ) ) {
return 'this is a test';
}
return $html;
},
10,
3
);
}}}
It took me a little while to figure out how to do the equivalent for
`theme_auto_update_setting_template`:
1. the plugin author needs to know that they probably want to test against
`data.id` (where the callback for `theme_auto_update_setting_html` is
explicitly passed `$stylesheet`...I had to look at the source of `wp-
admin/js/theme.js` to figure out what to test against)
2. the callback needs to **always** include the original template in their
return value, as an "else" when their test fails (i.e., it's not one of
the themes they are managing auto-updates for), otherwise there is no
auto-update link for the themes they are **not** managing
That is, something like:
{{{
#!php
add_filter(
'theme_auto_update_setting_template',
function( $template ) {
return <<<EOF
<# if ( [ 'twentynineteen', 'twentytwenty' ].includes ( data.id ) ) { #>
<p>this is a test</p>
<# } else { #>
{$template}
<# } #>
EOF;
}
);
}}}
The other thing is that if the callback for
`theme_auto_update_setting_template` returns something that is an
"illegal" template (i.e., contains backbone or JS errors) then the Theme
Details modal doesn't open for **any** theme!!, For example,
{{{
#!php
add_filter(
'theme_auto_update_setting_template',
function( $template ) {
// note that I forgot the "#" after the opening "< if..."
return <<<EOF
< if ( [ 'twentynineteen', 'twentytwenty' ].includes ( data.id ) ) { #>
<p>this is a test</p>
<# } else { #>
{$template}
<# } #>
EOF;
}
);
}}}
Not sure there's anything we can do about that, just pointing out that
developers will need to be reminded that the template they return from
`theme_auto_update_setting_template` has "global" consequences, whereas
the returned HTML from `theme_auto_update_setting_html` only affects
specific rows in the list table.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/50280#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list