Italiano
Español
Русскийget_template_part vs action hooks în teme
Mi se pare că ambele metode oferă posibilitatea utilizatorului final de a modifica o temă fără a edita fișierele temei (prin teme copil).
Întrebarea mea este: există vreo metodă preferată față de cealaltă?
De exemplu, ia tema la care lucrez acum. Încerc să decid dacă să folosesc părți de șablon sau hook-uri.
<?php get_template_part('before_sitecontainer' ); ?>
<div id="sitecontainer" class="sitecontainer" <?php //închis în 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><!-- sfârșit div topcontainer -->
<?php get_template_part( 'after_topcontainer' ); ?>
Codul de mai sus permite utilizatorului temei să înlocuiască orice secțiune a codului existent prin simpla creare a unui fișier cu numele corespunzător în folderul temei copil, precum și să adauge cod nou înainte/după fiecare secțiune preexistentă prin aceeași metodă - fișierele before/after pentru părțile de șablon nu există în tema părinte și sunt acolo doar pentru a le permite să insereze cod - iar această metodă nu necesită să înțeleagă hook-uri/filtre pentru a realiza acest lucru.
Desigur, aș putea obține același lucru folosind hook-uri și filtre.
Există vreun avantaj în folosirea hook-urilor/filtrelor în schimb? Ținând cont de faptul că publicul țintă care va folosi această temă este cu siguranță nu priceput la cod. Le pot oferi instrucțiuni relativ simple pe care le pot urma pentru a utiliza metoda cu șabloane, dar cu siguranță i-aș confunda groaznic cu hook-uri.
Sau există situații în care una dintre metode ar fi mai bună decât cealaltă în cadrul aceleiași teme?
Asta are sens. O parte din abordarea mea de design a fost să elimin necesitatea pluginurilor în majoritatea situațiilor comune, păstrând totuși posibilitatea de a le folosi pentru cei care doresc. Clientul meu țintă știe foarte puțin despre WordPress sau pluginuri, nu este calificat să distingă pluginurile bune de cele rele (principalul punct slab al pluginurilor, după părerea mea) și nu dorește să se ocupe de actualizarea și gestionarea multiplelor componente software. Așadar, trebuie să integrez multă funcționalitate direct în teme pentru a oferi ceea ce doresc ei: o soluție simplă de utilizat, simplu de întreținut, totul într-un singur loc.
Lemon Bacon
Da, are sens și face parte din ceea ce încercam să realizez cu codul exemplu.
Lemon Bacon
Ignorarea unui template părinte ar fi la fel de ușoară precum crearea unui fișier de template gol pentru a-l înlocui, aș fi crezut. Mult mai ușor decât să te complici cu hook-uri (și deci PHP) pentru utilizatorul nepasionat de tehnologie. Deși pentru cineva cu experiență, hook-urile ar fi mult mai ușoare. În ceea ce privește motivul, există întotdeauna cei care doresc să personalizeze, chiar tu ai recunoscut că o faci. În ceea ce privește motivul pentru care creez o temă, aceasta este direcția în care doresc să îmi duc afacerea. Construirea în jurul afacerii altcuiva nu pare foarte sigură pentru viitor, de asemenea pentru că, IMO, majoritatea temelor existente lasă de dorit. Cred că pot face mai bine.
Lemon Bacon
Argumente bune în ceea ce privește problemele de performanță. Totuși, deoarece WordPress a fost conceput să funcționeze cu get_template_part, aș fi crezut că nu ar fi o problemă atât de mare de performanță. Are cineva benchmark-uri pentru asta?
Lemon Bacon
Înțeleg ce vrei să spui despre ignorarea unei părți de template. Nu este atât de ușor pe cât am crezut
Lemon Bacon
De fapt, este la fel de simplu ca și plasarea unui fișier de șablon gol în folderul child, atâta timp cât acesta se află în rădăcina folderului. Dificultatea apare atunci când fișierele de șablon se află în subfoldere ale folderului temei părinte/child.
Lemon Bacon
De fapt, nici subfolderele nu reprezintă o problemă. Pur și simplu am denumit folderul greșit (un semn clar că lucrez prea târziu, LOL). Pentru a suprascrie o parte a șablonului, este nevoie doar de un fișier cu același nume și în aceeași cale în child tema, ca în tema părinte.
Lemon Bacon