La base du développement moderne de WordPress

WordPress est le système de gestion de contenu par excellence. Il est resté extrêmement populaire depuis sa sortie en 2003 en raison de la possibilité qu'il offre aux utilisateurs de créer rapidement un site web à l'aide d'outils leur permettant d'exercer 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 visant à maintenir le CMS classique en activité deux décennies après sa naissance est Bedrock, un effort visant à transformer WordPress en une application à douze facteurs par les gens de Roots.

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 "meilleures 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 constructions reproductibles et donc plus fiables. Ce sont également des caractéristiques que WordPress ne suit pas par défaut, ce qui rend la maintenance beaucoup plus difficile.

Maintenir les 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 construction hautement reproductible, conséquence de votre base de code et de son processus de construction 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 engagés dans 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 outre, 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ésinvolontaires qui ne sont absolument pas traçables. Si les thèmes et les plugins sont contrôlés par version, ils peuvent rapidement gonfler votre base de code. Puisque 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 validés, ce qui permet d'éliminer à la fois les vulnérabilités et le gonflement.

La solution Bedrock : Composer 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 livrer moins de code, être plus spécifiques dans nos versions, supporter 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 "vanille" 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 aussi accomplir cela en intégrant WordPress avec 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ôtWPackagist.

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.yml

La structure est très différente de celle de WordPress vanille : 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 reçoit une version exacte de WordPress : 6.6.1. Cette même version sera téléchargée lors de chaque compilation (lorsque composer install est lancé) 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, qui peut être explicitement définie et verrouillée à une version spécifique pour assurer des constructions répétables. Aucune version n'est engagée, et seule cette version spécifique est téléchargée lors d'une commande d'installation de Composer.

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 validé. Sur Platform.sh, cela est installé en utilisant notre saveur de construction ou pendant votre crochet de construction.

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 de lancer 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 pluginWooCommerce de la même manière :

$ composer require wpackagist-plugin/woocommerce

Si nous voulons pouvoir gérer l'application en utilisant le CLI de WordPress :

$ composer require wp-cli/wp-cli

Toute 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éployer 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 une autre composante de l'idée de l'application à douze facteurs : la configuration stockée dans l'environnement. L'application peut être déplacée dans de nombreux environnements différents et conserver la même construction, tant que ces variables sont définies. Voici un fichier .environment similaire inclus dans notre modèle Platform.sh WordPress Bedrock (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 # Décommentez cette ligne si vous souhaitez des versions de développement de WordPress sur des environnements de non-production.
# 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

Nos informations sur le 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, je l'ai nommé mariadb donc les informations de service sont préfixées avec MARIADB_*. Cependant, Bedrock a besoin que les variables d'environnement soient préfixées par DB_, donc le premier bloc du fichier .environment est simplement le mappage de l'information à 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é, qui peuvent toutes ê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 template WordPress pour Platform.sh.

.upsun/config.yaml

.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 upstreams 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 : # Les montages définissent des répertoires accessibles en écriture 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" # Les services du projet. services : mariadb : type : mariadb:11.0 # Les routes du projet. 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 fournit une méthode pour développer avec WordPress de manière intéressante. Les quelques contraintes qu'il impose à la structure de votre projet offrent une plus grande flexibilité pour personnaliser rapidement, tout en réduisant considérablement le fardeau de la maintenance à long terme.