Como substituir arquivos JavaScript no tema filho?

Estou carregando alguns arquivos JavaScript no tema principal. O caminho no tema pai é:

scripts > custom.js

No tema filho, estou criando o mesmo caminho ( scripts > custom.js) e alterando algumas das jQuery dentro do custom.jsarquivo.

O problema é que as alterações não estão sendo aplicadas. Essa é a maneira errada de fazer alterações nesses arquivos no tema filho?

Os temas filhos substituem apenas arquivos php (como header.php) que estão incluídos em funções como get_template_part ou get_header, etc.

A maneira correta de adicionar scripts ao WordPress é com wp_enqueue_script . Se o seu tema pai usar isso, você poderá substituir os arquivos JS usando wp_dequeue_script e enfileirando o seu próprio.

Igual a...

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

Se o tema pai não estiver usando wp_enqueue_script, provavelmente está conectando-se a wp_head (ou wp_footer) para ecoar os scripts lá. Portanto, você usaria remove_action para se livrar dessas funções que ecoam os scripts e enfileirar seu próprio script.

Se o script estiver codificado no arquivo de modelo, você precisará substituí-lo no tema filho sem a tag de script.

Se eles usaram chamadas wp_enqueue_script que utilizam get_stylesheet_directory_uri , não é necessário fazer nada. Como isso não está acontecendo, você terá que bisbilhotar e ver o que o autor do tema fez.

Em alguns casos, é importante priorizar as chamadas add_action e wp_enqueue_script da seguinte maneira:

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

Nesse caso, wp_enqueue_scripts foi chamado pelo pai com uma prioridade 20120206 (a data) e, portanto, essa ação é adicionada com uma prioridade apenas um pouco maior para que seja retirada da fila imediatamente. Em seguida, a declaração de enfileiramento a seguir é realmente priorizada depois disso, para garantir que ela seja carregada após a retirada da antiga. O verdadeiro, nesse caso, também é importante porque especifica que ele deve ser enfileirado no rodapé, que é onde o script pai foi enfileirado pela primeira vez.

Além disso, não consigo explicar completamente, mas percebo que, se você tomar cuidado com o desenfileiramento do script inicial imediatamente após o enfileiramento, parece que você pode efetivamente impedir que ele seja carregado em primeiro lugar.

chame wp_deregister_script antes de registrar sua própria versão

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