Une alternative au hook WordPress template_redirect
La majorité du travail que je fais actuellement se concentre sur des plugins personnalisés ou des utilitaires qui fonctionnent sur WordPress.
Si vous deviez conceptualiser le nombre de projets que je construis sont assemblés, vous examineriez WordPress (et tout ce qu’il implique) comme base, puis le code a une couche qui communique avec WordPress, et qui peut communiquer avec des API tierces.
Lorsque vous faites cela, cependant, il y a souvent un composant frontal qui nécessite que je rende les informations dans des modèles. Bien que la création de modèles pour WordPress ne soit pas intrinsèquement difficile (bien que j’aurais aimé avoir un peu plus que des balises de modèle – comme un moteur de modèles, c’est un autre article), je pense qu’il vaut la peine d’examiner quelques façons de gérer la personnalisation modèles que nous avons fournis avec des plugins.
L’une des premières questions qui est souvent soulevée avec cette déclaration, cependant, est
Pourquoi incluriez-vous des modèles personnalisés dans un plugin ?
Et je comprends à certains niveaux.
- Garder des modèles dans un plugin brouille un peu les frontières entre les thèmes et les plugins, en particulier lorsque vous laissez des thèmes pour la présentation et des plugins pour la logique métier,
- Demander aux utilisateurs de copier des fichiers de thème d’un emplacement à un autre est une mauvaise expérience utilisateur.
Mais il y a quelques réfutations ou peut-être des exceptions pures et simples aux cas ci-dessus.
Crochet template_redirect WordPress
Avant de parler du hook WordPress template_redirect, je veux parler un peu des points mentionnés ci-dessus.
1 Modèles dans les plugins
Si vous créez un plugin personnalisé qui s’interface à la fois avec WordPress et une API tierce ou qui utilise un type de combinaison de référentiels, d’usines, de modèles et de vues, vous devrez afficher ces informations sur le devant -end, et il doit être indépendant du thème.
Cela ne signifie pas que quelqu’un ne peut pas styliser les éléments de la page ou inclure le modèle dans son travail, mais cela signifie que le plugin doit fournir un niveau d’informations de base qui est rendu à l’utilisateur.
2 Demander aux utilisateurs de copier des fichiers est mauvais
Rappelez-vous le slogan qu’Apple a une fois et souvent présenté comme " Ça marche, tout simplement ? " Même si ce n’est peut-être pas quelque chose dont ils parlent autant qu’avant (voire plus du tout), j’aime l’idée d’avoir "juste du travail" pour l’utilisateur, et c’est quelque chose que j’essaie d’atteindre dans mon travailler.
Ainsi, lorsqu’il s’agit de créer des modèles ou des vues personnalisés pour les plugins, je ne veux pas demander à l’utilisateur de devoir copier des fichiers. Je veux juste qu’ils :
- installer le plugin,
- cliquez sur activer.
Et c’est tout. Le reste doit être évident ou bien documenté.
Retour au crochet
Bon, supposons un instant que nous ayons construit un plugin, le plugin comprend plusieurs modèles de base (ou vues selon le jargon que vous utilisez) et que les modèles doivent être écrits à la racine du répertoire du thème actif.
Vous pouvez utiliser le hook template_redirect (et de nombreux plugins populaires le font). Vous pouvez en savoir plus à ce sujet ici, mais l’essentiel est le suivant :
Ce hook d’action s’exécute juste avant que WordPress ne détermine la page de modèle à charger. C’est un bon crochet à utiliser si vous avez besoin de faire une redirection en toute connaissance du contenu qui a été interrogé.
Et, pour être clair, je ne dissuade pas l’utilisation de ce crochet. Je propose juste une alternative. Et c’est ça (car cela devrait fonctionner comme suit):
- activer le plugin,
- localiser le thème actif,
- s’ils n’existent pas déjà, copiez les fichiers de modèle du plugin dans le répertoire racine du thème actif
La dernière étape est critique car si les fichiers de modèle existent, il est important de ne pas les écraser principalement car l’utilisateur aurait pu écrire ses personnalisations.
Cela dit, voici comment vous pouvez le faire dans une seule fonction (avec des commentaires pour montrer ce que vous utilisez).
<?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);
}
}
Notez que cela utilise plusieurs fonctions PHP. À savoir:
Je pense que tous ces éléments sont pratiques et importants à connaître, quelle que soit la nature dans laquelle vous les utilisez.
Les hébergeurs prennent-ils cela en charge ?
Certains hôtes le font. Je sais pertinemment que les hôtes comme WPEngine ne le font pas et ce n’est pas non plus une critique de l’hôte. Certains le font pour des raisons de sécurité ; d’autres l’autorisent, mais cela ne signifie pas qu’ils sont moins sécurisés – cela signifie simplement que leur infrastructure est configurée différemment.
En fin de compte, cela montre qu’il existe d’autres moyens de rendre les modèles disponibles pour les utilisateurs lorsqu’un plugin est utilisé, mais ce n’est pas le seul moyen, et cela peut ne pas toujours fonctionner.
Cependant, avoir des options est une bonne chose, surtout si vous préférez une architecture spécifique dans votre plugin plutôt qu’une autre.