Les fondements du développement WordPress moderne

WordPress est le système de gestion de contenu (CMS) historique. Il est resté extrêmement populaire depuis son lancement en 2003 grâce à la possibilité qu'il offre aux utilisateurs de créer rapidement un site web à l'aide d'outils leur permettant un contrôle réel et intuitif sur leur contenu. Cette popularité a à la fois inspiré et dépendu des efforts constants de modernisation menés par les fans de WordPress. Le dernier projet en date visant à maintenir ce CMS classique en pleine forme deux décennies après sa naissance s’appelle Bedrock : il s’agit d’une initiative lancée par l’équipe de Roots pour transformer WordPress en une application « Twelve-Factor ».

Roots, c’est une équipe de développeurs qui crée et gère des outils pour améliorer le processus de développement de WordPress. Certains de leurs projets visent à standardiser le développement des plugins et des thèmes. Bedrock, en revanche, se concentre sur l’installation de WordPress elle-même, en simplifiant la configuration et la personnalisation grâce à une intégration totale avec Composer, le gestionnaire de paquets PHP.

Avec Bedrock, Roots essaie de rapprocher WordPress de la méthodologie des applications « Twelve-Factor ». Twelve-Factor est une sorte de guide des « meilleures pratiques » qui n’est respecté que lorsqu’une application définit explicitement les bases de code externes dont elle dépend et lorsque la configuration de cette application peut être récupérée depuis l’environnement, quel que soit l’endroit où elle est déployée. Ces deux caractéristiques rendent les builds reproductibles et donc plus fiables. Ce sont aussi deux fonctionnalités que WordPress ne respecte pas par défaut, ce qui rend la maintenance beaucoup plus difficile.

La maintenance des sites WordPress

Une fois que tu as déployé WordPress, le processus d’installation est réputé pour sa simplicité (l’une des nombreuses raisons de l’attrait durable de l’application). Mais la maintenance de WordPress n’est malheureusement pas aussi simple. Par exemple, mettre à jour WordPress avec autre chose que des mises à jour mineures de version peut s’avérer fastidieux. Le projet Bedrock vise à alléger la charge de maintenance de WordPress en définissant les thèmes et les plugins comme n’importe quelle autre dépendance PHP — des composants pouvant être installés et mis à jour à l’aide d’une seule commande via un gestionnaire de paquets.

Lorsqu’une mise à jour est disponible, WordPress affiche un bouton qui permet aux administrateurs de télécharger et d’appliquer les mises à jour d’un simple clic. Cependant, de nombreuses solutions d’hébergement, y compris Platform.sh, imposent des systèmes de fichiers en lecture seule lors de l’exécution. Ces solutions déploient une image de build hautement reproductible, issue de ta base de code et de son processus de build explicitement défini, le tout validé dans le système de contrôle de version. Autrement dit, ton application est le résultat de ces définitions, et pas seulement des fichiers présents dans le dépôt. Le code externe (les dépendances) dont dépend ton application, et idéalement les définitions de ton infrastructure elle-même, sont validés avec des versions précises, afin que l’ensemble de ton processus DevOps, du début à la fin, soit reproductible par quiconque en a besoin. C’est une bonne chose.

En comparaison, WordPress nécessite un accès en écriture au serveur pour que les plugins et les thèmes puissent être mis à jour à l’exécution. De plus, WordPress ne suit pas le code de ces thèmes et paquets dans le contrôle de version de ton site ; il se contente de les remplacer lorsque des mises à jour sont nécessaires. Ces deux aspects combinés peuvent introduire des vulnérabilités involontaires qui sont totalement introuvables. Si les thèmes et les plugins sont gérés par un système de contrôle de version, ils peuvent rapidement alourdir ta base de code. Comme Bedrock traite ces composants comme des dépendances, rien n’est écrit en cours d’exécution et les paquets individuels n’ont pas besoin d’être validés, ce qui permet d’éliminer à la fois les vulnérabilités et l’encombrement.

La solution Bedrock : « Composerifier » WordPress !

Composer est au cœur de tout pour Bedrock. Si on peut traiter le cœur de WordPress et toutes nos personnalisations comme des dépendances, on peut valider moins de code, être plus précis dans notre gestion des versions, prendre en charge le déploiement sur davantage d’environnements que WordPress ne le permettrait, et simplifier considérablement sa maintenance.

