Widgets WordPress : refactorisation, partie 1

Le dernier article comprenait de nombreuses informations sur la configuration d’outils de qualité de code dans votre environnement de développement WordPress, mais ils sont nécessaires si nous allons faire beaucoup de refactorisation.

Mais comme je l’ai mentionné au début de cet article, la mise en place d’outils de qualité de code nous fournit d’abord une base que nous pouvons utiliser lorsque nous refactorisons le passe-partout (ce que nous devons clairement faire compte tenu de la quantité de rouge affichée par GrumPHP).

Honnêtement, je les considère comme nécessaires si vous allez faire n’importe quel type de développement, d’où la nécessité de montrer comment les configurer.

Quoi qu’il en soit, le post précédent montre à quel point nous avons travaillé, n’est-ce pas ?

Nous allons maintenant commencer par refactoriser le WordPress Widget Boilerplate.

Cela améliorera non seulement la qualité du code, mais nous guidera également à travers certains principes orientés objet que nous pouvons appliquer lors de la construction de nos widgets et que nous pouvons appliquer dans les futurs efforts de développement de WordPress.

Le passe-partout du widget WordPress : refactorisation, partie 1

La chose la plus excitante pour moi est peut-être de mettre ce référentiel aux normes modernes. Si vous regardez la branche master dans GitHub au moment de cet article (ou l’historique du référentiel plus tard), vous verrez qu’elle a six ans.

Cette chose a six ans (au moment de ce post).

C’est long dans les années Internet, n’est-ce pas ?

Quoi qu’il en soit, dans nos efforts de refactorisation, nous allons faire certaines choses :

• créer une branche à partir de laquelle travailler avant de la fusionner dans la branche principale,
• mettre en place une organisation plus cohérente des fichiers,
• mettre à jour les normes de codage pour suivre ce qui est plus conforme au PSR,
• et plus.

J’expose cela maintenant parce que nous n’allons probablement pas tout aborder dans ce post, mais nous couvrirons beaucoup de terrain. Donc, cela dit, commençons.

1 Création d’une branche de développement

En supposant que vous ayez une copie du référentiel de sur votre machine locale, que vous devriez avoir après le dernier message, la première chose que nous devons faire est de créer une branche à partir de laquelle faire notre travail.

Il est recommandé de ne pas travailler sur la branche master. Au lieu de cela, le maître doit toujours être utilisé pour déployer la dernière version stable du code.

Pour cela, saisissez la commande suivante dans votre terminal :

$ git checkout -b develop

Cela créera une nouvelle branche locale. Il n’a pas encore été poussé vers GitHub ou votre référentiel distant (où que vous le conserviez).

Ensuite, entrez la commande suivante :

$ git push --set-upstream origin develop

Cela poussera la branche de développement vers le référentiel distant. Une fois cela fait, vous devriez pouvoir voir toutes les modifications que nous avons implémentées dans le dernier message dans votre référentiel distant.

Si vous utilisez GitHub, cela devrait ressembler à ceci :

Si vous utilisez un autre service, il devrait toujours ressembler. C’est-à-dire que la structure du répertoire devrait être la même, mais son apparence dans le navigateur variera.

Une note à propos de la succursale

N’oubliez pas que le but de cette branche est que nous fassions tout notre travail. De cette façon, nous n’interférons pas avec la branche master à partir de laquelle beaucoup de gens tireront.

Pour être clair, peut-être que personne ne s’en tirera. Peut-être qu’ils le feront. Quoi qu’il en soit, ces pratiques présentées ici sont destinées à montrer comment exécuter un projet à l’aide d’outils de contrôle de code source et de qualité de code afin que vous puissiez créer de meilleurs projets pour vous-même, votre entreprise, etc.

2 Réorganiser les fichiers

La première chose à faire est de réorganiser les fichiers afin qu’ils imitent une structure plus moderne. Je ferai de mon mieux pour justifier les décisions que je prends pour le projet pendant que nous le faisons ; cependant, n’hésitez pas à prendre des libertés avec la façon dont vous voulez le faire.

Les décisions que je prends vont finalement affecter le Boilerplate primaire. Ce que vous choisissez de faire affectera la façon dont vous pouvez l’utiliser dans votre travail quotidien ou la façon dont vous choisissez d’aller de l’avant avec le projet dans son ensemble.

Mise à jour des répertoires

L’une des choses que j’essaie de faire est de décomposer mes répertoires, afin qu’ils soient aussi clairs que possible. Cela signifie que j’essaie de faire ce qui suit:

