Ett alternativ till WordPress template_redirect Hook
Majoriteten av det arbete jag gör just nu fokuserar på anpassade plugins eller verktyg som fungerar ovanpå WordPress.
Om du skulle föreställa dig hur många av projekten som jag bygger är sammansatta, skulle du granska WordPress (och allt vad det innebär) som grund, och då har koden ett lager som kommunicerar med WordPress, och som kan kommunicera med API:er från tredje part.
När du gör detta, men det finns ofta en front-end-komponent som kräver att jag återger information till mallar. Även om det inte är svårt att bygga mallar för WordPress (även om jag önskar att vi hade lite mer än malltaggar – till exempel en mallmotor, det är ett annat inlägg), tycker jag att det är värt att titta på ett par sätt som vi kan hantera anpassade mallar som vi buntade med plugins.
En av de första frågorna som ofta ställs med detta uttalande är dock
Varför skulle du inkludera anpassade mallar i ett plugin?
Och jag får det på vissa nivåer.
- Att behålla mallar i ett plugin suddar ut gränserna lite mellan teman och plugins, särskilt när du lämnar teman för presentation och plugins för affärslogik,
- Att be användare att kopiera temafiler från en plats till en annan är dålig användarupplevelse.
Men det finns några motbevisningar eller kanske direkta undantag från ovanstående fall.
WordPress template_redirect Hook
Innan jag pratar om WordPress template_redirect – kroken vill jag prata lite om punkterna som nämns ovan.
1 Mallar i plugins
Om du bygger ett anpassat plugin som gränssnitt både med WordPress och ett tredjeparts-API eller som använder någon typ av kombination av arkiv, fabriker, modeller och vyer, måste du visa denna information på framsidan -slut, och det måste vara temaagnostiskt.
Detta betyder inte att någon inte kan utforma elementen på sidan eller inkludera mallen i sitt arbete, men det betyder att plugin-programmet ska ge en grundläggande nivå av information som återges till användaren.
2 Att be användare att kopiera filer är dåligt
Kommer du ihåg sloganen som Apple en gång och ofta utropade som " Det fungerar bara? " Även om det kanske inte är något de sprutar ut lika mycket som de en gång gjorde (om alls längre), så gillar jag tanken på att "bara jobba" för användaren, och det är något som jag försöker sträva efter i min arbete.
Så när det kommer till att skapa anpassade mallar eller vyer för plugins vill jag inte be användaren att behöva kopiera filer. Jag vill bara att de ska:
- installera plugin,
- klicka på aktivera.
Och det är allt. Resten ska vara antingen självklart eller väldokumenterat.
Tillbaka till Hook
Okej så låt oss för ett ögonblick anta att vi har byggt en plugin, plugin innehåller flera grundläggande mallar (eller vyer beroende på språket du använder) och att mallarna måste skrivas till roten av det aktiva temats katalog.
Du kan använda template_redirect- kroken (och många populära plugins gör det). Du kan läsa mer om det här, men kärnan i det är som följer:
Denna åtgärdshook körs precis innan WordPress bestämmer vilken mallsida som ska laddas. Det är en bra krok att använda om du behöver göra en omdirigering med full kännedom om innehållet som har efterfrågats.
Och för att vara tydlig, jag avråder inte användningen av denna krok. Jag erbjuder bara ett alternativ. Och det är detta (som det ska fungera enligt följande):
- aktivera plugin,
- hitta det aktiva temat,
- om de inte redan finns, kopiera mallfilerna från plugin-programmet till det aktiva temats rotkatalog
Det sista steget är avgörande eftersom om mallfilerna existerar är det viktigt att inte skriva över dem, främst eftersom användaren kunde ha skrivit sina anpassningar.
Med det sagt, så här kan du göra det i en enda funktion (komplett med kommentarer för att visa vad du använder).
<?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);
}
}
Observera att detta använder flera PHP-funktioner. Nämligen:
Alla som jag tycker är praktiska och viktiga att känna till oavsett i vilken natur du använder dem.
Stöder värdar detta?
Vissa värdar gör det. Jag vet att värdar som WPEngine inte gör det och det här är inte heller en kritik av värden. Vissa gör det av säkerhetsskäl; andra tillåter det men det betyder inte att de är mindre säkra – det betyder bara att de har sin infrastruktur inställd på ett annat sätt.
I slutändan visar detta att det finns andra sätt att göra mallar tillgängliga för användare när ett plugin används, men det är inte det enda sättet, och det kanske inte alltid fungerar.
Att ha alternativ är dock bra, särskilt om du föredrar en specifik arkitektur i ditt plugin framför en annan.