Share
Dans le premier article de cette série, nous avons passé en revue certaines des stratégies disponibles pour organiser nos répertoires de thèmes WordPress afin de les rendre plus faciles à gérer..
Plus précisément, nous avons abordé la manière d’organiser:
En fin de compte, l'objectif était de fournir un schéma de répertoire dans lequel nous puissions organiser nos fichiers de manière à ce que nous ayons un niveau de cohésion, de compréhension et de maintenabilité du travail que nous effectuons..
Mais ce n'est pas tout ce qu'il y a à écrire des thèmes WordPress maintenables. Une autre consiste à suivre les conventions énoncées par les normes de codage WordPress; Cependant, cet article ne portera pas sur les normes. Le Codex fait un excellent travail dans ce domaine et nous les avons décrits dans une autre série..
Au lieu de cela, nous allons examiner de manière légèrement plus détaillée certaines des stratégies et des outils que nous pouvons utiliser afin de nous assurer que nos thèmes sont aussi faciles à gérer que possible. Dans cet article, nous allons examiner les stratégies, puis nous terminerons la série en examinant certains des outils disponibles..
Comme mentionné précédemment, il est une chose d'avoir un moyen logique d'organiser tous les répertoires, fichiers et bibliothèques qui composent votre thème. cependant, ce n'est vraiment que la moitié de ce qui entre dans la construction d'un thème.
Après tout, il existe des modèles, des fonctions, des conventions de dénomination et des outils prédéfinis qui contribuent tous à la création du thème ou à la vérification du thème afin de s'assurer qu'il n'utilise pas d'appels d'API obsolètes et qu'il est compatible avec la version la plus récente. de WordPress.
À cette fin, je pense qu'il est important de comprendre chacun de ces sujets à la fois comme quelqu'un qui commence à peine à construire des thèmes WordPress et comme quelqu'un qui le fait depuis un certain temps..
Après tout, il n’ya jamais de meilleur moment pour essayer d’améliorer ce que vous faites. En outre, les commentaires sont également un excellent endroit pour continuer la discussion et partager des idées alternatives.
Mais avant d’y arriver, parlons de choses pratiques que nous pouvons faire en rapport avec le thème WordPress, et cela augmente la maintenabilité de ce que nous faisons..
Tout d'abord, si vous n'êtes pas familiarisé avec la hiérarchie des modèles, je vous recommande vivement de lire la page correspondante du Codex avant de continuer avec cet article..
En bref, les modèles peuvent être décrits comme suit:
Les modèles WordPress s'emboîtent comme des pièces d'un puzzle pour générer les pages Web sur votre site WordPress. Certains modèles (les fichiers de modèle d'en-tête et de pied de page, par exemple) sont utilisés sur toutes les pages Web, tandis que d'autres ne sont utilisés que dans des conditions spécifiques..
Une autre façon de penser est la suivante: s’agissant de WordPress, tout ce qui est affiché à l’utilisateur provient de la base de données. Cela comprend le titre de l'article, les données de l'article, les catégories de l'article, le contenu de l'article, les commentaires, etc..
Les modèles sont les véhicules par lesquels les informations sont présentées à l'utilisateur. Ils sont composés de balisage et PHP, stylés via CSS, et peuvent avoir certains effets appliqués via JavaScript..
Mais en supposant que vous ne faites rien d’avancé avec des éléments tels que les types d’articles et / ou les taxonomies personnalisés (un sujet pour un autre article, vraiment), il existe un élément unique dans la hiérarchie des modèles WordPress qui peut servir à la fois de luxe et un problème de maintenance en fonction de votre point de vue.
Notez que dans l’article lié au Codex, WordPress aura la valeur par défaut. index.php, header.php, et footer.php modèles. La vérité est que vous pouvez vraiment créer un thème WordPress complet en utilisant seulement index.php.
Cela semble attrayant, non? Je veux dire, qui a besoin de créer autant de fichiers différents quand vous pouvez créer un joli petit thème maigre qui fait tout ce dont vous avez besoin.
Mais ensuite, pensez à cela du point de vue du travail avec une équipe composée soit de vos pairs, soit de ceux qui peuvent contribuer à un référentiel ouvert, soit de ceux qui finiront peut-être par vous-même..
Si tout le code nécessaire pour restituer des informations à partir de la base de données est contenu dans un seul fichier, il y a de fortes chances pour que la complexité de ce fichier augmente à partir de sa création même..
Au niveau le plus élémentaire, nous examinons un seul fichier avec un certain nombre de conditions, éventuellement quelques instructions switch, etc. Et tout cela est fait parce que vous devez prendre en compte les pages d'archive, les pages de publication individuelle, les publications uniques, la liste principale, etc..
Tu vois ce que je veux dire?
Mais ensuite, créer des fichiers séparés juste atténuer cette complexité peut être une bête à elle seule. Par exemple, disons que vous avez single.php pour afficher un seul post et vous avez page.php pour afficher une page et les deux modèles ont exactement la même information sauf single.php a poster des méta données et page.php ne fait pas.
C’est un excellent exemple du moment où vous pouvez extraire des métadonnées post dans leur propre partiel, comme indiqué dans l’article précédent. Ou peut-être pouvez-vous extraire le code chargé de rendre le contenu en ses propre partiel.
Quoi qu’il en soit, ce que je veux dire, c’est qu’il faut trouver un équilibre lorsque l’on utilise des modèles WordPress et la hiérarchie de modèles WordPress..
Je ne pense pas que ce soit une bonne idée d'utiliser un nombre minimal de modèles, mais je ne pense pas non plus qu'il soit nécessaire d'utiliser chaque modèle pris en charge. si cela entraîne trop de duplication de code. Là est un équilibre à trouver entre modèles et partiels.
En fin de compte, je pense que l’expérience acquise avec le temps, mais le fait d’avoir cet état d’esprit dès le départ peut permettre d’obtenir un niveau d’organisation et de maintenabilité à l’avant-garde. peut commencez à ne pas avoir juste fait un peu de planification préalable.
Quand il s’agit de travailler avec des fonctions et des conventions de nommage, il y a généralement deux règles à suivre:
Accentsconagua
revenir les données et ce qui va écho Les donnéesMais si vous êtes juste un débutant dans le développement de thèmes, ou si vous cherchez à améliorer leurs compétences en la matière, à quoi cela ressemble-t-il?
Lorsque vous nommez vos fonctions de manière unique, vous devez éviter de se heurter accidentellement à une fonction préexistante définie dans WordPress ou à un plug-in en cours d'exécution dans votre environnement..
Par exemple, supposons que vous allez écrire votre propre fonction qui filtrera le contenu avant de le rendre à la page. La bonne façon de faire est évidemment d’utiliser le add_filter une fonction; cependant, nommeriez-vous votre fonction le contenu?
Non bien sûr que non. La raison en est que WordPress définit déjà le contenu. Si vous renommez une fonction portant ce nom, vous obtiendrez des erreurs. À cette fin, il est toujours préférable de préfixer vos fonctions avec une clé unique telle que le nom de votre thème ou quelque chose de similaire..
Alors disons que nous voulons ajouter une signature à la fin de notre contenu, et disons que nous avons un thème que nous appelons Acmé. Pour ce faire, je vous recommande de créer une fonction appelée acme_the_content car il identifie le nom du thème et indique le nom de la fonction à laquelle il est accroché.
Supposons que vous souhaitiez terminer chaque publication par votre nom et votre adresse Twitter. Pour ce faire, vous pouvez définir ceci dans votre functions.php fichier:
'; $ signature. = 'Tom | @tommcfarlin '; $ signature. = ''; return $ content. = $ signature;
C'est relativement simple, n'est-ce pas? Bref, j'essaie d'utiliser le format suivant lors de la création de mes propres fonctions accrochées: theme_name-name_of_hook.
Cela le rend très facile à comprendre et à suivre non seulement lorsque vous parcourez le code, mais également lorsque vous affichez les fonctions qui composent le thème ou le fichier actuellement actif dans votre IDE..
Comme mentionné précédemment, WordPress utilise une autre convention, à savoir si des informations doivent être renvoyées par la fonction appelée ou répercutées par la fonction appelée..
Heureusement, cette règle particulière est vraiment facile à retenir:
obtenir_ obtenir_ Vous pouvez trouver certains anomalies, mais c’est l’essentiel de la façon dont l’API WordPress indique comment elle vous redonnera les données une fois que vous aurez appelé la fonction..
Tout en restant cohérents avec notre exemple précédent, disons que vous voulez faire écho aux données lorsque la fonction est appelée, vous appelez simplement le contenu(); Toutefois, si vous souhaitez récupérer le contenu d'une publication, par exemple à partir d'une boucle personnalisée, appelez get_the_content () et le stocker dans votre propre variable.
Peut-être quelque chose comme ça: $ content_for_later = get_the_content (). Maintenant, vous avez lu les données du contenu actuellement lié à la publication active dans The Loop et vous les avez stockées dans une variable que vous pourrez utiliser plus tard..
Mais savoir comment WordPress nomme ses fonctions pour vous n’en représente que la moitié. Après tout, vous envisagez de créer un thème ou un plug-in et vous voulez vous assurer de rester cohérent avec "la méthode WordPress" de faire les choses, à droite?
Exemple: dans l'exemple ci-dessus, où nous avons filtré le contenu, nous avons préfixé la fonction de telle sorte qu'elle s'appelle acme_the_content, ce qui indique que le Acmé le thème va renvoyer le contenu d'où qu'il soit appelé dans le thème.
Que se passerait-il si nous devions nommer la fonction acme_get_the_content () ?
Eh bien, techniquement, la fonction ferait toujours écho aux données où qu'elles soient appelées. cependant, cela serait incompatible avec l'API WordPress car le développeur s'attendrait à ce que les données lui soient renvoyées de manière à pouvoir les stocker dans une variable ou les transmettre à une autre fonction..
Il y a un décalage entre ce que l'utilisateur attend et ce qui se passe réellement.
Si nous parlions de quelque chose dans le monde réel, ce serait comme avoir un interrupteur sur le mur pour lequel l'utilisateur attend que, quand ils actionnent l'interrupteur, une lumière ou un ventilateur s'allume dans la même pièce alors qu'en réalité, rien ne se passe ou que la lumière ou le ventilateur d'une autre pièce s'allume.
À cette fin, nous devons faire attention à la dénomination de nos fonctions afin que nous n'écrivions pas uniquement des fonctions qui n'entrent pas en conflit avec d'autres fonctions, mais qui soient également nommées clairement et qui indiquent: Comment ils manipuleront les informations lorsque la fonction sera appelée.
Comme mentionné au début de cet article, il existe également un certain nombre d'outils et de paramètres que nous pouvons installer et configurer dans notre environnement de développement, ce qui nous aidera à détecter tout problème potentiel avant de lancer notre thème..
Cela signifie que nous pourrons identifier les fonctions qui seront finalement supprimées de WordPress afin d'éviter d'écrire du code obsolète. De plus, il existe des moyens de savoir si les variables auxquelles nous essayons d'accéder n'ont pas d'index défini, par exemple, ou d'autres fonctionnalités similaires.
Dans le dernier article de la série, nous allons examiner cela exactement. En attendant, passez en revue ce qui a été couvert ici, n'hésitez pas à partager vos questions et vos commentaires dans le flux ci-dessous, puis nous examinerons cette série la semaine prochaine..
