How to intercept already localized scripts

by

If a plugin uses some script (prominent example: jQuery UI Datepicker), but you’re not happy with how the script renders the output, then there’re two possibilities:

1. Unregister the script > Add your own version

So first you’d need to check the handle, then find the priority and the hook (wp_enqueue_scripts, login_enqueue_scripts, etc.) … you know the drill.

2. Change the jQuery plugin parameters

Normally – if the plugin isn’t crap – it pushes through the parameters from PHP to JS using 

wp_localize_script( $handle, $object_name, array( 
    // data
) );

Now this is a smart way of adding your data to a JS script, but … it’s not filterable by default. Neither WP_Scripts nor WP_Dependencies offers any filter users can later utilize

Question: How can we filter the arguments/parameters that are moved from PHP to Javascript using wp_localize_script?

4 s
4

wp_localize_script() calls the method localize() on the global variable $wp_scripts. We can set this variable to an instance of a child class of WP_Scripts:

class Filterable_Scripts extends WP_Scripts
{
    function localize( $handle, $object_name, $l10n )
    {
        $l10n = apply_filters( 'script_l10n', $l10n, $handle, $object_name );
        return parent::localize($handle, $object_name, $l10n);
    }
}

add_action( 'wp_loaded', function() {
    $GLOBALS['wp_scripts'] = new Filterable_Scripts;
});

The theme customizer doesn’t use that, it creates a separate instance of WP_Scripts (see wp-admin/customize.php). It might be possible to replace that too:

add_action( 'customize_controls_init', function() {
    $GLOBALS['wp_scripts'] = new Filterable_Scripts;
    $GLOBALS['wp_scripts']->registered = $GLOBALS['registered'];
});

None of this has been tested, just an idea.

Leave a Comment