[wp-trac] [WordPress Trac] #35855: Let selective refresh component be required but be opt-in for sidebars/widgets (for now)

[WordPress Trac]

#35855: Let selective refresh component be required but be opt-in for
sidebars/widgets (for now)
----------------------------+--------------------------
 Reporter:  DrewAPicture    |       Owner:  westonruter
     Type:  task (blessed)  |      Status:  accepted
 Priority:  normal          |   Milestone:  4.5
Component:  Customize       |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+--------------------------

Comment (by westonruter):

 Thanks for the thoughtful feedback!

 Replying to [comment:24 obenland]:

 > Have we exhausted all options to enable it by default and be clever
 about maybe disabling it for themes that do funky things with their
 sidebars? While the theme support route is very convenient and makes
 things very easy in terms of backwards compatibility, we pay a high price
 with waiving adoption.

 I'd love to find a solution here. The only thing that comes to mind is
 sniffing for whether widgets in a sidebar have inline style attributes
 attached to them. This could be a signal that a theme is doing something
 funky?

 > To be a bit more constructive: If adding a flag on `customize_register`
 is not an option (is it really not?)
 > […]
 > The name is not very elegant, to a degree where I think it might even
 affect adoption.

 It ''is'' an option. But it just seems 10× less elegant than adding a new
 theme support feature, where a theme support is much easier to add if it
 is needed by all themes.

 > Like @DrewAPicture pointed out in 15, the proposed name is not really
 future proof. It actually makes it more like for the influx of more calls
 to be a problem because other Customizer features that might require a
 support declaration would add their own. ¶ The model is not really
 sustainable in the long run. Default themes come with at least three
 features they need to add support for (this would be the fourth), there
 are themes like Confit that already have 9 (!) calls.

 Part of the thinking for a specific `customize-selective-refresh-widgets`
 feature name is the idea that the need for themes adding support would be
 temporary. This specific feature name could be added in 4.5 with the
 explicit advisory that the feature will be enabled by default in future
 releases, to give theme and plugin authors time to ensure they're
 compatible.

 > and we do decide to go the theme support route, may I suggest the
 following syntax:
 > {{{#!php
 > <?php
 > // General support.
 > add_theme_support( 'customizer', 'selective-refresh' );
 >
 > // Specific widgets by `id_base`.
 > add_theme_support( 'customizer', array(
 >       'selective-refresh' => array( 'foo', 'bar' ),
 > ) );
 > }}}

 Widgets are the only thing that seem to need theme support. This is why I
 shy away from breaking down the name into separate parts like
 `customizer`, `selective-refresh`, and `widgets`. Nav menu selective
 refresh is currently enabled for all themes, as is selective refresh for
 custom logos. If the theme support feature flag is removed/deprecated in a
 future release, then this would leave a `customizer` root theme option
 without any children.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35855#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform