Widgets WordPress : refactorisation, partie 6

Vous devriez bien connaître la refactorisation que nous effectuons concernant le WordPress Widget Boilerplate. Sinon, je vous recommande de rattraper la série jusqu’à présent en :

• en lisant le message précédent ,
• ou lire toute la série jusqu’à ce point,
• et en regardant la branche de développement du projet sur GitHub.

En ce qui concerne la base de code, nous sommes actuellement bien placés. Nous avons commencé à refactoriser une grande partie du code en classes plus petites et plus ciblées. Et nous venons de mettre en place un registre afin que nous puissions commencer à travailler avec des instances d’objets tout au long du plugin sans avoir besoin de trop de couplage.

Mais il y a toujours un problème auquel nous sommes confrontés et qui concerne les espaces de noms et le chargement automatique. J’en ai un peu parlé il y a quelques années, mais pas en ce qui concerne Composer.

Et c’est ce que nous allons voir dans cet article.

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

Dans le deuxième article de cette série, nous avons commencé à parler de Composer. Si vous demandez à la plupart des développeurs PHP (y compris ceux qui travaillent sur WordPress), vous entendrez probablement que Composer est un gestionnaire de packages ou un gestionnaire de dépendances.

En bref, c’est un moyen pour nous d’intégrer des bibliothèques tierces dans notre projet, puis d’utiliser leurs fonctionnalités (nous n’avons donc pas à écrire notre propre code pour le faire).

Mais il existe une autre fonctionnalité offerte par Composer qui est d’une immense utilité, en particulier lorsque vous utilisez de nombreuses classes et que vous ne souhaitez pas utiliser d’instructions require_once dans votre base de code.

Et c’est le chargeur automatique.

L’autochargeur défini

Directement du manuel:

Pour les bibliothèques qui spécifient des informations de chargement automatique, Composer génère un vendor/autoload.phpfichier. Vous pouvez simplement inclure ce fichier et commencer à utiliser les classes fournies par ces bibliothèques sans aucun travail supplémentaire :

Si vous avez suivi le code jusqu’à présent, vous verrez que nous utilisons déjà le chargeur automatique généré par Composer.

Dans un premier temps, nous avons défini la configuration nécessaire :

{
    "name": "wordpress-widget-boilerplate/wordpress-widget-boilerplate",
    "description": "An organized, maintainable boilerplate for building widgets using WordPress best practices.",
    "type": "wordpress-plugin",
    "license": "GPL-3.0-or-later",
    "homepage": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate",
    "authors": [
      {
        "name": "Tom McFarlin",
        "email": "tom@pressware.co",
        "homepage": "https://pressware.co"
      }
    ],
    "support": {
      "issues": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate/issues"
    },
    "config": {
      "preferred-install": "dist",
      "platform": {
          "php": "7.1"
      }
    },
    "repositories": [
      {
        "type": "composer",
        "url": "https://wpackagist.org"
      }
    ],
    "require": {
      "php": "7.1",
      "composer/installers": "^1.4"
    },
    "require-dev": {
        "friendsofphp/php-cs-fixer": "^2.13.1",
        "jakub-onderka/php-parallel-lint": "^1.0.0",
        "phpmd/phpmd": "^v2.6.0",
        "nikic/php-parser": "^4.0",
        "ocramius/proxy-manager": "^2.0.0",
        "phpro/grumphp": "^0.13.1"
    },
    "scripts": {
      "test": [
        "./vendor/bin/grumphp run"
      ]
    },
    "minimum-stability": "stable"
  }

Ensuite, nous avons commencé à l’inclure dans le bootstrap du plugin (que nous finaliserons aujourd’hui) :

Mais il y a un problème ici: comment charger uniquement les classes dont nous avons besoin pour la distribution ?

En d’autres termes : il existe de nombreuses bibliothèques que nous utilisons dans le développement pour nous assurer que nous écrivons du code de haute qualité et conforme aux normes. Mais nous ne voulons pas distribuer 10 Mo de données à ceux qui utilisent notre projet.

Au lieu de cela, nous devons inclure uniquement les fichiers requis, n’est-ce pas ? Et pour ce faire, nous devons nous assurer que nous générons un chargeur automatique que nous pouvons inclure et qui fait exactement cela.

Tout d’abord, je vais vous montrer la commande, puis vous expliquer ce qu’elle fait :

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Cela générera exactement ce dont nous avons besoin pour que notre projet fonctionne dans un environnement de production. Voici ce que fait chaque drapeau :

• installation du compositeur. Cela installe simplement toutes les dépendances. Si vous en avez déjà un certain nombre dans votre répertoire de fournisseurs, cela supprimera tous sauf ceux qui sont nécessaires.
• non-dev. Cela empêchera Composer d’installer les packages dans la section require-dev de ses fichiers de configuration (à savoir, les dépendances que nous utilisons avec GrumPHP).
• non-ansi. Cela empêche toute sortie ANSI de se produire. Vous ne vous souciez peut-être pas de l’exécuter ou non. Si vous optez pour un type de déploiement automatique, utilisez-le ; sinon, il peut être omis de la commande.
• pas d’interaction. Il s’agit d’un autre indicateur utilisé spécifiquement pour les environnements dans lesquels vous souhaitez créer automatiquement le projet et ne pas avoir à répondre à des questions, des résultats et des choses comme ça.
• optimiser-chargeur automatique. En bref, cela génère un chargeur automatique plus rapide. Cela peut prendre un peu de temps en fonction de la taille de votre projet, mais cela porte ses fruits lors du lancement de votre travail.
• pas de progrès. Cela empêche la barre de progression de s’afficher dans le terminal. Vous voudrez peut-être voir cela et, si c’est le cas, c’est très bien ; cependant, certains environnements peuvent ne pas bien gérer certains caractères (tels que le retour arrière).
• préférence-dist. Cela garantira que les packages installés le sont en utilisant la version de distribution (par opposition à quelque chose de moins stable).