On a récemment partagé une méthode pour mettre à jour WordPress « vanilla » sur Upsun Cloud à l’aide de Source Operations. Cette méthode te permet de conserver un système de fichiers en lecture seule, de valider tout le code sur Git et d’exposer un point de terminaison qui déclenche les mises à jour dans un conteneur séparé, rendant ainsi la maintenance traditionnelle de WordPress compatible avec notre plateforme.

Mais tu peux aussi y parvenir en intégrant WordPress à Composer, le système de gestion de paquets de PHP. Sans surprise, c’est la méthode recommandée pour déployer WordPress sur Platform.sh depuis un certain temps déjà. Notre modèle WordPress s’appuie sur le célèbre fork Composer de John Bloch, qui reproduit le code source par défaut de WordPress, puis ajoute le fichier `composer.json` nécessaire pour traiter le cœur de WordPress comme une dépendance. Ce même principe s’applique au vaste écosystème de thèmes et de plugins WordPress, accessibles via Composer depuis le dépôt WPackagist.

Bedrock : le kit de démarrage pour le développement WordPress

Une grande partie de ce qui différencie Bedrock commence par sa structure de projet. Clonons donc une copie locale du dépôt pour la comparer à la structure classique de WordPress :

.
├── config/
│   ├── application.php
│   └── environments/
│       ├── development.php
│       └── staging.php
├── web/
│   ├── app/
│   │   ├── mu-plugins/
│   │   ├── plugins/
│   │   ├── themes/
│   │   └── uploads/
│   ├── index.php
│   └── wp-config.php
├── composer.json
├── composer.lock
├── phpcs.xml
└── wp-cli.yml

La structure est ici très différente de ce qu’on verrait dans un WordPress « pur » : elle est bien plus petite, pour commencer. La plupart des fichiers qui font fonctionner WordPress — y compris les fichiers du cœur de WordPress, ainsi que les thèmes et plugins par défaut et personnalisés — ne sont en fait pas ajoutés au dépôt. À la place, ces fichiers sont téléchargés à la volée en tant que dépendances pour l’application finale, le tout défini dans son fichier `composer.json`.

 "repositories": [
   {
     "type": "composer",
     "url": "https://wpackagist.org",
     "only": ["wpackagist-plugin/*", "wpackagist-theme/*"]
   }
 ],
 "require": {
   "php": ">=8.0",
   "composer/installers": "^2.2",
   "vlucas/phpdotenv": "^5.5",
   "oscarotero/env": "^2.1",
   "roots/bedrock-autoloader": "^1.0",
   "roots/bedrock-disallow-indexing": "^2.0",
   "roots/wordpress": "6.6.1",
   "roots/wp-config": "1.0.0",
   "roots/wp-password-bcrypt": "1.1.0",
   "wpackagist-theme/twentytwentyfour": "^1.0"
 },
 "extra": {
   "installer-paths": {
     "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin"],
     "web/app/plugins/{$name}/": ["type:wordpress-plugin"],
     "web/app/themes/{$name}/": ["type:wordpress-theme"]
   },
   "wordpress-install-dir": "web/wp"
 },

Dans l’extrait ci-dessus, le fichier `roots/wordpress` spécifie une version exacte de WordPress : 6.6.1. Cette même version sera téléchargée à chaque build (lors de l’exécution de `composer install`) dans un sous-répertoire, ce qui est devenu une pratique courante même en dehors des versions de WordPress « Composerisées ».

On s’éloigne déjà de certains des problèmes évoqués plus haut. WordPress est une dépendance, qu’on peut définir explicitement et verrouiller sur une version spécifique pour garantir des compilations reproductibles. Rien de tout ça n’est validé, et seule cette version spécifique est téléchargée lors d’une commande de compilation composer install.

Étendre WordPress avec Composer

Il en va de même pour les thèmes et les plugins. Mais tu remarqueras que l’composer.json a besoin d’une configuration supplémentaire pour prendre en charge cette nouvelle façon de définir les dépendances de WordPress. Par défaut, toute dépendance Composer est installée dans un sous-répertoire non validé : vendor. Sur Platform.sh, l’installation se fait via notre « build flavor » ou pendant ton hook de build.

