Share
Comme pour la création de thèmes WordPress - comme dans bien d'autres domaines -, il existe de bonnes et de mauvaises manières de le faire. Pour ceux d'entre nous qui veulent être des développeurs WordPress professionnels, pour ceux d'entre nous qui s'intéressent vraiment au travail que nous faisons, et pour ceux d'entre nous qui veulent que notre travail dure, alors nous devons penser à l'avenir nous organisons les fichiers et le code qui entre dans notre thème.
Oui, WordPress Codex propose un article fantastique sur le développement de thèmes, et je pense qu'il devrait être lu par quiconque se lance dans la construction de thèmes. - notamment thèmes premium - mais il existe certaines stratégies non couvertes que je trouve très utiles en ce qui concerne la création, la publication et la maintenance de thèmes au fil du temps.
Dans les deux prochains articles, nous allons examiner quelques stratégies qui vont un peu plus loin dans le développement de thèmes et qui nous aideront à structurer nos thèmes de manière à ce qu'ils ne suivent pas seulement les directives de WordPress. Codex, mais facilitera grandement la maintenance, la mise à jour et l’amélioration non seulement à mesure que WordPress avance, mais aussi à mesure que notre thème évolue..
La qualité de l'organisation des fichiers et du code nécessaire à la construction de thèmes WordPress est un sujet d'actualité.
Pour être clair, il s’agit d’une de ces choses dont les développeurs et les concepteurs adorent parler jusqu’à devenir quelque chose que les gens adorent détester. C’est-à-dire que d’autres commenteront souvent des thèmes de qualité médiocre disponibles pour WordPress et utiliseront ensuite cet argument pour expliquer pourquoi WordPress est une plate-forme médiocre non seulement pour les blogs, mais également pour d’autres raisons..
Ce n'est ni le propos ni l'argument de ce dont nous allons discuter ici, ni cela ne doit inspirer ce type de discussion dans les commentaires. Au lieu de cela, cette série en deux parties suppose ce qui suit:
Bien sûr, nous Tous ont nos propres façons de faire les choses, alors les recommandations qui sont partagées tout au long de cette série risquent de ne pas fonctionner avec votre flux de travail actuel. Peut-être que vous ne voulez pas changer - et c'est bien! - ou peut-être cherchez-vous un changement.
Indépendamment du cas, tout ce qui est partagé ici est basé sur l'expérience acquise dans la création et la maintenance de thèmes WordPress premium, ce qui facilite grandement leur maintenance dans le temps, à la fois d'un point de vue spécifique à un thème mais aussi d'un point de vue de la compatibilité WordPress..
L’un des aspects les plus difficiles du logiciel de construction n’exporte pas la version initiale (bien que est difficile en soi), mais il maintient le produit après sa sortie.
Cela implique non seulement de s'assurer que la base de code reste compatible avec l'infrastructure sous-jacente - dont nous parlerons dans la section suivante - mais également que les fichiers sont organisés de manière à être compris par l'équipe de développement. , qu'ils ont un niveau de cohésion et qu'ils ont une rime et une raison pour lesquelles ils sont nommés et placés de la manière dont ils sont.
Le Codex nous a appris qu’un certain nombre de fichiers constituent le cœur du thème. Cela inclut des modèles, un fichier de fonctions et au moins une feuille de style..
Mais que se passe-t-il lorsque votre thème devient plus compliqué? Dis que tu…
Tout ce qui précède peut être organisé proprement dans un répertoire de thèmes WordPress. Nous examinerons chacune d’elles avec un peu plus de détail et les raisons de leur placement dans le répertoire des thèmes dans l’espoir que cela rend le développement de thèmes plus propre et que cela facilite la maintenabilité..
Bien que dans de nombreux contextes, ceux-ci puissent être discutés indépendamment les uns des autres car ils sont responsables de différentes choses, leur structure organisationnelle au sein d'un thème est tellement similaire qu'il est logique de les regrouper..
Tout d'abord, en supposant que vous n'utilisez aucun type de pré-processeur CSS, il devrait exister un répertoire pour chacun de ces types de fichiers. C'est-à-dire que vous devriez avoir un css répertoire et un js répertoire (ou peut-être vous les appelez modes et javascript).
Quoi qu'il en soit, chaque type de fichier doit résider dans son propre répertoire. De là, vous pouvez alors utiliser functions.php enregistrer et mettre les fichiers en file d'attente selon les besoins. S'il s'agit d'un fichier utilisé dans le thème, vous l'enregistrerez sans condition..
Mais s'il s'agit d'un style ou d'un script utilisé uniquement sur un modèle, un type de publication ou même une partie du tableau de bord, vous pouvez, et devriez, mettre en file d'attente le fichier de manière conditionnelle.
Mais disons que vous sont en utilisant un pré-processeur. À ce stade, il ne vous restera plus que votre fichier pré-traité et vos fichiers post-traités. Selon la nature de votre projet, vous pouvez ou non tout réduire à un seul fichier..
je aurait faire des recommandations sur la façon de nommer les fichiers; Cependant, la diversité des thèmes, la manière dont les gens construisent leur travail et le problème qu’un thème donné tente de résoudre sont importants, ce qui nous éloigne de la portée de cette stratégie particulière..
Quoi qu’il en soit, si vous utilisez un pré-processeur, je vous recommande de créer un sous-répertoire dans le répertoire css et js des répertoires appelés dev (ou développement ou quoi que vous choisissiez de l'appeler). Dans ce répertoire, vous écrivez tous vos fichiers pré-traités, puis vous laissez l’outil de votre choix (qu’il s’agisse de CodeKit, de Grunt ou quelque chose du genre), d’exporter le (s) fichier (s) traité (s) dans la racine du fichier. css et js des annuaires.
De cette façon, vous avez toujours du code traité, combiné et / ou minifié et vous avez un répertoire contenant la source de ces fichiers. Lorsque vient le temps d’expédier le thème, vous avez non seulement les fichiers d’appel functions.php dans leurs répertoires respectifs, mais vous pouvez également exclure les fichiers. dev répertoire de la version finale de sorte que l'utilisateur final reçoive un paquet de thème plus petit et n'obtienne rien de plus qu'il n'en a besoin pour exécuter le thème.
Les parties de modèle sont souvent appelées des partiels (plus souvent dans d'autres langues que dans WordPress) et sont souvent appelées à l'aide de get_template_part dans WordPress. En bref, leur but est d’abriter du code répétitif qui peut être facilement incorporé dans plusieurs modèles..
Un exemple de ceci serait, disons, les méta-données post. Cela comprend généralement les informations suivantes:
Étant donné que ces informations peuvent exister dans plusieurs modèles (pensez à des publications uniques, des pages, des archives, etc.), il serait logique de les résumer en un seul fichier et de référencer ce fichier uniquement lorsque vous en aurez besoin..
Le fait est que les méta-données postales ne sont pas la seulement type d’information réutilisée dans un thème. À cette fin, identifiez les éléments essentiels réutilisés, résumez-les dans un fichier, puis créez un partiels annuaire.
À partir de là, nommez chaque partie du modèle en indiquant son contenu (tel que post-meta.php, gravatar.php, navigation.php, pagination.php, et ainsi de suite) et ensuite faire un appel au partiel dans le modèle où il est nécessaire.
Par exemple, dans les modèles post, page et archive, vous pouvez appeler get_template_part ('partials / post-meta');. Fait pour une lecture beaucoup plus facile et fait un unique endroit pour faire un changement plutôt que dans chaque modèle.
Si vous écrivez un thème internationalisé, si vous le publiez au public, vous devriez le faire, alors il existe un moyen très clair et net de le faire..
Tout d’abord, s’il s’agit d’un nouveau sujet pour vous, je vous recommande de lire l’article du Codex. Il vous dira tout ce que vous devez savoir sur la préparation des chaînes pour la traduction, les outils disponibles, etc..
Ensuite, je vous recommande de vous assurer que vous avez une place dédiée dans votre thème pour vos langues. De manière générale, je vous recommande de créer un répertoire dans votre thème nommé lang ou les langues puis laisser tomber le .po et .mo fichiers dans ledit répertoire. C’est aussi une pratique généralement acceptée et attendue au sein de la communauté WordPress en général..
Non seulement cela relègue les traductions à leur place dans la structure du thème, mais cela indique également aux autres où rechercher les traductions et où rechercher les fichiers qui offrent les chaînes à traduire..
Encore une fois, il s'agit de cohésion et de s'assurer que les choses d'utilité similaire sont regroupées de manière raisonnable.
En fonction de votre expérience en développement, les fonctions que vous utilisez pour faciliter le travail et séparer la logique métier de la logique de présentation (ou, dans la plupart des cas, de PHP simple à partir de HTML) sont appelées fonctions d'assistance ou fonctions utilitaires..
Pour les besoins de cette série, nous les désignerons comme des fonctions d’aide, mais sachez qu’ils sont tous identiques..
Mais cela soulève deux questions:
Accentsconagua
functions.php?functions.php, où vivent-ils?En bref, je suis d’avis que les aides et les services publics devraient ne pas vivre dans functions.php. Ma règle de base est la suivante: si le code que j’écris communique directement avec WordPress, tel que add_theme_support, alors il appartient à functions.php. Mais s'il y a du code que j'écris qui va exécuter une requête personnalisée pour récupérer des informations et restituer le résultat traité au modèle (ou à la partie de modèle), il appartient alors à une fonction d'assistance..
Tout comme WordPress, les balises de modèle ou les fonctions de modèle peuvent être appelées dans un modèle, telles que le contenu(), traiter les fonctions d'aide de la même manière: vous pouvez les appeler dans vos modèles et dans vos partiels, mais ils se trouvent dans leur propre fichier.
Puisque ces fonctions auxiliaires ne vivent pas dans functions.php, alors ils devraient vivre dans leur propre fichier et ce fichier devrait être référencé quelque part dans la base de code du thème, non? En plus de cela, il est également tout à fait possible que vous divisiez davantage vos assistants en plusieurs fichiers en fonction de la complexité de votre thème..
À cette fin, je recommande d’introduire un inc ou un comprend répertoire dans le noyau de votre thème. À partir de là, placez vos fichiers d’aide dans ce répertoire et include_once le fichier d'aide en haut de votre fichier de fonctions et les fonctions seront facilement et facilement accessibles dans le reste de votre thème.
Enfin, il est des fois où nous inclurons des bibliothèques tierces dans nos thèmes. Autrement dit, il s’agit d’outils mis au point par d’autres personnes, qui sont librement disponibles pour être utilisés et distribués, ce qui nous permet également de nous adapter facilement au travail des autres..
Alors, où devraient-ils vivre? Honnêtement, cela dépend du type de bibliothèque avec laquelle vous travaillez. Par exemple, les bibliothèques peuvent prendre la forme de CSS, JavaScript ou PHP. En tant que tel, il devrait y avoir une place pour cela:
lib répertoire dans votre js annuaire. Cela indique que le dossier contient des bibliothèques JavaScript.lib répertoire dans votre css annuaire. Encore une fois, cela indique que vous avez une bibliothèque CSS.lib répertoire à la racine du répertoire du thème. Cela indique qu'il ne s'agit ni de JavaScript ni de CSS et qu'il contribue à la fonctionnalité du thème principal (composé principalement d'appels de fonction PHP, de balises de modèle, etc.)..Bien sûr, j'ai aussi vu des développeurs créer un lib répertoire et ensuite créer js, css, et php sous-répertoires au sein du lib annuaire. C'est un peu une inversion des conseils fournis ci-dessus.
Ce n'est pas une mauvaise stratégie. La raison pour laquelle je n’aime pas cette approche est qu’elle répartit les fichiers JavaScript, CSS et PHP dans plusieurs répertoires du thème..
La création d'une structure de répertoires organisée n'en est qu'une partie. WordPress a une hiérarchie de modèles qui nécessite une certaine convention de nommage. Ne découle-t-il pas logiquement que nos fichiers personnalisés doivent faire de même?
De plus, qu'en est-il des conventions de nommage des fonctions? Est-ce qu'ils écho données ou revenir Les données? En plus de cela, nous savons que nous effectuons les appels de fonction API appropriés et que nous n'utilisons pas les fonctionnalités obsolètes de WordPress.?
Dans le prochain article, nous allons parler de tout cela ainsi que des outils que nous pouvons installer pour nous aider à éviter ces pièges. Nous verrons également comment ils fonctionnent et pourquoi, en plus des conventions de dénomination des fonctions, lors de la création de thèmes.
Pour l'instant, toutefois, nous avons couvert des stratégies d'organisation des fichiers qui devraient suffire à vous occuper jusqu'à la publication du prochain article de la série..
Comme d'habitude, si vous avez quelque chose à ajouter, merci de le faire dans les commentaires!
