[wp-trac] [WordPress Trac] #35945: Site Logo: reconsider the `site` terminology in code
    WordPress Trac 
    noreply at wordpress.org
       
    Sun Mar  6 04:42:49 UTC 2016
    
    
  
#35945: Site Logo: reconsider the `site` terminology in code
------------------------------+-----------------------
 Reporter:  celloexpressions  |       Owner:  obenland
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  4.5
Component:  Customize         |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  commit has-patch  |     Focuses:
------------------------------+-----------------------
Comment (by westonruter):
 @celloexpressions good point, that is true. When a selective refresh
 request returns, it could include the `body_classes()` among the response
 data it returns along with the actual `contents` of the rendered partials.
 For example:
 {{{#!php
 <?php
 add_filter( 'customize_render_partials_response', function( $response ) {
     $responses['body_classes'] = get_body_class();
     return $response;
 } );
 }}}
 In the Customizer preview, some JS could then do:
 {{{#!js
 wp.customize.selectiveRefresh.bind( 'render-partials-response', function(
 response ) {
         var oldClasses, newClasses, body = $( 'body' );
         if ( response.body_classes ) {
                 newClasses = response.body_classes;
                 oldClasses = $.trim( body.attr( 'class' ) ).split( /\s+/
 );
                 _.each( _.difference( oldClasses, newClasses ), function(
 removedClass ) {
                         body.removeClass( removedClass );
                 } );
                 _.each( _.difference( newClasses, oldClasses ), function(
 addedClass ) {
                         body.addClass( addedClass );
                 } );
         }
 } );
 }}}
 This, however, is problematic because `body_class()` allows a template to
 pass in a `$class` argument containing additional classes that should be
 used on the given template. Selective refresh wouldn't have access to any
 additional classes used here, and so they would erroneously get removed
 according to the above logic.
 I think this is a good challenge to solve, but it's too late to implement
 for 4.5 and in the mean time I think we should just continue with having a
 new body class added.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/35945#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
    
    
More information about the wp-trac
mailing list