Le problème, c’est que ce n’est pas là qu’on aimerait que le cœur de WordPress se retrouve. Dans l’extrait de code ci-dessus, tu verras les attributs extra.wordpress-install-dir et extra.installer-paths. Le premier indique à Composer (via composer/installers) de télécharger la version de WordPress qu’on a définie dans web/wp, et le second de installer les thèmes et les plugins dans web/app. Tout ce qui provient en amont de WordPress se trouve dans un répertoire, et tout ce qu’on ajoute à WordPress va dans un autre. Tu remarqueras quelque chose de similaire dans ta configuration, qui a été isolée sur config, avec un contrôle adapté à l’environnement. Ici, tout est clairement séparé, sous contrôle de version, et grâce à Composer, ça devient reproductible.

Avec cette configuration, on peut faire plein de choses très facilement. Si on veut mettre à jour le cœur de WordPress ainsi que tous nos thèmes et plugins, il suffit de lancer la commande « composer update ». On peut personnaliser l’apparence du site en utilisant un thème de la communauté avec « composer require wpackagist-theme/magsoul » (par exemple), puis l’activer dans le tableau de bord d’administration une fois déployé. Si on veut transformer le site en boutique en ligne, on peut ajouter le plugin WooCommerce de la même manière :

$ composer require wpackagist-plugin/woocommerce

Si on veut pouvoir gérer l’application via la CLI WordPress :

$ composer require wp-cli/wp-cli

Si tu veux essayer de reproduire notre application, il te suffit de lancer la commande composer install pour commencer à y contribuer. Tout est géré par des dépendances et peut être entièrement installé et mis à jour via Composer.

Déployer Bedrock sur Upsun.com

Tout ça ne servirait à rien si on ne parlait pas des déploiements, et c’est là que Bedrock offre vraiment une grande souplesse de configuration. Bedrock te permet d’utiliser des variables d’environnement pour te connecter à la base de données et définir des variables de routage comme WP_HOME et WP_SITEURL de manière plus flexible que le WordPress traditionnel. C’est un autre élément du concept des applications « Twelve-Factor » : la configuration stockée dans l’environnement. L’application peut être déplacée vers de nombreux environnements différents tout en conservant la même version, à condition que ces variables soient définies. Tu trouveras ci-dessous un fichier `.environment` similaire inclus dans notre modèle WordPress Bedrock de Platform.sh (qui fonctionne exactement de la même manière sur Upsun Cloud) :

# .environment

export DB_NAME=$MARIADB_PATH
export DB_HOST=$MARIADB_HOST
export DB_PORT=$MARIADB_PORT
export DB_USER=$MARIADB_USERNAME
export DB_PASSWORD=$MARIADB_PASSWORD


export WP_HOME=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.primary == true) | .key')
export WP_SITEURL="${WP_HOME}wp"
export WP_DEBUG_LOG=/var/log/app.log
export WP_ENV=production
# Uncomment this line if you would like development versions of WordPress on non-production environments.
# export WP_ENV="${PLATFORM_ENVIRONMENT_TYPE}"


export AUTH_KEY=$PLATFORM_PROJECT_ENTROPY
export SECURE_AUTH_KEY=$PLATFORM_PROJECT_ENTROPY
export LOGGED_IN_KEY=$PLATFORM_PROJECT_ENTROPY
export NONCE_KEY=$PLATFORM_PROJECT_ENTROPY
export AUTH_SALT=$PLATFORM_PROJECT_ENTROPY
export SECURE_AUTH_SALT=$PLATFORM_PROJECT_ENTROPY
export LOGGED_IN_SALT=$PLATFORM_PROJECT_ENTROPY
export NONCE_SALT=$PLATFORM_PROJECT_ENTROPY

Les informations relatives à notre service de base de données sont exposées sous la forme d’un ensemble de variables d’environnement préfixées par le nom du service de base de données que nous définissons dans la propriété « relationships » de notre fichier de configuration (voir ci-dessous). Dans ce cas précis, je l’ai nommé mariadb ; les informations du service sont donc préfixées par MARIADB_*. Cependant, Bedrock a besoin que les variables d’environnement soient préfixées par DB_ ; le premier bloc du fichier .environment se contente donc de mapper ces informations à ce qu’exige Bedrock.

