Utiliser Composer avec WordPress

Dans cet article nous allons voir, quels sont les avantages et comment utiliser composer avec WordPress.

Je souhaitais améliorer 4 points essentiels dans le processus de gestion des sites utilisant le CMS WordPress :

1. Installation et mise à jour du CMS
2. Installation et mise à jour des plugins
3. Workflow de développement en équipe
4. Évolutivité et maintenabilité du (des) thème(s)

J’ai donc commencé à faire des recherches, sur ce qui existait déjà. C’est pendant ces recherches que j’ai découvert que certaines personnes avaient déjà réfléchi à la question et utilisaient composer et wpackagist dans leurs projets.

Avant d’aller plus loin je vous invite à aller voir du côté du dépôt GitHub de WPress composer-skeleton.

Pourquoi ce dépôt

Au fur est à mesure des années passées à développer des sites et applications j’ai vite compris l’avantage d’automatiser certaines tâches notamment la gestion des librairies / plugins.
Lorsque on développe un site ou une application avec PHP, l’utilisation de composer est devenu indispensable. WordPress et quelques autres CMS sont les derniers résistants et font figure d’exception dans l’écosystème de PHP.

Mais en tant que développeur, il est important, a mon sens de voir les avantages d’intégrer cet outil a vos projets.

Voici quelques avantages :

• Mettre à la diet votre dépôt GIT / SVN en utilisant WordPress et les Plugins comme des dépendances de votre projet, et donc de versionner uniquement votre code.
• Avoir un .lock vous permettant de contrôler exactement les versions de vos plugins et de WordPress.
• Installer en une commande un nouveau projet
• La gestion des environnements (local / staging / prod)
• Bénéficier de l’autoloading et des namespaces dans vos plugins / thèmes

Le dépôt WPress composer-skeleton est un condensé de tout ce que j’ai pu mettre en place et tester sur des dizaines de projets plus ou moins complexes basés sur WordPress.

Ce projet est ouvertement inspiré du dépôt roots.io. Le travail proposé par cette équipe est vraiment génial mais j’avais besoin de mettre en place un starter répondant au mieux a mes habitudes de développement, problématiques et contraintes quotidiennes.

Quels sont les outils inclus

roots.io
Comme évoqué plus haut, ce projet est ouvertement et énormément inspiré de leur travail. J’utilise par exemple plusieurs de leurs packages.

"roots/wordpress": "^5.4",
"roots/wp-config": "^1.0",
"roots/wp-password-bcrypt": "^1.0.0",

Ces packages permettent d’utiliser bcrypt pour le chiffrement des mots de passes et de permettre une gestion plus fine de la configuration de WordPress en prenant en compte des environnements différents.

Un script est également dans le dossier mu-plugin (Must-Use), il permet de faire un chargement automatique sur tout les plugins présent dans celui-ci.

wpcli

Cet outil est très utile pour lancer des commandes dans votre projet. Il permet d’effectuer des opérations de maintenance et de configuration très simplement.
J’utilise principalement la CLI pour de la récupération de base de données tout en changeant le chemin vers les uploads et changer l’url (très pratique lorsque vous souhaitez rapatrier la base de prod en local) mais aussi la gestion du CRON de WordPress.

docker-compose

J’utilise un fichier docker-compose.yml afin de générer rapidement un base de données dans le projet. C’est par exemple un standard dans mes projets, fini MySQL en global sur ma machine, ça permet de contrôler la version du SGBD et que chaque développeur ai le même environnement.
De plus ce fichier permet d’ajouter facilement d’autres services, tels qu’Elasticsearch / Solr ou Mailhog.

Comment ça marche

Initialisation

$ composer create-project agencearcange/wordpress-composer-skeleton my-project

Avec cette commande vous pouvez générer rapidement un nouveau projet avec la dernière version du squelette. Ce starter est une « coquille vide » permettant de démarrer n’importe quel projet.