• créer un répertoire d’ actifs pour JavaScript et les feuilles de style,
• créer un répertoire src pour tous les fichiers PHP,
• créer un répertoire de langue pour les fichiers d’internationalisation,
• conservez tous les autres fichiers à la racine du référentiel, il est donc facile pour les autres de suivre le fichier README fourni.

Pour ce faire, je vais d’abord supprimer et déplacer quelques éléments. J’ai essayé d’organiser cela dans un ordre particulier:

1. Je vais supprimer le fichier README.txt. Ce fichier est utilisé comme modèle README standard si vous allez soumettre du code au référentiel de plugins WordPress, mais ce n’est pas nécessaire pour ce que je veux pour le Boilerplate.
2. Je vais renommer plugin.php en Plugin .php pour suivre les conventions PSR.
3. Je vais également renommer lang en langues.
4. Je vais créer un répertoire d’ actifs et déplacer puis déplacer les répertoires css et js dans ce répertoire. Je vais créer un sous-répertoire dev dans chacun de ces répertoires où nous pourrons travailler sur des fichiers Sass et JavaScript non minifiés (les deux viendront plus tard dans la série).
5. Après cela, je vais créer un répertoire src et déplacer la feuille de style des vues dans ce répertoire.
6. Je vais également renommer les vues en Vues et mettre également en majuscule les fichiers qu’elles contiennent.
7. Enfin, je vais tout déplacer jusqu’à la racine du répertoire. Cela signifie que widget-boilerplate disparaîtra et que tous les fichiers résideront dans le répertoire racine du référentiel.

Ce sont beaucoup d’étapes, mais elles sont petites. J’aime les exposer en premier afin que ce qui se passera dans le reste de cette section soit clair.

Supprimer le LISEZMOI

Pour cela, saisissez simplement la commande suivante dans votre terminal depuis la racine du répertoire widget-boilerplate :

$ rm readme.txt

Cela supprimera le fichier. Si vous saisissez la commande suivante dans votre terminal :

$ git status

Vous devriez voir quelque chose comme ceci :

Je suis partisan de m’assurer que les différents changements apportés sont clairs et concis afin qu’il soit plus facile de les annuler un par un. Alors allons-y, engageons-nous et poussons ce changement.

Entrez ce qui suit :

$ git rm README.txt
$ git add. $ git commit -n -m "Removing the original README.txt template."
$ git push

Cela indiquera à Git de supprimer le fichier, d’ajouter la modification unique à l’ensemble de modifications, de la valider sans exécuter d’outils de qualité de code (car nous n’avons pas besoin de le faire pour le moment ; sinon, cela échouera) et de la pousser à la branche develop du référentiel distant .

Maintenant que nous avons fait cela, allons-y et renommons certains fichiers.

Renommer des fichiers

Pendant que nous y sommes, nous allons non seulement renommer le fichier plugin .php mais aussi les autres fichiers PHP. Ce sont des fichiers qui peuvent être regroupés logiquement dans le même ensemble de modifications, il est donc logique d’aller de l’avant et de le faire.

Alors depuis votre terminal, entrez les commandes suivantes :

$ mv plugin.php Plugin.php
$ mv views/admin.php views/Admin.php
$ mv views/widget.php views/Widget.php

En faisant cela, nous n’avons encore apporté aucune modification aux fichiers, il n’y a donc rien à valider. Avançons avec le renommage des répertoires.

Créer des répertoires ; Renommer les répertoires

Comme nous l’avons fait avec les fichiers, continuons et créons un nouveau répertoire de ressources. Dans votre terminal, saisissez la commande suivante :

$ mkdir assets

Ensuite, nous voulons déplacer les répertoires css et js dans ce répertoire, alors entrez également ce qui suit dans le terminal :

$ mv css assets
$ mv js assets

Et renommons le répertoire lang en Languages ​​en entrant la commande suivante :

$ mv lang Languages

Enfin, renommons view en Views :

$ mv views Views

À ce stade, nous avons fait tout notre possible avec les fichiers actuellement dans le répertoire principal. Cependant, nous devons encore préparer des sous-répertoires pour nos actifs prétraités.

Avant de faire cela, cependant, c’est une bonne habitude d’exécuter une vérification rapide de l’ état de git pour voir ce qui existe et qui peut être ajouté à un ensemble de modifications. Si votre référentiel est comme le mien, vous verrez probablement quelque chose comme ceci :

