[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