Una alternativa al gancho template_redirect de WordPress
La mayoría del trabajo que hago en este momento se enfoca en complementos personalizados o utilidades que funcionan sobre WordPress.
Si tuviera que conceptualizar cuántos de los proyectos que construyo están juntos, revisaría WordPress (y todo lo que implica) como base, y luego el código tiene una capa que se comunica con WordPress, y que puede comunicarse con API de terceros.
Sin embargo, al hacer esto, a menudo hay un componente frontal que requiere que represente la información en plantillas. Aunque la creación de plantillas para WordPress no es intrínsecamente difícil (aunque desearía que tuviéramos algo más que etiquetas de plantilla, como un motor de plantillas, esa es otra publicación), creo que vale la pena ver un par de formas en que podemos manejar plantillas que empaquetamos con complementos.
Sin embargo, una de las primeras preguntas que suele surgir con esta declaración es
¿Por qué incluiría plantillas personalizadas en un complemento?
Y lo entiendo en algunos niveles.
- Mantener las plantillas en un complemento difumina un poco las líneas entre temas y complementos, especialmente cuando deja temas para presentación y complementos para lógica comercial.
- Pedir a los usuarios que copien archivos de temas de una ubicación a otra es una mala experiencia para el usuario.
Pero hay algunas refutaciones o quizás excepciones absolutas a los casos anteriores.
Gancho de WordPress template_redirect
Antes de hablar sobre el gancho template_redirect de WordPress, quiero hablar un poco sobre los puntos mencionados anteriormente.
1 Plantillas en Complementos
Si está creando un complemento personalizado que interactúa tanto con WordPress como con una API de terceros o que usa algún tipo de combinación de repositorios, fábricas, modelos y vistas, entonces necesitará mostrar esta información en el frente. -end, y debe ser independiente del tema.
Esto no significa que alguien no pueda diseñar los elementos de la página o incluir la plantilla en su trabajo, pero sí significa que el complemento debe proporcionar un nivel básico de información que se presenta al usuario.
2 Pedir a los usuarios que copien archivos es malo
¿Recuerdas el eslogan que Apple solía promocionar como » simplemente funciona? " Aunque puede que no sea algo que digan tanto como antes (si es que lo hacen, ya), me gusta la idea de que "simplemente funcione" para el usuario, y es algo por lo que trato de esforzarme en mi trabajar.
Entonces, cuando se trata de crear plantillas personalizadas o vistas para complementos, no quiero pedirle al usuario que tenga que copiar archivos. Solo quiero que ellos:
- instalar el complemento,
- haga clic en activar.
Y eso es. El resto debe ser evidente o estar bien documentado.
De vuelta al gancho
De acuerdo, supongamos por un momento que hemos creado un complemento, el complemento incluye varias plantillas básicas (o vistas según la jerga que use) y que las plantillas deben escribirse en la raíz del directorio del tema activo.
Puede usar el gancho template_redirect (y muchos complementos populares lo hacen). Puede leer más sobre esto aquí, pero la esencia es la siguiente:
Este enlace de acción se ejecuta justo antes de que WordPress determine qué página de plantilla cargar. Es un buen enlace para usar si necesita hacer una redirección con pleno conocimiento del contenido que se ha consultado.
Y, para ser claros, no estoy disuadiendo el uso de este gancho. Solo ofrezco una alternativa. Y eso es esto (ya que debería funcionar de la siguiente manera):
- activar el complemento,
- localizar el tema activo,
- si aún no existen, copie los archivos de plantilla del complemento al directorio raíz del tema activo
El paso final es fundamental porque si los archivos de plantilla existen, entonces es importante no sobrescribirlos principalmente porque el usuario podría haber escrito sus personalizaciones.
Dicho esto, así es como puede hacerlo en una sola función (completa con comentarios para mostrar lo que 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);
}
}
Tenga en cuenta que esto utiliza varias funciones de PHP. A saber:
Todos los cuales creo que son útiles e importantes para saber, independientemente de la naturaleza en la que los esté utilizando.
¿Los anfitriones admiten esto?
Algunos anfitriones lo hacen. Sé con certeza que los hosts como WPEngine no lo hacen y esto tampoco es una crítica del host. Algunos lo hacen por razones de seguridad; otros lo permiten, pero eso no significa que sean menos seguros, solo significa que tienen su infraestructura configurada de manera diferente.
En última instancia, esto demuestra que hay otras formas de hacer que las plantillas estén disponibles para los usuarios cuando se usa un complemento, pero no es la única forma y es posible que no siempre funcione.
Sin embargo, tener opciones es bueno, especialmente si prefiere una arquitectura específica en su complemento sobre otra.