¿Cómo anular archivos JavaScript en el tema secundario?

Estoy cargando algunos archivos JavaScript en el tema principal. La ruta en el tema principal es:

scripts > custom.js

En el tema secundario, estoy creando la misma ruta ( scripts > custom.js) y cambiando parte de jQuery dentro del custom.jsarchivo.

El problema es que los cambios no se están aplicando. ¿Es esta la forma incorrecta de hacer cambios en estos archivos en el tema secundario?

Los temas secundarios solo anulan los archivos php (como header.php) que se incluyen con funciones como get_template_part o get_header, etc.

La forma correcta de agregar scripts a WordPress es con wp_enqueue_script . Si su tema principal usa esto, puede anular los archivos JS mediante el uso de wp_dequeue_script y colocando el suyo.

Al igual que...

<?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 el tema principal no usa wp_enqueue_script, probablemente esté enganchado en wp_head (o wp_footer) para hacer eco de los scripts allí. Por lo tanto, usaría remove_action para deshacerse de esas funciones que hacen eco de las secuencias de comandos y luego crear su propia secuencia de comandos.

Si el script está codificado en el archivo de plantilla, solo tendrá que reemplazar ese archivo de plantilla en el tema secundario sin la etiqueta del script.

Si utilizaron llamadas wp_enqueue_script que utilizan get_stylesheet_directory_uri , entonces no debería tener que hacer nada. Como esto no está sucediendo, solo tendrás que mirar y ver qué hizo el autor del tema.

En algunos casos, es importante priorizar las llamadas a la función add_action y wp_enqueue_script de la siguiente manera:

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);
}

En este caso, el padre llamó a wp_enqueue_scripts con una prioridad de 20120206 (la fecha) y, por lo tanto, esta acción se agrega con una prioridad apenas mayor para que se elimine de inmediato. Luego, la declaración en cola que sigue a continuación se prioriza realmente después de eso para garantizar que se cargue después de que se eliminó la anterior. La verdad, en este caso, también es importante porque eso especifica que debe colocarse en cola en el pie de página, que es donde se colocó por primera vez la secuencia de comandos principal.

Además, no puedo explicarlo por completo, pero me doy cuenta de que si tiene cuidado al retirar el script inicial inmediatamente después de que se haya puesto en cola, parece que puede evitar que se cargue efectivamente en primer lugar.

llame a wp_deregister_script antes de registrar su propia versión

// 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 );