[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