WordPress est le système de gestion de contenu hérité. Il est resté extrêmement populaire depuis sa sortie en 2003 pour le pouvoir qu’il donne aux utilisateurs de créer rapidement un site Web avec des outils qui leur offrent un contrôle réel et intuitif sur leur contenu. Cette popularité a à la fois inspiré et dépend des efforts de modernisation constants des fans de WordPress. Le dernier projet à faire en sorte que le CMS classique continue de fonctionner deux décennies après sa naissance est Bedrock, un effort pour transformer WordPress en une application Twelve-Factor 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 de plugins et de 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 packages 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 des 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 répétables et donc plus fiables. Ce sont également les 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 déployez WordPress, le processus d’installation est réputé simple (l’une des nombreuses raisons de l’attrait durable de l’application). Mais maintenir WordPress n’est malheureusement pas si simple. Par exemple, mettre à jour WordPress avec autre chose que des mises à niveau de version mineures peut être un problème. Le projet Bedrock est une tentative de rendre la maintenance de WordPress moins fastidieuse en définissant des thèmes et des plugins comme toute autre dépendance PHP – des composants qui peuvent être installés et mis à jour avec des commandes uniques via un gestionnaire de packages.
Cependant directement sur le système de fichiers de votre site en direct.
De nombreuses solutions d’hébergement, Platform.sh inclus, appliquent des systèmes de fichiers en lecture seule au moment de l’exécution. Ces solutions déploient une image de construction hautement reproductible en 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. Autrement dit, votre application est un artefact de ces définitions plutôt que seulement les fichiers du référentiel seul. 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 toute personne qui 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. De plus, WordPress ne suivra souvent pas le code de ces thèmes et packages dans le contrôle de version, les échangeant simplement lorsque des mises à jour sont nécessaires. Les deux de ces aspects combinés peuvent introduire des vulnérabilités involontaires qui sont totalement introuvables. 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 packages 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 : Composerify 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 engager moins de code, être plus précis dans notre gestion des versions, prendre en charge le déploiement sur plus d’environnements que WordPress ne le permettrait et simplifier considérablement sa maintenance.
Nous avons récemment partagé une méthode de mise à jour de WordPress «vanille» sur Platform.sh en utilisant les opérations source. Cette méthode vous permet de maintenir un système de fichiers en lecture seule, de tout valider dans Git et d’exposer un point de terminaison qui déclenche les mises à jour dans un conteneur séparé qui rend la maintenance WordPress traditionnelle compatible avec notre plate-forme.
Mais vous pouvez également y parvenir en intégrant WordPress à Composer, le système de gestion de packages de PHP. C’est, sans surprise, la méthode recommandée pour déployer WordPress sur Platform.sh depuis un certain temps maintenant. Notre modèle WordPress repose sur le populaire fork de John Bloch Composer, qui reflète la base de code WordPress par défaut, puis ajoute le fichier composer.json nécessaire pour traiter le noyau WordPress comme une dépendance. Ce même modèle est appliqué au vaste écosystème de thèmes et de plugins WordPress, accessible avec Composer à partir du référentiel WPackagist.
Bedrock : le démarreur du développement WordPress
Une grande partie de ce que Bedrock fait différemment commence par la structure de son projet, alors clonons une copie locale du dépôt pour la comparer à la structure typique de WordPress:
├── config /
│ ├── application.php
│ └── environnements /
│ ├── development.php
│ └── staging.php
├── web /
│ ├── application /
│ │ ├── mu-plugins /
│ │ ├── plugins /
│ │ ├── thèmes /
│ │ └── met en ligne /
│ ├── index.php
│ └── wp-config.php
├── compositeur.json
├── composer.lock
├── phpcs.xml
├── wp-admin.png
└── wp-cli.yml
La structure est très différente ici de ce que nous voyons dans WordPress vanille : elle est beaucoup plus petite, pour sa part. La plupart des fichiers qui font fonctionner WordPress – y compris les fichiers de base de WordPress, ainsi que les thèmes et plugins par défaut et personnalisés – ne sont pas réellement engagé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.
« référentiels » :
« php » : « > = 7.1 »,
« compositeur / installateurs » : « ^ 1.8 »,
« vlucas / phpdotenv » : « ^ 5.2 »,
« oscarotero / env » : « ^ 2.1 »,
« roots / bedrock-autoloader » : « ^ 1.0 »,
« roots / wordpress » : « 5.7 »,
« racines / wp-config » : « 1.0.0 »,
« root / wp-password-bcrypt » : « 1.0.0 »,
« wpackagist-theme / corporate-theme-v2 » : « ^ 2.0 »
« rép-install-wordpress » : « web / wp »
Dans l’extrait ci-dessus, roots / wordpress reçoit une version exacte de WordPress: 5.7. Cette même version sera téléchargée lors de chaque build (lorsque l’installation de composer est exécutée) dans un sous-répertoire, ce qui est devenu une pratique populaire même en dehors des versions «composé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 sur une version spécifique pour garantir des constructions répétables. Rien de tout cela n’est validé, et seule cette version spécifique est téléchargée lors d’une commande de construction 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 composer.json a besoin d’une configuration supplémentaire pour prendre en charge cette nouvelle façon de définir les dépendances WordPress. Par défaut, toute dépendance Composer est installée sur un fournisseur de sous-répertoire non validé. Sur Platform.sh, ceci est installé en utilisant notre version de build ou pendant votre hook de build.
Tout ce qui est en amont de WordPress se trouve dans un répertoire, et tout ce que nous ajoutons à WordPress va dans un autre. Vous remarquerez quelque chose de similaire pour votre configuration, qui a été isolée de la configuration, avec un contrôle dépendant de l’environnement. Tout ici a une séparation claire, est contrôlé par version et avec Composer devient reproductible.
Avec cette configuration, nous pouvons faire beaucoup de choses très facilement. Si nous voulons mettre à jour le cœur de WordPress et tous nos thèmes et plugins, tout ce que nous devons faire est d’exécuter la mise à jour du compositeur. Nous pouvons personnaliser l’apparence du site en utilisant un thème de communauté avec le compositeur requiert wpackagist-theme / corporate-theme-v2, puis l’activer dans le tableau de bord d’administration une fois déployé. Si nous voulons étendre le site dans une boutique en ligne, nous pouvons ajouter le plugin WooCommerce de la même manière :
$ composer nécessite wpackagist-plugin / woocommerce
Quiconque essaie de reproduire notre application n’a besoin que d’exécuter l’installation de composer pour commencer à y contribuer. Tout est une dépendance et est complètement installable et actualisable via Composer.
Déploiement de Bedrock sur Platform.sh
Maintenant, tout ce discours serait pour non 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 telles que WP_HOME et WP_SITEURL de manière plus flexible que WordPress traditionnel. C’est un autre composant de l’idée de l’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 la même version, tant que ces variables sont définies. Vous trouverez ci-dessous le fichier.environment inclus dans notre modèle WordPress Bedrock :
#.environnement
jq -r « .database.chemin »)
jq -r « .database.héberger »)
jq -r « .database.Port »)
jq -r « .database.Nom d’utilisateur »)
jq -r « .database.le mot de passe »)
clé’)
export WP_DEBUG_LOG = / var / log / app.log
si ; ensuite
export WP_ENV = ‘développement’
autre
export WP_ENV = ‘production’
Fi
export AUTH_KEY = $ PLATFORM_PROJECT_ENTROPY
export SECURE_AUTH_KEY = $ PLATFORM_PROJECT_ENTROPY
exportation 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
exportation LOGGED_IN_SALT = $ PLATFORM_PROJECT_ENTROPY
export NONCE_SALT = $ PLATFORM_PROJECT_ENTROPY
Nous utilisons jq pour nettoyer et définir les informations d’identification de notre base de données 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 de configuration). La configuration restante est assez similaire à ce que vous avez vu auparavant dans notre modèle WordPress de compositeur.
routes.yaml
Notre fichier routes.yaml est identique à WordPress classique, dirigeant le trafic vers notre application de conteneur d’application.
# routes.yaml
type : en amont
en amont: « app: http »
cache :
activé : vrai
# Basez le cache sur les cookies de session. Ignorez tous les autres cookies.
biscuits:
‘/ ^ wordpress_logged_in_ /’
‘/ ^ wordpress_sec_ /’
« wordpress_test_cookie »
‘/ ^ wp-settings- /’
‘/ ^ wp-postpass /’
type : redirection
services.yaml
Il en va de même pour notre fichier services.yaml, où nous définissons une seule base de données MariaDB 10.4 pour WordPress.
# services.yaml
db :
type : mariadb : 10.4
disque : 2048
platform.app.yaml
platform.app.yaml est également similaire, y compris une étape de construction 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 en amont n’incluent pas de fichier composer.json), c’est donc toujours une étape utile à inclure.
#.platform.app.yaml
nom : app
tapez : « php: 7.4 »
construire :
saveur : compositeur
dépendances:
php:
compositeur / compositeur : ‘^ 2’
wp-cli / wp-cli : « ^ 2.2.0 »
crochets:
set -e
rsync -a plugins / * web / app / plugins /
des relations:
base de données: « db : mysql »
la toile :
Emplacements:
« / » :
racine : « web »
passthru : « /index.php »
indice :
« index.php »
expire : 600
scripts: vrai
autoriser : vrai
des règles:
^ / compositeur.json :
autoriser : faux
^ / licence.txt $ :
autoriser : faux
^ / readme.html $ :
autoriser : faux
« / wp / wp-content / cache » :
root: « web / wp / wp-content / cache »
scripts: faux
autoriser : faux
« / wp / wp-content / uploads » :
root: « web / wp / wp-content / uploads »
scripts: faux
autoriser : vrai
disque : 2048
montures:
« web / wp / wp-content / cache » :
source : locale
source_path: « cache »
« web / wp / wp-content / uploads » :
source : locale
source_path: « uploads »
ainsi que tous vos thèmes et plugins), se connectera à la base de données et déploiera Bedrock pour vous.
Il est impossible de dire quel sera l’avenir de WordPress, mais il est prudent de dire qu’il continuera d’être très populaire. Bedrock fournit une méthode de développement avec WordPress de manière intéressante. Les quelques contraintes qu’elle impose à la structure de votre projet offrent une plus grande flexibilité pour une personnalisation rapide, tout en diminuant considérablement la charge de maintenance à long terme. La prochaine fois que nous examinerons Bedrock, nous explorerons comment il peut être facilement modifié pour exécuter le multisite WordPress. Restez à l’écoute !