La maggior parte del lavoro che faccio in questo momento si concentra su plug-in o utilit\u00e0 personalizzati che funzionano su WordPress.<\/p>\n
Se dovessi concettualizzare quanti dei progetti che costruisco sono messi insieme, esamineresti WordPress (e tutto ci\u00f2 che comporta) come base, e quindi il codice ha un livello che comunica con WordPress e che pu\u00f2 comunicare con API di terze parti.<\/p>\n
Quando si esegue questa operazione, tuttavia, c’\u00e8 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\u00f9 rispetto ai tag dei modelli, come un motore di creazione di modelli, questo \u00e8 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.<\/p>\n
Tuttavia, una delle prime domande che viene spesso sollevata con questa affermazione \u00e8<\/p>\n
\nPerch\u00e9 dovresti includere modelli personalizzati in un plug-in?<\/p>\n<\/blockquote>\n
E lo capisco su alcuni livelli.<\/p>\n
\n
- 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,<\/li>\n
- Chiedere agli utenti di copiare i file del tema da una posizione all’altra \u00e8 un’esperienza utente negativa.<\/li>\n<\/ol>\n
Ma ci sono alcune confutazioni o forse eccezioni a titolo definitivo ai casi di cui sopra.<\/p>\n
WordPress template_redirect Hook<\/h2>\n
Prima di parlare dell’hook template_redirect<\/a> di WordPress, voglio parlare un po’ dei punti sopra menzionati.<\/p>\n
1 Modelli nei plugin<\/h3>\n
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.<\/p>\n
Ci\u00f2 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.<\/p>\n
2 Chiedere agli utenti di copiare i file \u00e8 sbagliato<\/h3>\n
Ricordi lo slogan che Apple una volta e spesso pubblicizzava come " Funziona e basta?<\/a><\/strong> " Anche se potrebbe non essere qualcosa che sputa fuori tanto quanto una volta (se non del tutto, pi\u00f9), mi piace l’idea di avere "solo lavoro" per l’utente, ed \u00e8 qualcosa a cui cerco di lottare nel mio opera.<\/p>\n
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:<\/p>\n
\n
- installa il plugin,<\/li>\n
- fare clic su attiva.<\/li>\n<\/ol>\n
E questo \u00e8 tutto. Il resto dovrebbe essere ovvio o ben documentato.<\/p>\n
Torna al gancio<\/h2>\n
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.<\/p>\n
Puoi usare l’ hook template_redirect (e molti plugin popolari lo fanno).<\/a><\/strong> Puoi leggere di pi\u00f9 a riguardo qui, ma il succo \u00e8 il seguente:<\/p>\n
\nQuesto hook di azione viene eseguito appena prima che WordPress determini quale pagina del modello caricare. \u00c8 un buon hook da utilizzare se \u00e8 necessario eseguire un reindirizzamento con piena conoscenza del contenuto che \u00e8 stato interrogato.<\/p>\n<\/blockquote>\n
E, per essere chiari, non sto dissuadendo l’uso di questo gancio. Sto solo offrendo un’alternativa. E questo \u00e8 questo (poich\u00e9 dovrebbe funzionare come segue):<\/p>\n
\n
- attivare il plugin,<\/li>\n
- individuare il tema attivo,<\/li>\n
- se non esistono gi\u00e0, copia i file modello dal plug-in nella directory principale del tema attivo<\/li>\n<\/ol>\n
Il passaggio finale \u00e8 fondamentale perch\u00e9 se i file modello esistono, \u00e8 importante non sovrascriverli principalmente perch\u00e9 l’utente potrebbe aver scritto le proprie personalizzazioni.<\/p>\n
Detto questo, ecco come puoi farlo in un’unica funzione<\/a><\/strong> (completa di commenti per mostrare cosa stai usando).<\/p>\n
<?php\n\nadd_action('plugins_loaded', __NAMESPACE__. 'acmeCopyTemplates');\n\/**\n * Copies the template files from the `assets\/templates` directory to the root directory \n * of the currently active theme (if they do not already exist).\n *\/\nfunction acmeCopyTemplates()\n{\n \/\/ Find the currently active theme.\n $activeThemeDir = get_template_directory();\n\n \/**\n * Read all of the template files from assets\/templates into an array but\n * exclude the '.' and the '..' from the array.\n *\/\n $templates = array_slice(scandir(dirname(__FILE__).'\/assets\/templates'), 2);\n\n \/**\n * Now copy all of these files to the active theme directory.\n * If the file already exists, then don't do it.\n *\/\n foreach ($templates as $template) {\n if (!file_exists($destination = trailingslashit($activeThemeDir).$template)) {\n continue;\n }\n\n $source = dirname(__FILE__).'\/assets\/templates\/'.$template;\n $destination = trailingslashit($activeThemeDir).$template;\n\n copy($source, $destination);\n }\n}\n<\/code><\/pre>\nNota che questo utilizza diverse funzioni PHP. Vale a dire:<\/p>\n
\n
- fetta_array<\/a><\/strong><\/li>\n
- scandir<\/a><\/strong><\/li>\n
- dirname<\/a><\/strong><\/li>\n
- il file esiste<\/a><\/strong><\/li>\n
- copia<\/a><\/strong><\/li>\n<\/ul>\n
Tutto ci\u00f2 che penso sia utile e importante da sapere indipendentemente dalla natura in cui li stai usando.<\/p>\n
Gli host lo supportano?<\/h2>\n