Uma alternativa ao gancho template_redirect do WordPress
A maior parte do trabalho que faço agora se concentra em plugins ou utilitários personalizados que funcionam em cima do WordPress.
Se você conceituar quantos dos projetos que eu construo são reunidos, você revisaria o WordPress (e tudo o que isso implica) como base, e então o código tem uma camada que se comunica com o WordPress e que pode se comunicar com APIs de terceiros.
Ao fazer isso, porém, geralmente há um componente de front-end que exige que eu renderize informações em modelos. Embora a construção de templates para WordPress não seja inerentemente difícil (embora eu deseje ter um pouco mais do que tags de template – como um mecanismo de template, esse é outro post), acho que vale a pena olhar para algumas maneiras de lidar com customização templates que juntamos com plugins.
Uma das primeiras perguntas que muitas vezes são levantadas com essa declaração, no entanto, é
Por que você incluiria modelos personalizados em um plugin?
E eu entendo isso em alguns níveis.
- Manter templates em um plugin borra um pouco as linhas entre temas e plugins, especialmente quando você deixa temas para apresentação e plugins para lógica de negócios,
- Pedir aos usuários que copiem arquivos de tema de um local para outro é uma experiência ruim para o usuário.
Mas há algumas refutações ou talvez exceções definitivas para os casos acima.
Gancho template_redirect do WordPress
Antes de falar sobre o gancho template_redirect do WordPress, quero falar um pouco sobre os pontos mencionados acima.
1 Modelos em Plugins
Se você estiver criando um plug-in personalizado que faça interface com o WordPress e uma API de terceiros ou que use algum tipo de combinação de repositórios, fábricas, modelos e visualizações, você precisará exibir essas informações na frente -end, e precisa ser independente do tema.
Isso não significa que alguém não possa estilizar os elementos da página ou incluir o modelo em seu trabalho, mas significa que o plug-in deve fornecer um nível básico de informação que é renderizado ao usuário.
2 Pedir aos usuários para copiar arquivos é ruim
Lembre-se do slogan que a Apple uma vez e muitas vezes divulgou como ” Simplesmente funciona? " Mesmo que não seja algo que eles falam tanto quanto antes (se é que mais), eu gosto da ideia de ter "apenas trabalho" para o usuário, e é algo que eu tento me esforçar no meu trabalhar.
Portanto, quando se trata de criar modelos ou visualizações personalizadas para plugins, não quero pedir ao usuário que copie arquivos. Eu só quero que eles:
- instale o plug-in,
- clique em ativar.
E é isso. O resto deve ser auto-evidente ou bem documentado.
De volta ao gancho
Ok, então vamos supor por um momento que nós construímos um plugin, o plugin inclui vários templates básicos (ou visualizações dependendo da linguagem que você usa) e que os templates precisam ser escritos na raiz do diretório do tema ativo.
Você pode usar o gancho template_redirect (e muitos plugins populares fazem isso). Você pode ler mais sobre isso aqui, mas a essência é a seguinte:
Esse gancho de ação é executado logo antes do WordPress determinar qual página de modelo carregar. É um bom gancho para usar se você precisar fazer um redirecionamento com pleno conhecimento do conteúdo que foi consultado.
E, para ser claro, não estou dissuadindo o uso deste gancho. Estou apenas oferecendo uma alternativa. E é isso (como deve funcionar da seguinte forma):
- ativar o plug-in,
- localize o tema ativo,
- se eles ainda não existirem, copie os arquivos de modelo do plugin para o diretório raiz do tema ativo
A etapa final é crítica porque, se os arquivos de modelo existirem, é importante não sobrescrevê-los principalmente porque o usuário pode ter escrito suas personalizações.
Com isso dito, veja como você pode fazer isso em uma única função (completa com comentários para mostrar o que você está 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);
}
}
Observe que isso usa várias funções do PHP. Nomeadamente:
Tudo o que eu acho que é útil e importante saber, independentemente da natureza em que você está usando.
Os hosts suportam isso?
Alguns anfitriões sim. Eu sei que hosts como o WPEngine não e isso também não é uma crítica ao host. Alguns fazem isso por razões de segurança; outros permitem, mas isso não significa que sejam menos seguros – significa apenas que têm sua infraestrutura configurada de forma diferente.
Em última análise, isso mostra que existem outras maneiras de disponibilizar modelos para os usuários quando um plug-in está sendo usado, mas não é a única maneira e nem sempre funciona.
No entanto, ter opções é bom, especialmente se você preferir uma arquitetura específica em seu plugin em vez de outra.