[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