[wp-trac] [WordPress Trac] #45599: WP_Scripts::localize is encoding booleans incorrectly

WordPress Trac noreply at wordpress.org
Wed Dec 12 14:44:56 UTC 2018


#45599: WP_Scripts::localize is encoding booleans incorrectly
--------------------------+-----------------------------
 Reporter:  conner_bw     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  I18N          |    Version:  5.0
 Severity:  normal        |   Keywords:
  Focuses:  javascript    |
--------------------------+-----------------------------
 Since 4.4.0 we can use the `mejs_settings` filter to configure the
 MediaElement settings.

 The problem is [https://github.com/WordPress/wordpress-
 develop/blob/140a95cf084922077a5d1e0814a49da0094b848e/src/wp-includes
 /script-loader.php#L504 that the filter is being run through
 WP_Scripts::localize]

 Valid MediaElement params:
  +
 https://github.com/mediaelement/mediaelement/blob/master/docs/api.md#mediaelementplayer

 The params I want to change are booleans. Booleans get encoded as json
 strings. WP_Scripts::localize() encodes false as "" and true as "1"

 I've run into this problem twice this week. Some other 3rd party scripts
 are not having it with this interpretation of booleans.

 Test case:

 {{{
 add_filter( 'mejs_settings', function( $mejs_settings ) {
         $mejs_settings['autoRewind'] = false;
         return $mejs_settings;
 } );
 }}}


 Expected:

 {{{
 var _wpmejsSettings = {"pluginPath":"\/blog\/wp-
 includes\/js\/mediaelement\/","classPrefix":"mejs-","stretching":"responsive","autoRewind":false};
 }}}

 Actual:

 {{{
 var _wpmejsSettings = {"pluginPath":"\/blog\/wp-
 includes\/js\/mediaelement\/","classPrefix":"mejs-","stretching":"responsive","autoRewind":""};
 }}}

 -=-=-

 Proposed patch, [https://github.com/WordPress/wordpress-
 develop/blob/140a95cf084922077a5d1e0814a49da0094b848e/src/wp-
 includes/class.wp-scripts.php#L434 change]:

 {{{
 foreach ( (array) $l10n as $key => $value ) {
         if ( !is_scalar($value) )
                 continue;

         $l10n[$key] = html_entity_decode( (string) $value, ENT_QUOTES,
 'UTF-8');
 }
 }}}

 To:

 {{{
 foreach ( (array) $l10n as $key => $value ) {
         if ( $value === true || $value === false ) // Don't stringify
 booleans
                 continue;
         if ( !is_scalar($value) )
                 continue;

         $l10n[$key] = html_entity_decode( (string) $value, ENT_QUOTES,
 'UTF-8');
 }
 }}}

 This raises questions about why integers and floats are also getting
 stringified? The argument "because they are supposed to be read by the
 user, so strings!" makes some sense to me. I'm willing not argue about
 changing the existing behaviour for those types.

 Where this falls apart is encoding true to "1" and false to "". If those
 had the intention of being read by the user then they are, in my opinion,
 illegible.

 Thank you for your consideration

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45599>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list