On utilise ensuite `jq` pour récupérer la route principale vers notre application, puisque l’URL change en fonction de l’environnement (production, staging ou développement), ainsi que la variable de projet `PLATFORM_PROJECT_ENTROPY` pour nos variables de sécurité. Toutes ces variables peuvent être appelées dans notre configuration spécifique à l’environnement (le sous-répertoire `config`). Le reste de la configuration est assez similaire à ce que tu as déjà vu dans notre modèle Composer WordPress pour Platform.sh.

.upsun/config.yaml

.upsun/config.yaml Elle est également similaire, notamment grâce à une étape de hook de build qui nous permet, si on le souhaite, de continuer à utiliser des plugins qui ne peuvent pas être téléchargés en tant que dépendances. Tous les thèmes et plugins WordPress n’ont pas été rendus compatibles avec Composer (leurs développeurs en amont n’incluent pas de fichier `composer.json`), c’est donc toujours une étape utile à inclure. Contrairement au fichier `.platform.app.yaml`, le fichier de configuration d’Upsun Cloud inclut également les routes (`routes.yaml` dans Platform.sh) et nos services (`services.yaml` dans Platform.sh)

# .upsun/config.yaml
applications:
  wp-bedrock-upsun:
    source:
      root: "/"

    type: "php:8.3"

    relationships:
      mariadb:
    
    
    # Mounts define directories that are writable 
    web:
      locations:
        "/":
          root: "web"
          passthru: "/index.php"
          index:
            - "index.php"
          expires: 600s
          scripts: true
          allow: true
          rules:
            ^/composer\.json:
              allow: false
            ^/license\.txt$:
              allow: false
            ^/readme\.html$:
              allow: false
        "/wp/wp-content/uploads":
          root: "web/wp/wp-content/uploads"
          scripts: false
          allow: false
          rules:
          '(?<!\-lock)\.(?i:jpe?g|gif|png|svg|bmp|ico|css|js(?:on)?|eot|ttf|woff|woff2|pdf|docx?|xlsx?|pp[st]x?|psd|odt|key|mp[2-5g]|m4[av]|og[gv]|wav|mov|wm[av]|avi|3g[p2])$':
            allow: true
            expires: 1w
    
    build:
      flavor: none

    dependencies:
      php:
        composer/composer: "^2"

    hooks:
      build: |
        set -eux
        composer --no-ansi --no-interaction install --no-progress --prefer-dist --optimize-autoloader --no-dev
        rsync -a plugins/* web/app/plugins/

    mounts:
      "web/wp/wp-content/cache":
        source: storage
        source_path: "cache"
      "web/wp/wp-content/uploads":
        source: storage
        source_path: "uploads"


# The services of the project.
services:
  mariadb:
    type: mariadb:11.0



# The routes of the project.
routes:
  "https://{default}/":
    type: upstream
    upstream: "wp-bedrock-upsun:http"
  "https://www.{default}":
    type: redirect
    to: "https://{default}/

Grâce à cette configuration, Upsun.com téléchargera chacune de tes dépendances (c’est-à-dire WordPress lui-même, ainsi que tous tes thèmes et plugins), se connectera à la base de données et déploiera Bedrock pour toi.

Espace disque

Une différence notable entre Platform.sh et Upsun.com, c’est que tu ne définis pas l’espace disque que tu alloues à tes services et aux montages d’applications dans le fichier de configuration. À la place, lors de ton premier push, Upsun.com attribuera automatiquement 512 Mo d’espace disque à la fois au service MariaDB et aux montages que WordPress utilisera pour les téléchargements. Pour ajuster l’espace disque alloué à chacun, tu peux soit utiliser la console, soit la commande CLI `upsun resources:set`. Consulte la section « Gérer les ressources » dans la documentation pour plus d’informations. 

On ne sait pas ce que l’avenir réserve à WordPress, mais on peut affirmer sans risque qu’il continuera d’être très populaire. Bedrock offre une méthode pour développer avec WordPress de manière innovante. Les quelques contraintes qu’il impose à la structure de ton projet t’offrent une plus grande flexibilité pour personnaliser rapidement ton site, tout en réduisant considérablement la charge de maintenance à long terme.