WordPress, PHP en la webstack : ce qui tourne vraiment sous le capot

Ce guide s'adresse à qui doit installer, configurer ou débugger une pile WordPress sur un serveur Linux — pas à qui cherche un thème. On part d'un VPS ou d'un serveur dédié sous Ubuntu 22.04 ou Debian 12, avec un accès root ou sudo.

Prérequis

• Ubuntu 22.04 LTS ou Debian 12 (les commandes `apt` ci-dessous valent pour les deux).
• Un accès SSH avec un utilisateur dans le groupe `sudo`.
• Un nom de domaine qui pointe déjà vers l'IP du serveur.
• Nginx 1.18 ou plus récent (celui des dépôts Ubuntu 22.04 est en 1.18, Debian 12 en 1.22).
• PHP 8.1 ou 8.2. WordPress fonctionne encore sur PHP 7.4, mais 7.4 n'est plus maintenu depuis novembre 2022 et ne reçoit plus de correctifs de sécurité. Sur une install neuve en 2024, partir sur 7.4 n'a aucun sens.
• MariaDB 10.6 ou plus récent.

Étape 1 — Installer la pile

On installe Nginx, MariaDB, PHP-FPM et les extensions dont WordPress a besoin. L'extension `php-mysql` est celle qui permet à PHP de parler à MariaDB ; sans elle, l'installateur WordPress te renverra une erreur de connexion à la base sans plus de détail.

```bash sudo apt update sudo apt install -y nginx mariadb-server php8.1-fpm php8.1-mysql \ php8.1-curl php8.1-gd php8.1-mbstring php8.1-xml php8.1-zip php8.1-imagick ```

Sur Debian 12, remplace `php8.1` par `php8.2` partout. Les deux versions sont supportées par WordPress 6.x.

Étape 2 — Créer la base de données

WordPress stocke tout — articles, réglages, utilisateurs, commentaires, métadonnées — dans des tables relationnelles. On crée une base dédiée et un utilisateur qui n'a accès qu'à celle-là.

```bash sudo mariadb -u root ```

Puis, dans le prompt MariaDB :

```sql CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'un_mot_de_passe_long_et_unique'; GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost'; FLUSH PRIVILEGES; EXIT; ```

`utf8mb4` et pas `utf8` : le `utf8` de MySQL ne code que sur 3 octets et casse les emojis et certains caractères asiatiques. WordPress utilise `utf8mb4` depuis la version 4.2.

Étape 3 — Configurer PHP-FPM

PHP-FPM (FastCGI Process Manager) gère les processus PHP séparément de Nginx. C'est ce qui permet de redémarrer PHP sans toucher au serveur web, et de limiter la mémoire par pool.

Ouvre le pool par défaut :

```bash sudo nano /etc/php/8.1/fpm/pool.d/www.conf ```

Vérifie ces lignes (les valeurs par défaut conviennent pour un petit site) :

```ini user = www-data group = www-data listen = /run/php/php8.1-fpm.sock listen.owner = www-data listen.group = www-data pm = dynamic pm.max_children = 20 pm.start_servers = 4 pm.min_spare_servers = 2 pm.max_spare_servers = 6 ```

`pm.max_children` à 20, c'est environ 20 requêtes PHP simultanées. Chaque processus PHP consomme entre 40 et 80 Mo selon les plugins. Si ton VPS a 2 Go de RAM, ne monte pas plus haut sans mesurer.

Redémarre :

```bash sudo systemctl restart php8.1-fpm ```

Étape 4 — Configurer Nginx

Nginx ne sait pas exécuter PHP. Il transmet les requêtes `.php` à PHP-FPM via FastCGI, et sert les fichiers statiques (images, CSS, JS) directement. C'est cette séparation qui rend Nginx rapide sous charge.

Crée le fichier de site :

```bash sudo nano /etc/nginx/sites-available/wordpress ```

Contenu :

```nginx server { listen 80; server_name exemple.be www.exemple.be; root /var/www/wordpress; index index.php index.html;

location / { try_files $uri $uri/ /index.php?$args; }

location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; }

location ~ /\.ht { deny all; }

location = /wp-config.php { deny all; } } ```

Le bloc `try_files` est ce qui fait fonctionner les permaliens WordPress : toute URL qui ne correspond pas à un fichier réel est renvoyée vers `index.php`. Sans lui, tes articles renvoient des 404 alors que l'accueil fonctionne.