Toujours intéressé?

Si vous êtes vraiment curieux d’optimiser le chargeur automatique pour des projets en dehors de ce post, je vous recommande de lire cette page dans la documentation de Composer. Cela sort du cadre de ce que nous faisons ici, mais cela peut être utile avec d’autres travaux que vous avez actuellement ou que vous ferez à l’avenir.

À quoi cela ressemble-t-il dans le Boilerplate ?

Si vous travaillez sur le Boilerplate sur votre ordinateur local, vous pouvez voir quelque chose comme ceci :

Mais si vous exécutez la commande incluse ci-dessus, vous verrez alors quelque chose comme ceci :

C’est une grande différence et c’est un petit projet. Imaginez faire quelque chose de beaucoup plus grand qui va fonctionner en production.

Par expérience, je peux vous dire que les projets peuvent rapidement atteindre 20 Mo ou plus de dépendances si vous utilisez une variété de bibliothèques tierces pour des choses telles que la journalisation, les requêtes HTTP et les outils de qualité du code.

Allons-nous inclure dans notre répertoire de fournisseurs ?

Les gens diront souvent que vous ne devriez pas inclure le répertoire du fournisseur dans le contrôle de source et pour une bonne raison : cela peut être énorme.

Même la documentation de Composer en parle :

La meilleure pratique consiste à demander à tous les développeurs d’utiliser Composer pour installer les dépendances. De même, le serveur de build, CI, les outils de déploiement, etc. doivent être adaptés pour exécuter Composer dans le cadre de l’amorçage de leur projet.

Alors qu’est-ce qu’on est censé faire? Nous avons besoin du chargeur automatique et nous avons besoin de certaines dépendances car nos utilisateurs ne sauront pas exécuter (et ne devraient pas non plus exécuter !) Composer chaque fois qu’ils téléchargent notre travail.

En raison de la nature de WordPress et du travail que nous effectuons, nous devrons valider le répertoire des fournisseurs, mais uniquement avec certaines exigences.

1. Nous allons créer une branche qui sera utilisée pour la version (nous l’appellerons de manière créative release et nous pourrons y fusionner le développement chaque fois que nécessaire).
2. Nous nous assurerons que le répertoire du fournisseur ne fait pas partie du fichier gitignore ; cependant, nous nous assurerons que les répertoires .git dans le répertoire du fournisseur sont ignorés (cela peut encore prendre beaucoup d’espace).

Faisons donc chaque étape et voyons à quoi cela ressemble lorsque nous avons terminé.

Création de la branche de publication

Pour créer une nouvelle branche depuis le terminal, saisissez la commande suivante :

$ git checkout -b release

Cela prendra tout le code sur lequel nous travaillons et créera ensuite une nouvelle branche avec. Puisque ce sera la branche que nous utiliserons pour agir comme ce que nos utilisateurs utiliseront (nous parlerons de master dans un prochain article).

Tout d’abord, examinez votre fichier composer.json et assurez-vous qu’il inclut les éléments suivants :

"autoload": {
    "psr-4": {
        "WordPressWidgetBoilerplate": "src/",
        "WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
        "WordPressWidgetBoilerplateUtilities": "src/Utilities/",
        "WordPressWidgetBoilerplateViews": "src/Views/"
    }
},

Nous devons maintenant nous assurer que nous exécutons la commande Composer ci-dessus pour nous assurer que rien d’autre que ce dont nous avons besoin ne se trouve dans le  répertoire du fournisseur.

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Maintenant, nous devons mettre à jour gitignore.

Mettre à jour ce que nous ignorons

Et si vous avez suivi à la fois la série et le message jusqu’à présent, alors vous savez que cela ressemblera à quelque chose comme ça (cela peut inclure plus ou moins mais devrait inclure au moins cela).

Pour moi, cela ressemble à ceci :

*.DS_Store
*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php

/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz

/vendor/**/.git
/vendor/bin
composer.lock

Selon que vous utilisez un terminal ou un client, vous verrez qu’il y a de nouveaux fichiers à valider (à partir du répertoire du fournisseur, en particulier). Ajoutez-les donc à votre branche.

Validez ensuite vos modifications. Vous devrez peut-être spécifier les éléments suivants si vous travaillez dans le terminal :

$ git push --set-upstream origin release

Et avec cela, votre code devrait fonctionner et être disponible sur GitHub (ou tout autre service de contrôle de code source que vous utilisez). Vous pouvez voir ce que j’ai de disponible ici.

Ajouter des fonctionnalités

Maintenant que nous avons toutes les pièces nécessaires en place, il est temps de commencer à utiliser Composer, le chargeur automatique, nos classes abstraites et notre registre pour commencer à ajouter des fonctionnalités de base au WordPress Widget Boilerplate afin que nous ayons quelque chose à montrer pour notre travail .

Pour ceux qui sont curieux, je prévois pour le moment de garder les branches organisées comme telles :

• master sera ce qui est disponible pour tous ceux qui souhaitent créer un widget WordPress,
• develop est strictement réservé aux développeurs, y compris ceux qui savent utiliser Composer et les sujets abordés dans cet article,
• release est ce qui sera utilisé pour fournir une démonstration de travail.

Pour l’instant, cependant, passez en revue ce qui est couvert dans cet article et nous le reprendrons dans le prochain article.