Aller au contenu
Photo d’Armand Philippot
Logo d’Armand Philippot

Armand Philippot

Intégrateur web

Installer WordPress avec Composer et Git

Écrit par :
Armand
Publié le :
Mis à jour le :
Temps de lecture :
10 minutes
Thématiques :
Développement

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.
WordPress Composer Git

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 );
define( 'RELOCATE', 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 );
define( 'RELOCATE', 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 :

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 et wordpress-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.

Commentaires

  1. Philippe Etronnier avatar
    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

    1. Armand avatar
      Armand

      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 un composer 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.

      1. Philippe Etronnier avatar
        Philippe Etronnier

        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

    2. Armand avatar
      Armand

      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.

    Laisser un commentaire