Jak zastąpić pliki JavaScript w motywie potomnym?

Ładuję niektóre pliki JavaScript w motywie nadrzędnym. Ścieżka w kompozycji nadrzędnej to:

scripts > custom.js

W motywie potomnym tworzę tę samą ścieżkę ( scripts > custom.js) i zmieniam część jQuery w custom.jspliku.

Problem polega na tym, że zmiany nie są stosowane. Czy to zły sposób wprowadzania zmian w tych plikach w motywie potomnym?

Motywy potomne zastępują tylko pliki php (takie jak header.php), które są zawarte w funkcjach takich jak get_template_part lub get_header itp.

Prawidłowy sposób dodawania skryptów do WordPress to użycie wp_enqueue_script . Jeśli używa tego motyw nadrzędny, możesz przesłonić pliki JS, używając wp_dequeue_script i umieszczając w kolejce własne.

Tak jak ...

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

Jeśli motyw nadrzędny nie używa skryptu wp_enqueue_script, prawdopodobnie podłącza się do wp_head (lub wp_footer), aby wysłać tam echa skryptów. Więc byłoby użyć remove_action , aby pozbyć się tych funkcji echo skrypty na zewnątrz, a następnie enqueue własnego scenariusza.

Jeśli skrypt jest zakodowany na stałe w pliku szablonu, wystarczy zastąpić ten plik szablonu w motywie podrzędnym bez znacznika script.

Jeśli użyli wywołań wp_enqueue_script, które wykorzystują get_stylesheet_directory_uri , nie powinieneś nic robić. Ponieważ tak się nie dzieje, musisz po prostu pogrzebać i zobaczyć, co zrobił autor motywu.

W niektórych przypadkach ważne jest, aby nadać priorytet zarówno wywołaniom funkcji add_action, jak i wp_enqueue_script:

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

W tym przypadku obiekt nadrzędny wp_enqueue_scripts został wywołany z priorytetem 20120206 (data), więc akcja ta jest dodawana z priorytetem niewiele większym, aby można ją było natychmiast usunąć z kolejki. Następnie następująca po nim instrukcja kolejki jest tak naprawdę traktowana priorytetowo, aby upewnić się, że ładuje się po usunięciu kolejnej starej. Prawda, w tym przypadku jest również ważna, ponieważ określa, że ​​należy ją umieszczać w kolejce w stopce, czyli w miejscu, w którym skrypt nadrzędny został po raz pierwszy umieszczony w kolejce.

Nie potrafię też tego całkowicie wyjaśnić, ale zauważam, że jeśli jesteś ostrożny w usuwaniu z kolejki początkowego skryptu natychmiast po kolejce, wydaje się, że możesz skutecznie zapobiec jego załadowaniu.

wywołaj wp_deregister_script przed zarejestrowaniem własnej wersji

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