Dans ce cas, je pense qu’il est acceptable de tout ajouter dans un seul ensemble de modifications avec un commentaire indiquant que nous avons renommé et déplacé des fichiers.

Vous pouvez différer et si c’est le cas, c’est tout à fait correct. Vos commandes différeront un peu des miennes mais voici ce que j’ai pour mon commit :

$ git add. $ git commit -n -m "Creating new directories; Renaming files."
$ git push

Passons maintenant aux sous-répertoires de nos fichiers prétraités.

Créer des sous-répertoires

Dans le répertoire CSS, créez un sous-répertoire appelé dev et créez un fichier vide appelé admin.scss et widget.scss car nous travaillerons avec ces fichiers plus tard dans la série.

Ensuite, ajoutez un répertoire dev au répertoire JavaScript et ajoutez des fichiers vides admin.js et widget.js à ces fichiers. Si vous vous sentez si enclin, vous pouvez déplacer les fichiers préexistants dans les répertoires de développement car ce sont les fichiers que nous utiliserons comme base pour nos fichiers de développement.

C’est une étape facultative ; cependant, je suis allé de l’avant et je l’ai fait parce que c’est comme ça que je préfère travailler. Voici l’ensemble des commandes que j’ai exécutées.

Depuis le répertoire css …

$ mkdir dev
$ mv admin.css admin.scss && mv widget.css widget.scss
$ mv *.scss dev

Ci-dessus, j’ai créé le répertoire dev pour mes feuilles de style, les ai renommés en fichiers Sass et les ai déplacés dans le répertoire dev.

Avant d’aller de l’avant, c’est le bon moment pour vérifier le statut de git et valider les modifications liées aux feuilles de style :

$ git add. $ git commit -n -m "Renaming and moving stylesheets into a dev directory."
$ git push

Maintenant, depuis le répertoire js …

$ mkdir dev
$ mv *.js dev

Comme nous n’avons pas à changer le type de fichier des fichiers associés, nous pouvons simplement les déplacer dans le nouveau répertoire.

Enfin, faisons la même chose et voyons s’il y a des changements que nous pouvons faire passer par une vérification rapide de l’ état de git (ce qui devrait être le cas). Voici une liste des commandes que j’ai exécutées pour valider et pousser mes modifications :

$ git add. $ git commit -n -m "Adding a JavaScript dev directory and moving the development files."
$ git push

Nous avons presque terminé. Il ne reste plus qu’à déplacer certains répertoires à la racine du référentiel et à renommer le répertoire principal en src. Alors faisons-le maintenant.

Déplacer les répertoires dans la racine

Essentiellement, nous devons tout déplacer sauf le fichier du plugin et le répertoire Views hors du répertoire widget-boilerplate, et nous devons renommer widget-boilerplate en src.

Cela semble simple, non ? C’est assez simple. Depuis le répertoire widget-boilerplate :

$ mv assets .. && mv languages ..
$ cd ..
$ mv widget-boilerplate src

Ensuite, je validerai la modification sur GitHub en utilisant ce qui suit :

$ git add. $ git commit -n -m "Reorganizing the directory structure."
$ git push

Nous avons maintenant une structure de répertoires beaucoup plus moderne. Vous pouvez le voir ici dans ma branche de développement.

Un mot sur la POO

Et maintenant que nous avons tout cela en place, nous pouvons nous lancer dans l’écriture de code. Mais ne vous y trompez pas : une partie de la programmation orientée objet est également une analyse orientée objet et une conception orientée objet.

Ce que nous avons fait dans cet article est essentiellement d’appliquer une conception architecturale orientée objet basée sur l’analyse de la façon dont le plugin s’intègre.

La partie suivante, cependant, consiste à mettre à jour le code pour se débarrasser de tout le rouge que nous avons vu en reniflant notre code.

Dans le prochain article

L’objectif principal du prochain article est de continuer à mettre à jour les normes de codage afin que nous ayons résolu tous les problèmes posés par notre IDE ou via les outils de qualité de code que nous exécutons en ligne de commande.

Nous devrions également avoir un référentiel beaucoup plus propre et mieux organisé, et être dans une position où nous sommes prêts à fusionner notre travail dans la branche master.

Pour l’instant, cependant, assurez-vous que vous avez une bonne maîtrise de tout ce qui précède avant de continuer car il est nécessaire de comprendre pour le reste du travail que nous avons devant nous.