Tutto quello che devi sapere sulla funzione get_template_part() di WordPress

Una volta ho letto che il modo migliore per imparare a programmare è leggere il codice che altri hanno scritto. Dopotutto, la maggior parte del tempo che trascorri come sviluppatore probabilmente sarà la revisione, la rifinitura e la correzione del codice che tu o un altro sviluppatore avete scritto in passato. Questo è proprio il motivo per cui mi piace così tanto il software gratuito e open source: ci garantisce l'accesso al codice sorgente di ottimi strumenti e permette di imparare da essi.

Se sei interessato al mondo di WordPress (e immagino che tu lo sia, perché sei qui), il codice sorgente di WordPress Core o quello di Gutenberg sono due ottimi modi per diventare un professionista WordPress migliore e conoscere lo sviluppo di back-end e front-end.

Dalla prima versione di Gutenberg, abbiamo condiviso tutto ciò che abbiamo imparato finora sullo sviluppo del frontend. Così, ad esempio, abbiamo pubblicato una serie di post in cui ti abbiamo insegnato le basi di React, abbiamo visto come riutilizzare i componenti, abbiamo spiegato come estendere Gutenberg e abbiamo discusso di novità su JavaScript per scrivere un codice sorgente migliore, per citare alcuni articoli abbiamo scritto.

Bene, oggi cambieremo marcia e ci concentreremo di nuovo su WordPress Core. Come mai? Non lo so, forse perché l'annuncio del prossimo tema di Twenty Twenty-One uscito qualche giorno fa è la scusa perfetta per farlo?. Parliamo quindi di uno degli elementi più importanti durante la creazione di temi in WordPress: la funzione get_template_part .

Temi WordPress

Prima di tutto, esaminiamo come funzionano i temi di WordPress, vero? In sostanza, un tema è una raccolta di file che definisce la struttura HTML e gli stili CSS che il nostro sito utilizzerà.

Se pensi allo scheletro di qualsiasi pagina web, vedrai che lo stesso schema si ripete sempre:

• Iniziamo aprendo i tag html e head . È qui che aggiungiamo script, stili, meta tag e così via.
• Quindi chiudiamo il tag head e apriamo il tag body , che conterrà il contenuto visibile del nostro sito web.
  • Di solito, il corpo di una pagina include un'intestazione con il logo del web, un menu, ecc.
  • Poi arriva il contenuto stesso, che può essere una pagina, un articolo del blog, un elenco di post, il risultato di una ricerca e così via.
  • Infine, di solito termina con un piè di pagina.
• Infine, una volta che l'intera pagina è stata renderizzata, chiudiamo tutti i tag e il gioco è fatto.

