[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