[wp-trac] [WordPress Trac] #35855: Let selective refresh component be required but be opt-in for sidebars/widgets (for now)
noreply at wordpress.org
Tue Mar 15 18:17:21 UTC 2016
#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
> 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
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
> and we do decide to go the theme support route, may I suggest the
> // 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
More information about the wp-trac