Comment remplacer les fichiers JavaScript dans le thème de l'enfant?

Je charge des fichiers JavaScript dans le thème parent. Le chemin dans le thème parent est:

scripts > custom.js

Dans le thème de l'enfant, je crée le même chemin ( scripts > custom.js) et modifie une partie de jQuery à l'intérieur du custom.jsfichier.

Le problème est que les modifications ne sont pas appliquées. Est-ce une mauvaise façon de modifier ces fichiers dans le thème enfant?

Les thèmes enfants ne remplacent que les fichiers php (tels que header.php) inclus dans des fonctions telles que get_template_part ou get_header, etc.

La manière correcte d'ajouter des scripts à WordPress est d' utiliser wp_enqueue_script . Si votre thème parent l'utilise, vous pouvez remplacer les fichiers JS en utilisant wp_dequeue_script et en mettant les vôtres en file d' attente.

Ainsi...

<?php
// hook in late to make sure the parent theme's registration 
// has fired so you can undo it. Otherwise the parent will simply
// enqueue its script anyway.
add_action('wp_enqueue_scripts', 'wpse26822_script_fix', 100);
function wpse26822_script_fix()
{
    wp_dequeue_script('parent_theme_script_handle');
    wp_enqueue_script('child_theme_script_handle', get_stylesheet_directory_uri().'/scripts/yourjs.js', array('jquery'));
}

Si le thème parent n'utilise pas wp_enqueue_script, il est probablement connecté à wp_head (ou wp_footer) pour y faire écho les scripts. Donc, vous utiliseriez remove_action pour vous débarrasser de ces fonctions qui renvoient les scripts, puis mettez en file d'attente votre propre script.

Si le script est codé en dur dans le fichier de modèle, il vous suffira de remplacer ce fichier de modèle dans votre thème enfant sans la balise de script.

S'ils ont utilisé des appels wp_enqueue_script utilisant get_stylesheet_directory_uri , vous ne devriez rien avoir à faire. Comme cela ne se produit pas, il vous suffira de fouiller et de voir ce que l'auteur du thème a fait.

Dans certains cas, il est important de donner la priorité aux appels de fonction add_action et wp_enqueue_script comme suit:

add_action('wp_enqueue_scripts', 'wpse26822_script_fix', 20120207);
function wpse26822_script_fix()
{
    wp_dequeue_script('storefront-navigation');
    wp_enqueue_script('my_storefront-navigation', get_stylesheet_directory_uri().'/js/navigation.min.js', array('jquery'),20151110,true);
}

Dans ce cas, wp_enqueue_scripts a été appelé par le parent avec une priorité de 20120206 (la date); cette action est donc ajoutée avec une priorité à peine supérieure, de sorte qu'elle sera immédiatement retirée de la file d'attente. Ensuite, l'instruction de mise en file d'attente qui suit qui suit est en réalité priorisée après celle-ci afin de s'assurer qu'elle est chargée après le retrait de l'ancienne. La valeur true, dans ce cas, est également importante car elle spécifie qu'elle doit être mise en file d'attente dans le pied de page, où le script parent a été mis en file d'attente pour la première fois.

De plus, je ne peux pas tout expliquer, mais je remarque que, si vous veillez à retirer le script initial immédiatement après sa mise en file d'attente, il semble que vous puissiez effectivement l'empêcher de se charger.

appelez wp_deregister_script avant d'enregistrer votre propre version

// enqueue your required script file
add_action('wp_enqueue_scripts', 'your_child_theme_js_file_override');
function your_child_theme_js_file_override(){
    wp_enqueue_script( 'child_theme_script_handle', get_stylesheet_directory_uri() . '/assets/js/your-file.js', array('jquery' ) );
}

// dequeue your required script file
function your_child_theme_js_file_dequeue() {
   wp_dequeue_script( 'parent_theme_script_handle' );
}
add_action( 'wp_print_scripts', 'your_child_theme_js_file_dequeue', 100 );