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

[WordPress Trac]

#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):

 If a theme or plugin is using filters on those relevant pieces in some
 way, then they have the ability to change the control to be using refresh
 instead of postMessage as well. It's one line of code:

 {{{
 $wp_customize->get_setting('background-color')->transport='refresh';
 }}}

 As it is, I figure most will be going the other way and changing default
 refresh settings to be postMessage ones.

 Themes we don't need to worry about at all WRT their filters, since the
 theme author will also have to implement any JS to handle a postMessage
 method. The controls default to refresh, after all, they have to turn on
 postMessage.

 And yes, I think it should totally prevent hooks running on the settings,
 for the case where the theme has explicitly said "hey, use postMessage".
 Not running those through the server is sort of the whole point.

 Re: IE, just force it to refresh on all controls when IE and cross-domain
 is detected. Not much else to do about that. postMessage is an optional
 add-on that the theme has to both enable and add extra code to support,
 while refresh is the default.

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