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

 > If the custom background default wp-head-callback
 (_custom_background_cb) is used, we use postMessage for all custom
 background properties. Otherwise, we use full refreshes.

 Was looking at this yesterday, didn't suggest a patch since it's a big
 change. Perhaps something to consider for 3.5 or in the future.

 Wouldn't it be simpler and more robust to always do a full refresh of the
 preview iframe when a user changes something? That would allow WP filters,
 actions and PHP callbacks to run on the changed value and
 filter/reject/tweak the value according to the theme and any plugins that
 may be hooked there or after that.

 So instead of the current "flow":
 - User changes a setting
 - We send the changes back to the server (if they need processing in PHP)
 - We receive the filtered values (optional)
 - We push them to the preview iframe, applying the changes with JS

 we could do:
 - User changes a setting
 - We send the changes back to the server triggering a refresh of the
 preview iframe.

 In both cases the preview is updated to reflect the new setting. In the
 second case we don't need to push any changes with JS removing any
 complications there (cross-domain iframes, etc.).

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