get_template_part vs haki akcji w motywach

Wydaje mi się, że oba te dają użytkownikom końcowym możliwość modyfikacji motywu bez faktycznej edycji plików motywów (za pośrednictwem motywów potomnych).

Moje pytanie brzmi: czy jedna metoda jest preferowana nad drugą?

Weźmy na przykład motyw, nad którym teraz pracuję. Próbuję zdecydować, czy pójść z szablonowymi częściami haków.

<?php get_template_part('before_sitecontainer' ); ?>
<div id="sitecontainer" class="sitecontainer" <?php //closed in footer ?>>

<?php get_template_part( 'before_topcontainer' ); ?>
<div id="topcontainer ">

    <?php get_template_part( 'before_topedge_navigation' ); ?>
    <?php get_template_part( 'topedge_navigation' ); ?>

    <?php get_template_part( 'before_site_header' ); ?>
    <?php get_template_part( 'site_header' ); ?>

    <?php get_template_part( 'before_second_navigation' ); ?>
    <?php get_template_part( 'second_navigation' ); ?>

    <?php get_template_part( 'after_second_navigation' ); ?>

</div><!-- end topcontainer div -->
<?php get_template_part( 'after_topcontainer' ); ?>

Powyższe pozwala użytkownikowi motywu zastąpić dowolną sekcję istniejącego kodu, po prostu tworząc plik o odpowiedniej nazwie w folderze motywu podrzędnego, a także dodając nowy kod przed / po każdej wcześniej istniejącej sekcji tą samą metodą - szablon przed / po pliki części w ogóle nie istnieją w motywie nadrzędnym i są po prostu po to, aby umożliwić im wstawienie kodu - i ta metoda nie wymaga zrozumienia haczyków / filtrów, aby to osiągnąć.

Mógłbym oczywiście to samo osiągnąć za pomocą haczyków i filtrów.

Czy istnieje korzyść z używania haczyków / filtrów zamiast tego? Biorąc pod uwagę grupę docelową, która będzie z tego korzystać, zdecydowanie nie jest obeznany z kodem. Mogę dać im stosunkowo podstawowe instrukcje, których mogą przestrzegać, aby użyć metody szablonu, ale prawie na pewno pomieszają diabła z haczykami.

Czy są sytuacje, w których jeden byłby lepszy od drugiego w ramach tego samego tematu?

Wolę haki, ponieważ są bardziej elastyczne: możesz podłączyć się do nich z functions.phppliku motywu , ale także z wtyczek. Staram się wkładać tyle wtyczek do wtyczek, aby motywy zawierały głównie elementy układu.

Jeśli używasz haka akcji, nadal można go używać get_template_part() w tym module obsługi haka . To daje najlepsze z obu światów. Prawdopodobnie możesz nawet utworzyć domyślny hook, który wywołuje get_template_part(), aby ludzie, którzy nie mają dużego doświadczenia z kodowaniem, mogli dodawać dodatkowe pliki, a inni mogliby usunąć ten hook, jeśli tego nie chcą.

Jeśli chodzi o wydajność: get_template_part()używa ( wlocate_template() ) file_exists()jeden, dwa lub cztery razy (w zależności od tego, jak to nazywasz). Wygląda na file_exists()to, że jest bardzo szybki i wykorzystuje buforowanie w PHP, a może nawet w systemie operacyjnym. Więc to chyba nie jest problem.

Powiedziałbym, że główną różnicą jest czytelność. Jeśli zobaczysz kilka dobrze nazwanych części szablonu, możesz łatwo zrozumieć, co się dzieje. Jeśli widzisz tylko hak, musisz przeszukać resztę motywu, aby ustalić, co jest do niego przymocowane.

Jest (stosunkowo) łatwo usunąć funkcję z zaczepu w motywie potomnym, ale o wiele trudniej jest zignorować niechciany szablon nadrzędny.

Zasadniczo praca z hakami jest bliższa stronie PHP, a praca z szablonami bliżej strony HTML. Używam motywu nadrzędnego Hybrid, który jest bardzo zorientowany na haczyki. To błogość, dopóki nie musisz pozbyć się szablonu jakiegoś rodzica.

Dla użytkowników, którzy nie są obeznani z technologią, żadna z tych opcji nie jest bardzo przyjemna. Dlaczego i tak musieliby zadzierać z takimi motywami wewnętrznymi?

PS zwraca również uwagę na problemy z wydajnością. Rzeczy z hakami zdarzają się w pamięci, rzeczy z szablonami wymagają wielu wyszukiwań na dysku. Zwłaszcza jeśli piszesz coś w swoim przykładzie.

PPS nie preferencje wszystkich ... ale zamiast pisać od podstaw motyw nadrzędny, dlaczego nie wziąć istniejącego motywu nadrzędnego i udostępnić użytkownikowi prosty motyw podrzędny?