Si un plugin utilise un script (exemple important: jQuery UI Datepicker), mais que vous n'êtes pas satisfait de la façon dont le script rend la sortie, il y a deux possibilités:
1. Annulez l'enregistrement du script> Ajoutez votre propre version
Alors d' abord , vous aurez besoin de vérifier la poignée, puis trouver la priorité et le crochet ( wp_enqueue_scripts
, login_enqueue_scripts
, etc.) ... vous savez la perceuse.
2. Modifiez les paramètres du plugin jQuery
Normalement - si le plugin n'est pas de la merde - il pousse à travers les paramètres de PHP à JS en utilisant
wp_localize_script( $handle, $object_name, array(
// data
) );
Maintenant, c'est une façon intelligente d'ajouter vos données à un script JS, mais ... ce n'est pas filtrable par défaut. Ni WP_Scripts
ni WP_Dependencies
propose aucun filtre que les utilisateurs peuvent utiliser ultérieurement
Question: Comment filtrer les arguments / paramètres qui sont déplacés de PHP vers Javascript en utilisant
wp_localize_script
?
wp_localize_script()
: un tableau simple ou multidimensionnel .@toscho grande implémentation. Testé et vrai. Voici une version légèrement modifiée, qui passe également le $ handle et $ object_name afin que vous ne puissiez filtrer qu'en cas de besoin.
la source
La réponse acceptée est super! Mais j'ai rencontré un problème qui empêchait les champs personnalisés avancés de fonctionner dans le backend en raison d'une erreur javascript. Après avoir creusé pendant quelques heures, je suis arrivé à la conclusion que l'objet Filterable_Scripts manquait les fichiers javascript enregistrés par le plugin ACF. Je ne sais pas exactement pourquoi il a fait cela, mais j'ai trouvé une bonne solution à cela si vous rencontrez le même problème.
Le
$GLOBALS['wp_scripts']
heureusement encore contenait les scripts appropriés. J'ai donc fait ce qui suit dans leadd_action
:Étant donné que l'objet contient un tableau de tous les scripts enregistrés et que les poignées sont également les clés du tableau, je pourrais utiliser array_diff_key pour déterminer quels scripts manquaient dans l'objet étendu et les ajouter à nouveau. J'ai fait ça et pas seulement
$fscripts->registered = $GLOBALS['wp_scripts']->registered;
parce que je ne voulais pas écraser les modifications apportées par l'objet étendu.
la source
$acf_field_group = $GLOBALS['wp_scripts']->registered['acf-field-group'];
(égalementacf-input
) les deux balises de script acf , puis de les ajouter à nouveau à l'instance de laWP_Scripts
balise étendue :, puis j'ai réalisé qu'ACF$GLOBALS['wp_scripts']->registered['acf-field-group'] = $acf_field_group
n'utilisait que les scripts dans Admin et je suis seulementl10n
devant donc juste enveloppé l'action et filtrer dans un!is_admin
test.