Installer WordPress avec Composer et Git
Il n’y a pas si longtemps encore, j’installais WordPress manuellement. Je téléchargeais l’archive sur le site de WordPress, j’extrayais les fichiers et je copiais le tout via SFTP. Cette méthode fonctionne bien, à moins de vouloir utiliser un gestionnaire de version. J’ai donc changé de méthode d’installation pour pouvoir utiliser Git.
Présentation des outils
Pour ceux qui ne les connaîtraient pas encore, voici une brève présentation des outils que nous allons utiliser dans cet article.
- WordPress est un système de gestion de contenu, autrement appelé CMS. Il est libre, écrit en PHP et utilise MySQL. Il est personnalisable grâce à des thèmes et des extensions.
- Composer est un gestionnaire de dépendances. Il est libre et écrit en PHP. Il permet de déclarer et d’installer des bibliothèques nécessaires à un projet.
- Git est un logiciel de gestion de versions décentralisé. Il s’agit également d’un logiciel libre. Il vous permet de stocker un ensemble de fichier en conservant la chronologie des modifications.
La structure du dossier
Pour commencer, et ainsi mieux comprendre les prochaines étapes, voici à quoi ressemblera le projet une fois que WordPress sera installé via Composer.
votresite.test |- .git |- htdocs |--- wp (le « Noyau » de WordPress) |------ wp-admin |------ wp-content (ce dossier est inutile, mais il sera installé) |------ wp-includes |------ les autres fichiers WordPress |--- wp-content (notre dossier content) |------ languages |------ plugins |------ themes |------ uploads |------ vendor |--- index.php |--- wp-config.php |- .gitignore |- composer.json
Étape 1 : créer les fichiers nécessaires
Nous n’allons pas créer manuellement tous les fichiers/répertoires listés précédemment. En fait, la structure de départ va ressembler à ça :
votresite.test |- htdocs |--- index.php |--- wp-config.php |- .gitignore |- composer.json
Comme vous pouvez le voir, les fichiers composer.json
et .gitignore
sont à la racine et nous créons deux fichiers dans le dossier public (htdocs
).
À noter : J’utilise Gandi comme hébergeur. Chaque virtual host comporte un dossier htdocs
correspondant au dossier public. Votre hébergeur utilise peut-être une structure différente (exemple : www
à la place de htdocs
) ; pensez à faire les changements nécessaires (comme renommer le dossier) ici et dans les étapes suivantes.
Étape 2 : configurer WordPress
Les deux fichiers PHP que nous venons de créer vont indiquer à WordPress où se situent les parties « Noyau » (le dossier contenant wp-admin
et wp-includes
) et « Contenu » (notre dossier wp-content
).
Le fichier index.php
Il va indiquer à WordPress l’emplacement du fichier wp-blog-header.php
nécessaire pour exécuter WordPress. Voici son contenu :
<?php
/**
* Define WP Blog Header location..
*
* @package WordPress
*/
define( 'WP_USE_THEMES', true );
require './wp/wp-blog-header.php';
Le fichier wp-config.php
Il est assez classique, mais nous allons lui apporter les modifications suivantes :
- indication du chemin vers le fichier autoload de Composer
- configuration de la base de données
- définition des clés uniques d’authentification et du salage.
- désactivation des mises à jour automatiques et du menu mise à jour
- désactivation de l’édition des fichiers thèmes et plugins
- définition des chemins d’installation pour le « Noyau », les thèmes et les plugins.
Dans ce fichier, juste avant les paramètres MySQL, nous allons insérer une ligne indiquant où se trouve le fichier autoload.php
de Composer. Certains paquets peuvent en avoir besoin.
require __DIR__ . '/wp-content/vendor/autoload.php';
Puis, pour configurer la base de données il faut changer les valeurs suivantes (présentes en début de fichier) :
// Indiquer le nom de votre base de données
define( 'DB_NAME', 'database_name_here' );
// Indiquer votre nom d’utilisateur MySQL
define( 'DB_USER', 'username_here' );
// Indiquer votre mot de passe MySQL
define( 'DB_PASSWORD', 'password_here' );
// Indiquer le nom d’hôte MySQL (généralement localhost)
define( 'DB_HOST', 'localhost' );
// Indiquer l’encodage des tables
define( 'DB_CHARSET', 'utf8' );
// Indiquer le type de collation de la base de données. Ne pas changer si vous ne savez pas ce que c’est.
define( 'DB_COLLATE', '' );
Ensuite, il faut renseigner les clés uniques d’authentification et de salage. Cette étape n’est pas propre à notre installation de WordPress via Composer. Il est recommandé de modifier ces valeurs pour chaque installation de WordPress. Pour cela, il suffit de vous rendre sur le lien indiqué par WordPress et de remplacer ces valeurs par celles générées.
define( 'AUTH_KEY', 'put your unique phrase here' );
define( 'SECURE_AUTH_KEY', 'put your unique phrase here' );
define( 'LOGGED_IN_KEY', 'put your unique phrase here' );
define( 'NONCE_KEY', 'put your unique phrase here' );
define( 'AUTH_SALT', 'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT', 'put your unique phrase here' );
define( 'NONCE_SALT', 'put your unique phrase here' );
Puisque nous allons gérer les mises à jour avec Composer, il faut empêcher WordPress de faire des mises à jour automatiques. Ainsi, si elles ne sont pas déjà présentes dans votre fichier, il faut rajouter ces valeurs :
// Désactiver l’éditeur dans l’interface d’administration
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
// Désactiver les mises à jour
define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'WP_AUTO_UPDATE_CORE', false );
Enfin, nous allons renseigner les chemins d’installation. Pour cette étape, il est important de reprendre les mêmes emplacements que ceux définis dans le fichier composer.json
(étape suivante). En cas d’erreur, pensez à vérifier la concordance des deux fichiers.
// Définir le chemin vers le « noyau » de WordPress. Remplacez par votre nom de domaine.
define( 'WP_SITEURL', 'https://yourdomainname.com/wp' );
// Définir l’URL de notre site. Remplacez par nom de domaine.
define( 'WP_HOME', 'https://yourdomainname.com' );
// Indiquer le chemin vers le dossier « wp-content » (le nôtre, pas celui de WordPress).
define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/wp-content' );
// Indiquer le chemin vers les plugins. La première ligne correspond au chemin indiqué ci-dessus. La seconde indique le nom du répertoire pour les plugins.
define( 'WP_CONTENT_URL', WP_HOME . '/wp-content' );
define( 'WP_PLUGIN_URL', WP_CONTENT_URL . '/plugins' );
Au final, le fichier wp-config.php
ressemble à ça :
<?php
/**
* The base configuration for WordPress.
*
* The wp-config.php creation script uses this file during the
* installation. You don't have to use the web site, you can
* copy this file to "wp-config.php" and fill in the values.
*
* This file contains the following configurations:
*
* * MySQL settings
* * Secret keys
* * Database table prefix
* * ABSPATH
*
* @package WordPress
* @see https://codex.wordpress.org/Editing_wp-config.php
*/
// Composer autoloader
require __DIR__ . '/wp-content/vendor/autoload.php';
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );
// MySQL database username.
define( 'DB_USER', 'username_here' );
// MySQL database password.
define( 'DB_PASSWORD', 'password_here' );
// MySQL hostname.
define( 'DB_HOST', 'localhost' );
// Database Charset to use in creating database tables.
define( 'DB_CHARSET', 'utf8' );
// The Database Collate type. Don't change this if in doubt.
define( 'DB_COLLATE', '' );
/*
// @+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define( 'AUTH_KEY', 'put your unique phrase here' );
define( 'SECURE_AUTH_KEY', 'put your unique phrase here' );
define( 'LOGGED_IN_KEY', 'put your unique phrase here' );
define( 'NONCE_KEY', 'put your unique phrase here' );
define( 'AUTH_SALT', 'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT', 'put your unique phrase here' );
define( 'NONCE_SALT', 'put your unique phrase here' );
// #@-
/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'wp_';
/*
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*
* For information on other constants that can be used for debugging,
* visit the Codex.
*
* @link https://codex.wordpress.org/Debugging_in_WordPress
*/
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false );
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SAVEQUERIES', false );
/*
* Custom WordPress Install Path.
*/
// Sets the site's admin location and the site's location, respectively.
define( 'WP_SITEURL', 'https://yourdomainname.com/wp' );
define( 'WP_HOME', 'https://yourdomainname.com' );
// Sets the content location, related to what's defined on composer.json file.
define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/wp-content' );
// Sets the plugins location, related to what's defined on composer.json file.
define( 'WP_CONTENT_URL', WP_HOME . '/wp-content' );
define( 'WP_PLUGIN_URL', WP_CONTENT_URL . '/plugins' );
// Disables the embebeded editor.
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
// Disables automatic update functions.
define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'WP_AUTO_UPDATE_CORE', false );
/*
* SSL
* You might want to force SSL on the admin page
*/
define( 'FORCE_SSL_ADMIN', true );
// That's all, stop editing! Happy publishing.
// Absolute path to the WordPress directory.
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', dirname( __FILE__ ) . '/' );
}
/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';
Étape 3 : le fichier composer.json
Dans le fichier composer.json
, nous allons indiquer les paquets à installer, leur dépôt distant (où récupérer les fichiers) et les dossiers d’installation. Je me suis inspiré de la recette d’Andrey “Rarst” Savchenko pour configurer ce fichier. Cependant, je préfère utiliser le dépôt Github de WordPress pour récupérer les fichiers.
Pour cette étape, il est important de reprendre les mêmes emplacements que ceux définis dans le fichier wp-config.php
(étape précédente). En cas d’erreur, pensez à vérifier la concordance des deux fichiers.
Définir les repositories
Dans la propriété repositories
, nous indiquons les différents dépôts distants que nous allons utiliser :
- WordPress Packagist pour installer des thèmes et plugins wordpress,
- Le dépôt Github de WordPress pour installer WordPress.
Voici le détail :
"repositories": [
{
"type": "composer",
"url": "https://wpackagist.org",
"only": [
"wpackagist-plugin/*",
"wpackagist-theme/*"
]
},
{
"type": "package",
"package": {
"name": "wordpress/wordpress",
"type": "wordpress-core",
"version": "5.7.1",
"source": {
"url": "https://github.com/WordPress/WordPress.git",
"type": "git",
"reference": "5.7.1"
}
}
}
],
Puisque le dépôt de WordPress ne dispose pas de fichier composer.json
, nous devons le définir en tant que package
et ajouter certaines précisions. Nous ajoutons également un type
pour pouvoir l’installer ailleurs que dans le dossier vendor
.
Définir nos paquets
Dans la propriété require
, nous indiquons les paquets à installer :
- le premier permet d’utiliser les types définis par Composer pour personnaliser les chemins d’installation (
wordpress-theme
etwordpress-plugin
par exemple), - le deuxième permet d’étendre ces types (il va servir à installer notre type
wordpress-core
), - WordPress,
- un thème, ici twentytwenty, mais vous pouvez en utiliser un autre,
- un plugin, de même vous pouvez le remplacer, il est là pour la démonstration,
- un outil permettant de télécharger les traductions pour WordPress, les plugins et les thèmes.
"require": {
"composer/installers": "^1.10",
"oomphinc/composer-installers-extender": "^2.0",
"wordpress/wordpress": "5.7.1",
"wpackagist-theme/twentytwenty": "*",
"wpackagist-plugin/akismet": "^4.1.5",
"inpsyde/wp-translation-downloader": "^2.0"
},
À noter : si vous avez déjà téléchargé les traductions (donc lorsque vous faites une mise à jour), inpsyde/wp-translation-downloader
peut afficher des Failed to execute[...]
. Malgré ça, il fonctionne correctement ; ce n’est pas vraiment un bug et le problème est en cours de discussion.
Config & Extra
Dans la propriété config
, nous allons indiquer où installer le dossier vendor
.
"config": {
"vendor-dir": "htdocs/wp-content/vendor"
},
Dans la propriété extra
nous indiquons les différents chemins d’installation grâce aux types :
wordpress-muplugin
est lié àhtdocs/wp-content/mu-plugins
,wordpress-plugin
est lié àhtdocs/wp-content/plugins
,wordpress-theme
est lié àhtdocs/wp-content/themes
,wordpress-core
est lié àhtdocs/wp
,- les fichiers de traduction iront dans
htdocs/wp-content/languages
.
Voici le détail :
"extra": {
"installer-types": ["wordpress-core"],
"installer-paths": {
"htdocs/wp/": [
"type:wordpress-core"
],
"htdocs/wp-content/mu-plugins/{$name}/": [
"type:wordpress-muplugin"
],
"htdocs/wp-content/plugins/{$name}/": [
"type:wordpress-plugin"
],
"htdocs/wp-content/themes/{$name}/": [
"type:wordpress-theme"
]
},
"wp-translation-downloader": {
"languages": [
"fr_FR"
],
"directory": "htdocs/wp-content/languages"
}
}
Le fichier final
{
"name": "armandphilippot/wordpress",
"description": "WordPress installation with Composer",
"keywords": [
"wordpress", "composer"
],
"version": "1.0.0",
"license": "GPL-2.0-or-later",
"authors": [
{
"name": "Armand Philippot",
"homepage": "https://wp.armandphilippot.com/"
}
],
"type": "post",
"require": {
"composer/installers": "~1.0",
"wordpress/wordpress": "5.3.2",
"koodimonni-language/core-fr_fr": "*",
"wpackagist-theme/twentytwenty": "*",
"wpackagist-plugin/akismet": "dev-trunk"
},
"repositories": [
{
"type": "composer",
"url": "https://wpackagist.org"
},
{
"type": "package",
"package": {
"name": "wordpress/wordpress",
"type": "webroot",
"version": "5.3.2",
"source": {
"url": "https://github.com/WordPress/WordPress.git",
"type": "git",
"reference": "5.3.2"
},
"require": {
"fancyguy/webroot-installer": "^1.0.0"
}
}
},
{
"type": "composer",
"url": "https://wp-languages.github.io"
}
],
"config": {
"vendor-dir": "htdocs/wp-content/vendor"
},
"extra": {
"installer-paths": {
"htdocs/wp-content/plugins/{$name}/": [
"type:wordpress-plugin"
],
"htdocs/wp-content/themes/{$name}/": [
"type:wordpress-theme"
]
},
"webroot-dir": "htdocs/wp",
"webroot-package": "wordpress/wordpress",
"wordpress-install-dir": "htdocs/wp",
"dropin-paths": {
"htdocs/wp-content/languages/": [
"vendor:koodimonni-language"
],
"htdocs/wp-content/languages/plugins/": [
"vendor:koodimonni-plugin-language"
],
"htdocs/wp-content/languages/themes/": [
"vendor:koodimonni-theme-language"
]
}
}
}
Étape 4 : le fichier .gitignore
Dans le fichier .gitignore
, nous allons indiquer à Git d’ignorer certains fichiers et dossiers.
# Ignorer les dépendances
**/node_modules/
**/vendor/
# Ignorer le répertoire wp
htdocs/wp/
# Ne pas ignorer le répertoire wp-content mais ignorer son contenu
!htdocs/wp-content/
htdocs/wp-content/*
# Ne pas ignorer le répertoire themes mais ignorer son contenu
!htdocs/wp-content/themes
htdocs/wp-content/themes/*
# Ne pas ignorer ce thème
!htdocs/wp-content/themes/your-custom-theme
# Ne pas ignorer le répertoire plugins mais ignorer son contenu
!htdocs/wp-content/plugins
htdocs/wp-content/plugins/*
# Ne pas ignorer ces plugins
!htdocs/wp-content/plugins/your-custom-plugin1
!htdocs/wp-content/plugins/your-custom-plugin2
# Ne pas ignorer le répertoire mu-plugins mais ignorer son contenu
!htdocs/wp-content/mu-plugins
!htdocs/wp-content/mu-plugins/*
# Ne pas ignorer ces mu-plugins
!htdocs/wp-content/mu-plugins/your-custom-mu-plugin1.php
!htdocs/wp-content/mu-plugins/your-custom-mu-plugin2.php
Étape finale
Tout est prêt. Il nous reste à initier Git et à lancer l’installation via Composer. À la racine du projet, ouvrez un terminal et saisissez :
git init
composer install
Vous pouvez maintenant utiliser Git pour versionner votre projet ! Si vous avez des paquets à mettre à jour, il vous suffira de lancer la commande composer update
dans votre terminal.
Épilogue
Il ne vous reste plus qu’à configurer le fichier composer.json
pour qu’il corresponde à vos besoins en termes de thèmes et plugins notamment. J’ai créé deux repos : un sur Github, l’autre sur Gitlab. Vous pouvez récupérer les fichiers de base pour installer WordPress.
5 commentaires
Bonjour,
Je n’ai jamais utilisé Bedrock, donc je ne peux pas répondre à vos questions précisément.
De ce que j’ai lu sur Bedrock, le principe est assez similaire. Il utilise des chemins personnalisés pour installer WordPress. La principale différence repose sur l’architecture. Bedrock définit pour nous une architecture précise. Avec la solution de cet article, c’est à nous de définir notre propre architecture.
En dehors de cet aspect, Bedrock intègre d’autres fonctionnalités comme l’utilisation de dotenv et la définition d’environnements de production. Ici, ce n’est pas le cas. Il s’agit simplement d’une base pour pouvoir installer WordPress avec Composer. Si on souhaite ajouter d’autres choses comme l’utilisation de dotenv, il faut l’ajouter soi-même.
Enfin, Bedrock utilise le dépôt de root pour installer WordPress. Ici, on récupère WordPress directement sur le dépôt Github de WordPress.
Concernant les avantages, Bedrock semble être utilisé par un grand nombre de personnes donc le système doit être efficace et il est toujours activement maintenu. Ici, il n’y a pas de maintenance active. Chacun peut utiliser cette méthode pour installer WordPress. Il faudra ensuite éditer le fichier composer pour mettre à jour la version de WordPress à chaque nouvelle version. Je suppose que les mainteneurs de Bedrock font ça de leur côté et, pour l’utilisateur, il suffit de faire uncomposer update
. Je dirai que les deux solutions ont leurs avantage ; tout dépend de ce que l’on souhaite faire je pense.
Je ne peux pas tellement vous en dire plus puisque je n’ai pas utilisé Bedrock. J’espère que ma réponse vous aura tout de même un peu éclairé sur les différences entre les deux.Merci pour votre réponse
Voilà trois ans que j’utilise Bedrock sur les sites WordPress que j’ai développés.
La mise à jour de WordPress via le dépot roots, github ou packagist peut être automatisée en mettant par exemple require “wordpress/wordpress”: “^5.0.0” au lieu de la version précise actuelle.
Un cron sur mes sites en production se charge ensuite de faire la mise à jour quotidienne de wordpress et des plugins que j’ai développés (hébergés sur gitlab) avec un simple composer update.
Cordialement
Depuis, j’ai pu tester Bedrock et effectivement c’est une bonne solution.
Par contre… ça ne fonctionne pas forcément avec les hébergements mutualisés comme Gandi Simple Hosting. Je ne suis pas sûr d’identifier correctement l’origine du problème. Je pense que cela vient du dossier vendor ou de la config… les deux sont en dehors du dossier public, il doit y avoir des problèmes de droits pour y accéder.
Avec la solution présentée ici, il n’y a pas ce problème.
Bonjour,
Merci pour ce tuto, par contre vous pouvez expliquer pourquoi avoir mi RELOCATE à true ? Ca pose des soucis de notre côté, et en fouillant dans le code source de WP je ne vois pas l’intérêt de le mettre, mais peut etre que je loupe quelque chose
Merci
Bonsoir,
Honnêtement, je ne sais plus. L’article date de 2020, il y a eu quelques changements dans WordPress (et sa doc) depuis et je n’ai pas touché à WordPress récemment. J’aurai dû mieux documenter l’article au moment de sa rédaction.
D’après ce que je lis dans la documentation, ce n’est pas indispensable/utile. L’intérêt est de mettre à jour l’adresse du site dans la base de données ; ce qui peut servir à corriger l’adresse utilisée en développement/production. J’ai dû la laisser là entre mes différents essais. Ce qui est une erreur d’après la doc… Il est déconseillé de laisser cette ligne en permanence dans le fichierwp-config.php
. Bref, ça ne semble pas lié à l’utilisation de WordPress avec Git et Composer et ça devrait fonctionner sans cette instruction.
Je n’ai pas testé sans, mais je vais mettre à jour l’article en supprimant cette ligne puisqu’elle ne semble pas utile et qu’elle peut être à l’origine de problèmes de sécurité. Merci d’avoir porté mon attention sur cette erreur !
Philippe Etronnier
Bonjour
Article intéressant
J’utilise Bedrock pour pouvoir utiliser Composer avec WordPress.
Votre système est il différent? Et quels en seraient les avantages?
Cordialement
Philippe Etronnier