[wp-trac] [WordPress Trac] #40432: Customizer: Should we stop contextually hiding features?
WordPress Trac
noreply at wordpress.org
Thu Apr 13 06:21:13 UTC 2017
#40432: Customizer: Should we stop contextually hiding features?
-------------------------+------------------------------
Reporter: melchoyce | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Customize | Version:
Severity: normal | Resolution:
Keywords: | Focuses:
-------------------------+------------------------------
Comment (by westonruter):
Replying to [comment:4 sami.keijonen]:
> This is tricky one. I have had also other feedback when not using
contextually hiding widgets for example: "I'm adding a widgets but I can't
see them on the preview. Theme is broken".
Exactly. In the live preview interface, if something can be edited which
is not displayed in the preview, it defeats the whole point. So if an
inactive control _is_ displayed, there will have to be some very explicit
messaging/indicators to communicate that they would be making any
modifications “blind”.
> Could the preview automatically go to that page where there are widgets?
Unfortunately not. In the case of a widget area, for example, it is
unknown which templates will have the required `dynamic_sidebar()` call to
display the widget area, and so we cannot know which URL to take the user
to either. This is a side effect of themes largely being procedural rather
than declarative.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/40432#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list