Cómo interceptar guiones ya localizados

Si un complemento utiliza algún script (ejemplo destacado: jQuery UI Datepicker), pero no está satisfecho con la forma en que el script representa la salida, entonces hay dos posibilidades:

1. Anule el registro del script> Agregue su propia versión

Así que primero que había necesidad de comprobar el mango, y luego encontrar la prioridad y el gancho ( wp_enqueue_scripts, login_enqueue_scripts, etc.) ... Lo de siempre.

2. Cambie los parámetros del complemento jQuery

Normalmente, si el complemento no es basura, pasa a través de los parámetros de PHP a JS usando

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

Ahora, esta es una forma inteligente de agregar sus datos a un script JS, pero ... no se puede filtrar de manera predeterminada. Ni WP_Scriptstampoco WP_Dependenciesofrece ningún filtro que los usuarios puedan utilizar más tarde

Pregunta: ¿Cómo podemos filtrar los argumentos / parámetros que se mueven de PHP a Javascript usando wp_localize_script?

wp_localize_script()llama al método localize()en la variable global $wp_scripts. Podemos establecer esta variable en una instancia de una clase secundaria de 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;
});

El personalizador de temas no usa eso, crea una instancia separada de WP_Scripts(ver wp-admin/customize.php). Podría ser posible reemplazar eso también:

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

Nada de esto ha sido probado, solo una idea.

@toscho gran implementación. Probado y verdadero. Aquí hay una versión ligeramente modificada, que también pasa el $ handle y $ object_name para que pueda filtrar solo cuando sea necesario.

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( 'init', function() {
    $GLOBALS['wp_scripts'] = new Filterable_Scripts;
});

add_filter('script_l10n', 'se108362_example_filter', 10 , 3);

// Example
function se108362_example_filter($l10n, $handle, $object_name ) {
    if('js-handle' == $handle && 'jsVariable' == $object_name) {
       return 'Something Else';
    }
    return $l10n;
}

¡La respuesta aceptada es genial! Pero me encontré con un problema que Advanced Custom Fields dejó de funcionar en el back-end debido a un error de JavaScript. Después de excavar durante unas horas, llegué a la conclusión de que al objeto Filterable_Scripts le faltaban los archivos javascript registrados por el complemento ACF. No sé exactamente por qué hizo esto, pero he encontrado una solución adecuada para esto si te encuentras con el mismo problema.

La $GLOBALS['wp_scripts']afortunadamente, aún contenían las secuencias de comandos adecuados. Entonces hice lo siguiente en add_action:

add_action( 'wp_loaded', function() {
    $fscripts = new Filterable_Scripts();

    $missing_scripts = array_diff_key( $GLOBALS['wp_scripts']->registered, $fscripts->registered);
    foreach($missing_scripts as $mscript){
        $fscripts->registered[$mscript->handle] = $mscript;
    }

    $GLOBALS['wp_scripts'] = $fscripts;
});

Debido a que el objeto contiene una matriz de todos los scripts registrados y los controladores también son las claves de la matriz, podría usar array_diff_key para determinar qué scripts faltaban en el objeto extendido y volver a agregarlos. Hice esto y no solo

$fscripts->registered = $GLOBALS['wp_scripts']->registered;

porque no quería sobrescribir ningún cambio realizado por el objeto extendido.