Un’alternativa al WordPress template_redirect Hook
La maggior parte del lavoro che faccio in questo momento si concentra su plug-in o utilità personalizzati che funzionano su WordPress.
Se dovessi concettualizzare quanti dei progetti che costruisco sono messi insieme, esamineresti WordPress (e tutto ciò che comporta) come base, e quindi il codice ha un livello che comunica con WordPress e che può comunicare con API di terze parti.
Quando si esegue questa operazione, tuttavia, c’è spesso un componente front-end che richiede il rendering delle informazioni in modelli. Sebbene la creazione di modelli per WordPress non sia intrinsecamente difficile (anche se vorrei che avessimo qualcosa in più rispetto ai tag dei modelli, come un motore di creazione di modelli, questo è un altro post), penso che valga la pena esaminare un paio di modi in cui possiamo gestire modelli che abbiamo fornito in bundle con i plugin.
Tuttavia, una delle prime domande che viene spesso sollevata con questa affermazione è
Perché dovresti includere modelli personalizzati in un plug-in?
E lo capisco su alcuni livelli.
- Mantenere i modelli in un plug-in offusca un po’ i confini tra temi e plug-in, soprattutto quando si lasciano temi per la presentazione e plug-in per la logica aziendale,
- Chiedere agli utenti di copiare i file del tema da una posizione all’altra è un’esperienza utente negativa.
Ma ci sono alcune confutazioni o forse eccezioni a titolo definitivo ai casi di cui sopra.
WordPress template_redirect Hook
Prima di parlare dell’hook template_redirect di WordPress, voglio parlare un po’ dei punti sopra menzionati.
1 Modelli nei plugin
Se stai creando un plug-in personalizzato che si interfaccia sia con WordPress che con un’API di terze parti o che utilizza un qualche tipo di combinazione di repository, fabbriche, modelli e viste, dovrai visualizzare queste informazioni in primo piano -end, e deve essere indipendente dal tema.
Ciò non significa che qualcuno non possa definire lo stile degli elementi sulla pagina o includere il modello nel proprio lavoro, ma significa che il plug-in dovrebbe fornire un livello base di informazioni che viene visualizzato all’utente.
2 Chiedere agli utenti di copiare i file è sbagliato
Ricordi lo slogan che Apple una volta e spesso pubblicizzava come " Funziona e basta? " Anche se potrebbe non essere qualcosa che sputa fuori tanto quanto una volta (se non del tutto, più), mi piace l’idea di avere "solo lavoro" per l’utente, ed è qualcosa a cui cerco di lottare nel mio opera.
Quindi, quando si tratta di creare modelli o viste personalizzati per i plug-in, non voglio chiedere all’utente di dover copiare i file. Voglio solo che:
- installa il plugin,
- fare clic su attiva.
E questo è tutto. Il resto dovrebbe essere ovvio o ben documentato.
Torna al gancio
Va bene, quindi supponiamo per un momento di aver creato un plug-in, il plug-in include diversi modelli di base (o viste a seconda del gergo che usi) e che i modelli devono essere scritti nella radice della directory del tema attivo.
Puoi usare l’ hook template_redirect (e molti plugin popolari lo fanno). Puoi leggere di più a riguardo qui, ma il succo è il seguente:
Questo hook di azione viene eseguito appena prima che WordPress determini quale pagina del modello caricare. È un buon hook da utilizzare se è necessario eseguire un reindirizzamento con piena conoscenza del contenuto che è stato interrogato.
E, per essere chiari, non sto dissuadendo l’uso di questo gancio. Sto solo offrendo un’alternativa. E questo è questo (poiché dovrebbe funzionare come segue):
- attivare il plugin,
- individuare il tema attivo,
- se non esistono già, copia i file modello dal plug-in nella directory principale del tema attivo
Il passaggio finale è fondamentale perché se i file modello esistono, è importante non sovrascriverli principalmente perché l’utente potrebbe aver scritto le proprie personalizzazioni.
Detto questo, ecco come puoi farlo in un’unica funzione (completa di commenti per mostrare cosa stai usando).
<?php
add_action('plugins_loaded', __NAMESPACE__. 'acmeCopyTemplates');
/**
* Copies the template files from the `assets/templates` directory to the root directory
* of the currently active theme (if they do not already exist).
*/
function acmeCopyTemplates()
{
// Find the currently active theme.
$activeThemeDir = get_template_directory();
/**
* Read all of the template files from assets/templates into an array but
* exclude the '.' and the '..' from the array.
*/
$templates = array_slice(scandir(dirname(__FILE__).'/assets/templates'), 2);
/**
* Now copy all of these files to the active theme directory.
* If the file already exists, then don't do it.
*/
foreach ($templates as $template) {
if (!file_exists($destination = trailingslashit($activeThemeDir).$template)) {
continue;
}
$source = dirname(__FILE__).'/assets/templates/'.$template;
$destination = trailingslashit($activeThemeDir).$template;
copy($source, $destination);
}
}
Nota che questo utilizza diverse funzioni PHP. Vale a dire:
Tutto ciò che penso sia utile e importante da sapere indipendentemente dalla natura in cui li stai usando.
Gli host lo supportano?
Alcuni host lo fanno. So per certo che host come WPEngine non lo fanno e questa non è nemmeno una critica all’host. Alcuni lo fanno per motivi di sicurezza; altri lo consentono, ma ciò non significa che siano meno sicuri, significa solo che la loro infrastruttura è configurata in modo diverso.
In definitiva, questo dimostra che ci sono altri modi per rendere disponibili i modelli agli utenti quando viene utilizzato un plug-in, ma non è l’unico modo e potrebbe non funzionare sempre.
Tuttavia, avere opzioni è positivo, soprattutto se preferisci un’architettura specifica nel tuo plug-in rispetto a un’altra.