[wp-trac] [WordPress Trac] #19910: Appearance Improvements: Theme Customization Frame

WordPress Trac wp-trac at lists.automattic.com
Fri May 25 22:00:51 UTC 2012


#19910: Appearance Improvements: Theme Customization Frame
-------------------------------------+--------------------------
 Reporter:  koopersmith              |       Owner:  koopersmith
     Type:  task (blessed)           |      Status:  closed
 Priority:  normal                   |   Milestone:  3.4
Component:  Appearance               |     Version:  3.3.1
 Severity:  normal                   |  Resolution:  fixed
 Keywords:  dev-feedback needs-docs  |
-------------------------------------+--------------------------

Comment (by Otto42):

 Replying to [comment:22 azaozz]:
 > So if there's a plugin that runs hooks on a setting and the theme opts
 for postMessage,

 In that case the plugin is perfectly capable of overriding the theme's
 control and changing the transport mode for that control to "refresh" and
 thus forcing the customizer to refresh the theme.

 {{{
 add_action( 'customize_register', 'force_refresh_demo', 100 ); // late
 hook to ensure the control is there
 function force_refresh_demo($wp_customize) {
   wp_customize->get_setting('some-example-setting')->transport='refresh';
 }
 }}}

 Voila. Plugin can handle it, and it's the proper place for it to be
 handled because the plugin knows whether or not it's hooking onto some
 setting and modifying it in a way that the customizer will need to care
 about.

 > Denying PHP hooks on the new settings is a drawback, consider adding
 menus and widgets to the customizer in the future, "instant" JS driven
 previews would not be possible for them.
 > ...
 > The underlying problem is that in some cases the preview won't be "real"
 without a trip to the server, whether it's an XHR or iframe refresh.

 If it is necessary to add some new mechanism later that goes to the server
 to retrieve some kind of PHP generated data via AJAX, and then pass that
 into the preview frame, then that can be added later. It doesn't mean that
 we should dump postMessage and opt for full-refresh all the time, just
 because some cases don't work well with postMessage. There's nothing wrong
 with having more than one way to get the job done.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19910#comment:24>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list