Quindi, sì, sembra che ogni pagina web segua più o meno una struttura simile: c'è una parte comune (cioè intestazione, menu, piè di pagina...) e un'area specifica del contenuto (un post del blog, l'insieme di risultati che abbiamo ottenuto dopo una ricerca , un prodotto WooCommerce, ecc.).

Poiché ai programmatori non piace ripetere il codice e noi siamo (in generale) persone organizzate, i temi di WordPress seguono una struttura di file molto strutturata. In questo post che ho scritto qualche mese fa, hai una buona spiegazione dei diversi file in un tema, ma tieni presente che ci sono:

• un foglio di stile: style.css ,
• un file header.php per “aprire” la pagina web (ovvero, produrre in output il tag head e, normalmente, la parte iniziale del body comune a tutte le pagine),
• un altro file footer.php che “chiude” la pagina (cioè aggiunge il footer e chiude il tag html ), e
• molti file aggiuntivi per i diversi tipi di contenuto che vogliamo renderizzare.

Che cos'è la funzione get_template_part ea cosa serve?

La prima cosa da fare quando ti imbatti in una nuova funzionalità è l'opposto di quello che fai quando tuo padre ti chiede di aiutarlo a programmare il suo nuovo pulitore Roomba: leggi la documentazione. Quindi facciamolo con la nostra funzione guardando il Codex:

get_template_part fornisce un semplice meccanismo per i temi figlio per sovraccaricare sezioni di codice riutilizzabili nel tema.

Include la parte del modello denominata per un tema o se viene specificato un nome, verrà inclusa una parte specializzata. Se il tema non contiene alcun file {slug}.php, non verrà incluso alcun modello.

Il modello è incluso utilizzando require, non require_once, quindi è possibile includere la stessa parte del modello più volte.

Per il parametro $name, se il file è chiamato "{slug}-special.php", specificare "special".

Nota: get_template_part() fallisce silenziosamente

get_template_part docs su WordPress.org

Vedere? In meno di un minuto abbiamo ottenuto tutte le informazioni di cui avevamo bisogno. Ora sappiamo che questa funzione viene utilizzata per creare "parti riutilizzabili" in un tema (evitando così la duplicazione del codice) e lo fa in modo tale che un tema figlio possa adattarle. Abbiamo anche informazioni sui suoi parametri, sul suo funzionamento interno (usa la funzione require di PHP) e su cosa possiamo aspettarci da esso (fallisce silenziosamente).

Sfortunatamente, ci sono alcune cose che non sono ancora chiare, come questi file {slug}.php e {slug}-special.php che menziona. Quali sono? Cosa contengono? Cosa fanno? Molte domande difficili a cui rispondere guardando solo la documentazione, quindi è tempo di saltare agli esempi.

Come creare modelli parziali nel nostro tema

Diamo un'occhiata al tema Twenty Twenty-One per scoprire se utilizza questi "modelli parziali" e, se lo fa, che aspetto hanno e cosa dovresti fare per implementarli nel tuo tema.

Se leggi il mio post sulla gerarchia dei file di un tema WordPress, saprai che " index.php è il modello predefinito per il nostro tema. Viene utilizzato per eseguire il rendering di qualsiasi contenuto sul nostro sito Web, a condizione che tale contenuto non disponga di un modello specifico progettato per esso". Poiché questo è un modello predefinito, penso che sia una buona idea iniziare da lì. Questo è il contenuto di index.php nel tema Twenty Twenty-One:

 get_header(); if ( have_posts() ) { // Load posts loop. while ( have_posts() ) { the_post(); get_template_part( 'template-parts/content/content' ); } // Previous/next page navigation. twenty_twenty_one_the_posts_navigation(); } else { // If no content, include the "No posts found" template. get_template_part( 'template-parts/content/content-none' ); } get_footer();

Come puoi vedere, abbiamo tutte le parti che avevamo precedentemente commentato:

• Include l'intestazione usando get_header .
• Rende il contenuto stesso.
• Chiude la pagina con get_footer .

La cosa interessante qui, ovviamente, è l'area "contenuto" in index.php . Nello specifico, vediamo che abbiamo un piccolo controllo per sapere se stiamo vedendo o meno dei contenuti validi ( funzione have_posts del WordPress Loop) e, a seconda che abbiamo o meno, carichiamo un template parziale ( …/content ) o un altro ( …/content-none ).

Se ora diamo un'occhiata al template parziale content.php , vedremo approssimativamente quanto segue:

 <article <?php post_class(); ?>> <header class="entry-header alignwide"> … the_title( … ); … </header> <div class="entry-content"> <?php the_content( … ); wp_link_pages( … ); ?> </div> <footer class="entry-footer default-max-width"> <?php twenty_twenty_one_entry_meta_footer(); ?> </footer> … </article>

Abbastanza semplice, non è vero? Tutto ciò che abbiamo è un minuscolo modello progettato per il rendering di contenuti WordPress generici come, ad esempio, un post di un blog. Nota che lo scheletro HTML risultante non è altro che un tag article con un titolo, il suo contenuto e un piè di pagina, il tutto utilizzando tag template di WordPress per estrarre il contenuto effettivo.

Perché l'API di WordPress è fantastica

Anche se non sapevi che tutte queste funzioni esistono ( get_header , get_footer o la star di oggi: get_template_part ), sono abbastanza sicuro che avresti organizzato il tuo codice seguendo un approccio simile. Dopotutto, sembra abbastanza logico creare un modello per l'intestazione, un altro per il piè di pagina, un altro per il contenuto... e poi avere un file speciale o qualcosa che incolla tutto insieme, giusto?

Se avessi seguito un tale approccio, scommetto che il tuo file index.php sarebbe stato simile a questo:

 require_once 'header.php'; if ( have_posts() ) { // Load posts loop. while ( have_posts() ) { the_post(); require 'template-parts/content.php'; } // Previous/next page navigation. twenty_twenty_one_the_posts_navigation(); } else { // If no content, include the "No posts found" template. require 'template-parts/content-none.php'; } require_once 'footer.php';

che è molto simile a quello che abbiamo nel tema Twenty Twenty-One. Allora, a questo punto, potresti chiederti: cosa ci guadagno usando specifiche funzioni di WordPress? Non è lo stesso utilizzare direttamente un PHP require , soprattutto considerando che, secondo la documentazione di WordPress, è proprio quello che usano queste funzioni di supporto?

Bene, il motivo principale è effettivamente menzionato nella documentazione stessa: semplifica la creazione di temi figlio. Pertanto, se stai creando un tema figlio e usi get_template_part , WordPress cercherà il modello nel figlio e, in caso contrario, utilizzerà quello del genitore.

Ma non è tutto! Le funzioni di WordPress sono solitamente piene di filtri e azioni che consentono di adattare il risultato finale. Ad esempio, se osserviamo la funzione interna get_template_part nel file wp-includes/general-template.php :

 function get_template_part( … ) { do_action( "get_template_part_{$slug}", … ); … do_action( 'get_template_part', … ); if ( ! locate_template( … ) ) { return false; } }

vedremo che abbiamo un paio di azioni che i plugin e il tema stesso possono sfruttare. E se continuiamo a tirare il filo, saremo anche in grado di vedere come WordPress individua ( locate_template ) e carica il modello che finirà per utilizzare:

 function locate_template( $template_names, … ) { $located = ''; foreach ( $template_names as $name ) { if ( file_exists( STYLESHEETPATH . "/$name" ) ) { $located = …; // in child theme break; } else if ( file_exists( STYLESHEETPATH . "/$name" ) ) { $located = …; // in parent theme break; } else { … } } if ( $located ) { load_template( $located, $require_once, $args ); } return $located; }

Spero che il post di oggi ti abbia aiutato a capire un po' meglio come funzionano i temi di WordPress. Spero anche che ti abbia mostrato come conoscere WordPress leggendo la sua documentazione e sfogliando il suo codice sorgente. E se ti è piaciuto, condividilo con i tuoi amici e lasciaci un commento.

Immagine in primo piano di Joshua Sortino su Unsplash.