Créer un site staging pour WordPress sur un sous-domaine

Le Centre de Kriya Yoga France n’avait pas de site staging, ce site de développement et de test qui permet de tester, développer ou mettre à jour de nouvelles extensions, sans affecter le site principal.

Une des extensions a eu besoin d’être débugguée par ses concepteurs mais pour des raisons de confidentialité, il nous est apparu intéressant et plus sécurisé de donner accès à un site de développement, fraîche copie du site original, pour le débuggage.

Si vous avez besoin de créer un site staging pour votre site WordPress et que votre hébergeur ne le propose pas, voici comment faire.

Étape 1 : créer un sous-domaine au niveau DNS

Nous choisissons la solution la plus simple: servir le site STAGING depuis un sous-domaine. Il suffit de créer un nouvel enregistrement DNS sous la forme:

staging IN A xxx.xxx.xxx.xxxCode language: CSS (css)

où staging represente le sous-domaine et xxx.xxx.xxx.xxx représente l’adresse IPv4 du serveur.

Étape 2 : créer le server block sous NginX

Le domaine étant déjà actif, j’ai uniquement rajouté ce server block:

### STAGING ###
 server {
 listen              443 ssl http2;
 listen              [::]:443 ssl http2;
 server_name staging.kriyayoga.fr;
 root /home/www/kriyayoga/staging/public_html;
 set $root /home/www/kriyayoga/staging/public_html;
 index index.php index.htm index.html;
 error_log /var/log/nginx/kriyayoga_staging_error.log;
 #SSL
 ssl_certificate        /etc/nginx/ssl/kriyayoga.fr/fullchain.pem;
 ssl_certificate_key    /etc/nginx/ssl/kriyayoga.fr/privkey.pem;
 include snippets/mime-types.conf;
 #Exclusions
 include snippets/exclusions.conf;
 #Security
 include snippets/security.conf;
 #Static Content
 include snippets/static-files.conf;
 #Fastcgi cache rules
 include snippets/fastcgi-cache.conf;
 include snippets/limits.conf;
 include snippets/nginx-cloudflare.conf;
 #Gzip
 include snippets/gzip.conf;
 location / {
 try_files $uri $uri/ /index.php?$args;
 }
 location ~ .php$ {
 try_files $uri =404;
 include snippets/fastcgi-params.conf;
 fastcgi_pass unix:/run/php/php7.4-fpm.sock;
 #Skip cache based on rules in snippets/fastcgi-cache.conf.
 fastcgi_cache_bypass $skip_cache;
 fastcgi_no_cache $skip_cache;
 #Define memory zone for caching. Should match key_zone in fastcgi_cache_path above.
 fastcgi_cache kriyayoga;
 #Define caching time.
 fastcgi_cache_valid 60m;
 #increase timeouts
 fastcgi_read_timeout 6000;
 fastcgi_connect_timeout 6000;
 fastcgi_send_timeout 6000;
 proxy_read_timeout 6000;
 proxy_connect_timeout 6000;
 proxy_send_timeout 6000;
 send_timeout 6000;
 #these lines should be the ones to allow Cloudflare Flexible SSL 
 #to be used so the server does not need to decrypt SSL if you wish
 proxy_set_header X-Forwarded-Host $host;
 proxy_set_header X-Forwarded-Server $host;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto https;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-NginX-Proxy true;
 }
 #Protect WooCommerce upload folder from being accessed directly.
 #You may want to delete this config if you are using "Redirect Only" method for downloadable products.
 #Place this config towards the end of "server" block in NginX configuration.
 location ~* /wp-content/uploads/woocommerce_uploads/ {
   if ( $upstream_http_x_accel_redirect = "" ) {
     return 403;
     }
     internal;
 }
 }Code language: PHP (php)

Testez la nouvelle configuration:

nginx -t

Puis redémarrez NginX:

service nginx reload

Note: il est important de noter que je n’ai pas besoin de créer de certificat SSL puisque mes certificats sont wildcard par défaut. Si ce n’est pas le cas chez vous, pensez à en générer pour votre sous-domaine.

Étape 3 : copier les fichiers du site LIVE vers STAGING

Nous nous plaçons dans le répertoire de notre site. Les fichiers se trouvent sous /public_html et nous allons copier ce répertoire dans /staging, ce qui nous donnera au final:

/public_html => les fichiers du site LIVE
/staging/public_html => les fichiers du site STAGING Code language: JavaScript (javascript)

C’est parti:

cd /home/www/kriyayoga
cp -rf public_html/ staging/

Cela peut prendre quelques minutes.

Étape 4 : exporter la base de données LIVE

Rien de plus simple avec wp-cli, on se déplace dans LIVE:

cd /home/www/kriyayoga/public_html

Et on lance l’export de la base de données:

wp db export ../production-db.sql --allow-rootCode language: JavaScript (javascript)

Étape 5 : créer une base de données pour STAGING et importer la base de données LIVE

On va dans la console mysql:

mysql -u root -p

Et nous créons notre nouvelle base avec un nouvel utilisateur:

CREATE DATABASE staging_example;
CREATE USER 'example-USER'@'localhost' IDENTIFIED WITH mysql_native_password BY '4Ly(^7&xg%Vd4545h5thdsed12874H!è!ç?Vv9SWbL)'; 
GRANT ALL PRIVILEGES ON staging_example.* TO 'example-USER'@'localhost'; 
FLUSH PRIVILEGES; EXIT;Code language: PHP (php)

Nous importons ensuite notre base de données dans STAGING:

cd /home/www/kriyayoga/staging/public_html

wp db import ../../production-db.sql --allow-rootCode language: JavaScript (javascript)

Étape 6 : modifier le wp-config.php de STAGING

Je préfère déplacer le fichier wp-config.php d’un niveau dans l’arborescence, pour plus de sécurité:

mv wp-config.php ../

On l’édite ensuite avec les identifiants de notre nouvelle base de données:

nano ../wp-config.php

Étape 7 : assigner les bons droits pour STAGING

Si vous passez cette étape, les fichiers ne pourront être lus et servis par NginX, ce qui vous exposera à une magnifique erreur 403.

Il faut donc faire un chown et chmod sur nos fichiers et répertoires:

cd /home/www/kriyayoga/staging

chown -R www-data:www-data ./public_html
find ./public_html  -type d -exec chmod 755 {} +
find ./public_html -type f -exec chmod 644 {} +

Étape 8 : faire pointer les liens vers STAGING

On teste d’abord pour voir combien de liens vont être modifiés, avec la directive --dry-run :

wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid --dry-run --allow-rootCode language: JavaScript (javascript)

Si tout est bon, on lance la commande pour de bon:

wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid --allow-rootCode language: JavaScript (javascript)

Et voilà, vous venez de créer une copie de votre site original – à vous les tests sur votre version de développement.

Si vous souhaitez mon aide pour mettre votre site de développement en place, contactez-moi.

Articles conseillés :

• WordPress Rocket Stack : envoyez WordPress sur orbite !
• Lister tous les articles publiés sur un blog WordPress avec wp-cli
• WordPress : résoudre le problème de la table wp_options à qui manquent une colonne Unique et une Primary Key
• Mettre à jour la base de données de WooCommerce avec wp-cli
• Mise à jour du serveur vers Ubuntu 24.04 LTS
• Plausible Analytics au lieu de Google Analytics