[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 azaozz):

 Replying to Otto42:
 > 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.

 So if there's a plugin that runs hooks on a setting and the theme opts for
 postMessage, the preview would not reflect the filtering done by the
 plugin and the output will be different from the front-end? The main point
 of a preview is to be "truthful" :)

 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.

 Replying to nacin:
 As far as I remember the original scope was to have an API for front-end
 previews accessible from any page in the admin. Handling the preview from
 JS only was a "nice-to-have-if-it-works" kind of thing.

 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.

 Yes, agree now it's not the time for such discussion, could we leave it
 for when adding widgets and menus support to the customizer.

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