On peut voir que composer va chercher les plugins et surtout va chercher automatiquement WordPress dans la version spécifiée dans le composer.json.

Pour mieux comprendre le fonctionnement de ce starter, il faut regarder la structure du fichier composer.json

{
   ...
    "extra": {
        "installer-paths": {
            "public/content/mu-plugins/{$name}/": ["type:wordpress-muplugin"],
            "public/content/plugins/{$name}/": ["type:wordpress-plugin"],
            "public/content/themes/{$name}/": ["type:wordpress-theme"]
        },
        "dropin-paths": {
            "public/content/languages/"         : ["vendor:koodimonni-language"],
            "public/content/languages/plugins/" : ["vendor:koodimonni-plugin-language"],
            "public/content/languages/themes/"  : ["vendor:koodimonni-theme-language"]
        },
        "wordpress-install-dir": "public/wp"
    },
    ...
}

Tout d’abord, composer est configuré pour fonctionner avec le dépôt wpackagist, ce repository « scanne » le subversion de WordPress (plugins et thèmes) et récupère les tags dans le but de les rendre utilisables par composer.

La configuration « extra » de composer permet le fonctionnement suivant :

• copie de wordpress dans public/wp
• copie des plugins et les thèmes dans leurs dossiers respectifs
• lors de l’installation, création du fichier .env basé sur le fichier .env.dist

La structure des fichiers

my-project/
├── config/
│   ├── environments/
│   │   └── development.php
│   └── application.php
├── public/
│   ├── wp/
│   ├── content/
│   │   ├── languages/
│   │   ├── mu-plugins/
│   │   ├── plugins/
│   │   ├── themes/
│   │   └── uploads/
│   ├── .htaccess
│   ├── index.php
│   └── wp-config.php 
├── var/
├── vendor/
├── .env
├── .env.dist
├── .gitignore
├── composer.json
├── docker-composer.yaml
└── wp-cli.yaml

Plusieurs choses importantes:

• les configurations sont disponibles dans config et organisées par « environnement »
• le serveur pointe dans le dossier public
• les plugins / themes / uploads sont dans le dossier public/content/
• les variables de configuration sont situées dans le fichier .env

Environnements

La gestion des environnements a deux dimensions. Premièrement, vous pouvez définir les configurations propres a votre environnement (development, staging) dans des fichiers situés dans le dossier config/environments. Ces configurations viendrons supplanter celles par défaut de votre projet.

Exemple :

Config::define('SAVEQUERIES', true);
Config::define('WP_DEBUG', true);
Config::define('WP_DEBUG_DISPLAY', true);
Config::define('WP_DISABLE_FATAL_ERROR_HANDLER', true);
Config::define('SCRIPT_DEBUG', true);

Concernant les variables, par exemple les informations de connexion à la base de données, il faut utiliser le ficher .env .

Exemple :

# Database
DB_NAME='wordpress'
DB_USER='root'
DB_PASSWORD='toor'

Gestion des plugins et des thèmes

La gestion des plugins, thèmes et autres librairies se fait à l’aide de composer, c’était le but non ? 🙂

Voici un exemple d’ajout de plugin:

$ composer require wpackagist-plugin/contact-form-7

Base de données

Dans le starter j’ai mis en place un fichier docker-compose.yaml qui permet de créer rapidement une base de données MySQL 5.7.

$ docker-compose up -d

Par défaut les variables dans le fichier.env permettent de se connecter cette la base de données générée avec Docker.

Aller plus loin

Ce dépôt et l’utilisation de Composer n’est qu’un point de départ pour faciliter l’utilisation de WordPress pour les développeurs.

La mise en place de cette archi vous permet d’envisager de nouvelles améliorations, par exemple d’automatiser des process de développement en équipe. En allant encore plus loin, vous pouvez même mettre en place du déploiement automatique.

J’aborderai ces sujets dans de futurs articles, si j’ai le temps 🙂