Le bloc `location = /wp-config.php` bloque l'accès direct au fichier de configuration. Ce fichier contient le mot de passe de la base en clair.

Active le site et recharge :

```bash sudo ln -s /etc/nginx/sites-available/wordpress /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx ```

`nginx -t` teste la syntaxe avant de recharger. Si tu recharges sans tester et que le fichier contient une erreur, Nginx continue de tourner avec l'ancienne config et tu chercheras le problème au mauvais endroit.

Étape 5 — Télécharger WordPress

```bash cd /tmp curl -O https://wordpress.org/latest.tar.gz tar xzf latest.tar.gz sudo mv wordpress /var/www/wordpress sudo chown -R www-data:www-data /var/www/wordpress sudo find /var/www/wordpress -type d -exec chmod 755 {} \; sudo find /var/www/wordpress -type f -exec chmod 644 {} \; ```

Les permissions comptent. `755` sur les dossiers et `644` sur les fichiers empêchent le serveur web d'écrire là où il ne devrait pas. WordPress a besoin d'écrire uniquement dans `wp-content/uploads` pour les médias.

Étape 6 — Créer wp-config.php

```bash cd /var/www/wordpress sudo cp wp-config-sample.php wp-config.php sudo nano wp-config.php ```

Renseigne les quatre valeurs :

```php define( 'DB_NAME', 'wordpress' ); define( 'DB_USER', 'wpuser' ); define( 'DB_PASSWORD', 'un_mot_de_passe_long_et_unique' ); define( 'DB_HOST', 'localhost' ); ```

Puis récupère les clés de sécurité depuis l'API WordPress et colle-les :

```bash curl -s https://api.wordpress.org/secret-key/1.1/salt/ ```

Ces clés signent les cookies de session. Si tu les laisses aux valeurs par défaut du fichier d'exemple, n'importe qui peut forger un cookie administrateur.

Étape 7 — Terminer l'installation

Ouvre `http://exemple.be` dans un navigateur. WordPress te demande le titre du site, un nom d'utilisateur admin et un mot de passe.

Évite `admin` comme nom d'utilisateur. C'est le premier identifiant que les scripts de brute force essaient, et le changer après coup demande une requête SQL manuelle.

Étape 8 — HTTPS avec Certbot

```bash sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d exemple.be -d www.exemple.be ```

Certbot modifie ta config Nginx et installe un timer systemd qui renouvelle le certificat automatiquement. Let's Encrypt délivre des certificats de 90 jours ; le renouvellement est automatique, mais vérifie une fois que le timer tourne :

```bash systemctl list-timers | grep certbot ```

Vérification

Trois commandes pour confirmer que tout tient debout :

```bash systemctl status nginx php8.1-fpm mariadb curl -I https://exemple.be sudo -u www-data php /var/www/wordpress/wp-cron.php ```

La première doit montrer les trois services en `active (running)`. La deuxième doit renvoyer `HTTP/2 200` et un en-tête `server: nginx`. La troisième exécute les tâches planifiées de WordPress sans erreur — si elle affiche un message sur la base de données, la config est fausse.

Problèmes courants

« Error establishing a database connection » — l'utilisateur MariaDB n'a pas les droits, ou le mot de passe dans `wp-config.php` ne correspond pas. Teste directement :

```bash mysql -u wpuser -p wordpress -e "SELECT 1;" ```

Erreur 502 Bad Gateway — Nginx ne trouve pas le socket PHP-FPM. Vérifie que le chemin dans `fastcgi_pass` correspond exactement à `listen` dans `www.conf`, et que PHP-FPM tourne.

Les permaliens renvoient 404, l'accueil fonctionne — il manque le bloc `try_files` dans la config Nginx, ou le module `rewrite` n'est pas actif. Corrige la config et recharge.

Ce que cette pile ne fait pas

Elle ne met pas en cache. Chaque visite déclenche une exécution PHP et une ou plusieurs requêtes SQL. Sur un site à faible trafic, ça passe. Au-delà de quelques dizaines de visiteurs simultanés, il faut ajouter Redis pour le cache objet et un cache de page côté Nginx.

Elle ne sauvegarde rien non plus. MariaDB tourne, mais si le disque tombe, la base tombe avec. `mysqldump` dans un cron, ou un snapshot du VPS — les deux, idéalement.

Le reste, c'est du réglage.