WordPress est le système de gestion de contenu historique. Il est resté extrêmement populaire depuis sa sortie en 2003 pour la puissance qu'il offre aux utilisateurs de créer rapidement un site web avec des outils qui leur donnent un contrôle réel et intuitif sur leur contenu. Cette popularité a à la fois inspiré et dépendu des efforts constants de modernisation déployés par les adeptes de WordPress. Le dernier projet en date pour maintenir le CMS classique en marche deux décennies après sa naissance est Bedrock, un effort de l'équipe de Roots pour transformer WordPress en une application Twelve-Factor.
Roots est une équipe de développeurs qui crée et maintient des outils pour améliorer le processus de développement de WordPress. Certains de leurs projets se concentrent sur la standardisation du développement des plugins et des thèmes. Bedrock, cependant, se concentre sur l'installation de WordPress elle-même, simplifiant la configuration et la personnalisation en s'intégrant complètement au gestionnaire de paquets PHP, Composer.
Avec Bedrock, Roots tente de rapprocher WordPress de la méthodologie de l'application Twelve-Factor. Twelve-Factor est une sorte de guide des "bonnes pratiques" qui n'est satisfait 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 extraite de 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 également deux fonctionnalités que WordPress ne suit pas par défaut, ce qui rend la maintenance beaucoup plus difficile.
Maintenance des sites WordPress
Une fois que vous avez déployé WordPress, le processus d'installation est notoirement simple (l'une des nombreuses raisons de l'attrait durable de l'application). Mais la maintenance de WordPress n'est malheureusement pas si simple. Par exemple, la mise à jour de WordPress, à l'exception des mises à jour mineures, peut s'avérer fastidieuse. Le projet Bedrock tente de rendre la maintenance de WordPress moins contraignante en définissant les thèmes et les plugins comme n'importe quelle autre dépendance PHP - des composants qui peuvent être installés et mis à jour avec de simples commandes via un gestionnaire de paquets.
Lorsqu'une mise à jour est disponible, WordPress propose un bouton qui permet aux administrateurs de télécharger et de remplacer 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 au moment de l'exécution. Ces solutions déploient une image de build hautement reproductible, conséquence de votre base de code et de son processus de build explicitement défini, tous engagés dans le contrôle de version. En d'autres termes, votre application est un artefact de ces définitions plutôt que de simples fichiers dans le référentiel. Le code externe (dépendances) dont dépend votre application, et idéalement les définitions de votre infrastructure elle-même, sont commis à des versions exactes afin que l'ensemble de votre processus DevOps, du début à la fin, soit répétable et reproductible par quiconque en a besoin. C'est une bonne chose.
En comparaison, WordPress nécessite un accès en écriture au serveur afin que les plugins et les thèmes puissent être mis à jour au moment de l'exécution. En plus, WordPress ne suit pas le code de ces thèmes et packages dans le contrôle de version de votre site, se contentant de les échanger lorsque des mises à jour sont nécessaires. Ces deux aspects combinés peuvent introduire des vulnérabilités involontaires totalement intraçables. Si les thèmes et les plugins sont sous contrôle de version, ils peuvent rapidement alourdir votre base de code. Étant donné que Bedrock traite ces composants comme des dépendances, rien n'est écrit au moment de l'exécution et les paquets individuels n'ont pas besoin d'être commis, ce qui permet d'éliminer à la fois les vulnérabilités et le gonflement..
La solution Bedrock : Composerifier WordPress !
Composer est au cœur de tout pour Bedrock. Si nous pouvons traiter le cœur de WordPress et toutes nos personnalisations comme des dépendances, nous pouvons commettre moins de code, être plus spécifiques dans notre versioning, prendre en charge le déploiement sur plus d'environnements que WordPress ne le permettrait, et simplifier drastiquement sa maintenance.
Nous avons récemment partagé une méthode pour mettre à jour WordPress "vanilla" sur Upsun en utilisant Source Operations. Cette méthode vous permet de maintenir un système de fichiers en lecture seule, de tout commiter sur Git, et d'exposer un point de terminaison qui déclenche les mises à jour dans un conteneur séparé qui rend la maintenance traditionnelle de WordPress compatible avec notre plateforme.
Mais vous pouvez également y parvenir en intégrant WordPress à Composer, le système de gestion de paquets de PHP. C'est, sans surprise, la méthode recommandée pour déployer WordPress sur Platform.sh depuis un certain temps. Notre modèle WordPress s'appuie sur le populaire John Bloch Composer fork, qui reflète la base de code WordPress par défaut et ajoute ensuite le fichier composer.json nécessaire pour traiter le noyau de WordPress comme une dépendance. Ce même modèle est appliqué au vaste écosystème de thèmes et de plugins WordPress, accessibles avec Composer depuis le dépôt WPackagist.
Bedrock : le starter du développement WordPress
Une grande partie de ce que Bedrock fait différemment commence par sa structure de projet, alors clonons une copie locale du dépôt pour comparer avec la structure typique 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.ymlLa structure est très différente de celle de WordPress vanilla : elle est beaucoup plus petite, d'abord. La plupart des fichiers qui permettent à WordPress de fonctionner, y compris les fichiers de base de WordPress, ainsi que les thèmes et les plugins par défaut et personnalisés, ne sont pas réellement déposés dans le référentiel. Au lieu de cela, ces fichiers sont téléchargés à la volée en tant que dépendances pour l'application finale, toutes définies 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, roots/wordpress se voit attribuer une version exacte de WordPress : 6.6.1. Cette même version sera téléchargée lors de chaque compilation (lors de l'exécution de composer install ) dans un sous-répertoire, ce qui est devenu une pratique populaire même en dehors des versions "Composerifiées" de WordPress.
Nous nous éloignons déjà de certains des problèmes décrits ci-dessus. WordPress est une dépendance, que l'on peut définir explicitement et verrouiller à une version spécifique pour garantir des builds reproductibles. Rien n'est commis, et seule cette version spécifique est téléchargée lors d'une commande de build composer install.
Extension de WordPress avec Composer
Il en va de même pour les thèmes et les plugins. Mais vous remarquerez que le fichier composer.json a besoin d'une configuration supplémentaire pour supporter cette nouvelle façon de définir les dépendances de WordPress. Par défaut, toute dépendance de Composer est installée dans un sous-répertoire vendor non commité. Sur Platform.sh, cela est installé en utilisant notre falor de build ou pendant votre hook build.
Le problème est que ce n'est pas l'endroit où nous aimerions que le noyau de WordPress se retrouve. Dans l'extrait ci-dessus, vous verrez les attributs extra.wordpress-install-dir et extra.installer-paths. Le premier indique à Composer (en utilisant composer/installers) de télécharger la version de WordPress que nous avons définie dans web/wp et le second d'installer les thèmes et les plugins dans web/app. Tout ce qui est en amont de WordPress est dans un répertoire, et tout ce que nous ajoutons à WordPress est dans un autre. Vous remarquerez quelque chose de similaire pour votre configuration, qui a été isolée dans config, avec un contrôle dépendant de l'environnement. Tout ici est clairement séparé, est contrôlé par version et, grâce à Composer, devient reproductible.
Avec cette configuration, nous pouvons faire beaucoup de choses très facilement. Si nous voulons mettre à jour le noyau de WordPress et tous nos thèmes et plugins, tout ce que nous avons à faire est d'exécuter composer update. Nous pouvons personnaliser l'apparence du site en utilisant un thème communautaire avec composer require wpackagist-theme/magsoul, (à titre d'exemple) puis l'activer dans le tableau de bord de l'administrateur une fois déployé. Si nous voulons étendre le site en une boutique en ligne, nous pouvons ajouter le plugin WooCommerce de la même manière :
$ composer require wpackagist-plugin/woocommerceSi nous voulons pouvoir gérer l'application en utilisant le CLI de WordPress :
$ composer require wp-cli/wp-cliToute personne essayant de reproduire notre application n'a qu'à lancer composer install pour commencer à y contribuer. Tout est une dépendance et peut être installé et mis à jour via Composer.
Déploiement de Bedrock sur Upsun.com
Maintenant, tout ce discours ne servirait à rien si nous n'abordions pas les déploiements, et c'est ici que Bedrock ouvre vraiment la configuration pour le faire. Bedrock vous permet d'utiliser des variables d'environnement pour vous connecter à la base de données et de 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 composant de l'idée d'application 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 le même build, tant que ces variables sont définies. Voici un fichier .environment similaire inclus dans notre modèleWordPress Bedrock pour platform.sh (qui fonctionne à l'identique sur Upsun) :
# .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_ENTROPYLes informations de notre service de base de données sont exposées sous 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, je l'ai nommé mariadb, donc les informations du service sont préfixées par MARIADB_*. Cependant, Bedrock a besoin que les variables d'environnement soient préfixées par DB_, donc le premier bloc dans le fichier .environment mappe simplement les informations à ce que Bedrock exige.
Nous utilisons ensuite jq pour récupérer la route principale vers notre application puisque l'URL changera en fonction de l'environnement (production vs staging vs development), et la variable de projet PLATFORM_PROJECT_ENTROPY pour nos variables de sécurité, toutes pouvant ê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 vous avez déjà vu dans notre modèle WordPress Composer pour Platform.sh.
.upsun/config.yamlLe fichier .upsun/config.yaml est également similaire, incluant une étape de build hook qui nous permet, si nous le souhaitons, 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 sources amont n'incluent pas de fichier composer.json ), c'est donc toujours une étape utile à inclure. Contrairement à .platform.app.yaml, le fichier de configuration d'Upsun 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}/Avec cette configuration, Upsun.com téléchargera chacune de vos dépendances (qui est encore une fois WordPress lui-même, ainsi que tous vos thèmes et plugins), se connectera à la base de données, et déploiera Bedrock pour vous.
Espace disque
Une différence notable entre Platform.sh et Upsun.com est que vous ne définissez pas la quantité de disque que vous allouez à vos services et aux montages d'applications dans le fichier de configuration. Au lieu de cela, la première fois que vous pousserez, Upsun.com attribuera automatiquement 512MB de disque au service MariaDB et aux montages que WordPress utilisera pour les téléchargements. Pour ajuster l'espace disque alloué à chacun, vous pouvez utiliser la console ou la commande CLI upsun resources:set. Reportez-vous à la section Gérer les ressources dans la documentation pour plus d'informations.
Il est impossible de dire quel sera l'avenir de WordPress, mais on peut affirmer qu'il continuera à être très populaire. Bedrock offre une méthode de développement avec WordPress de manière intéressante. Les quelques contraintes qu'il impose à la structure de votre projet ouvrent une plus grande flexibilité pour personnaliser rapidement, tout en diminuant considérablement la charge de maintenance à long terme.
Votre meilleur travail
est à l'horizon
