Tag: terminal

Auditer les problèmes de performance WordPress avec wp profile

21 mai 2025 by Matt Biscay · Lecture: 7 minutes

La commande wp profile est un peu comme une alternative à New Relic, capable d’identifier précisément quels composants ralentissent votre site WordPress. Initialement disponible en tant que package premium via runcommand, il est désormais gratuit sur GitHub.

Si vous cherchez un hébergeur compatible avec l’installation de wp profile, jetez un œil à Kinsta et FastNyx.

J’utilise régulièrement wp profile pour diagnostiquer les problèmes de performance chez mes clients sur Codeable. Tous les développeurs WordPress devraient s’en servir ! Après avoir suivi ce guide, vous serez plus proche de la résolution de la lenteur de votre site WordPress.

Installation du package wp-profile

Lancez cette commande pour installer wp profile :

wp package install wp-cli/profile-command

Vous devriez voir que le processus s’est déroulé avec succès et que la commande wp profile est maintenant disponible:

Updating /root/.wp-cli/packages/composer.json to require the package...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
Resolving dependencies through SAT
Dependency resolution completed in 0.120 seconds
Analyzed 3696 packages to resolve dependencies
Analyzed 101022 rules to resolve dependencies
Package operations: 1 install, 0 updates, 0 removals
Installs: wp-cli/profile-command:dev-master ef44df5
- Installing wp-cli/profile-command (dev-master ef44df5)
Writing lock file
Generating autoload files
---
Success: Package installed.Code language: JavaScript (javascript)

Si vous voyez une erreur concernant composer.json reverté, l’augmentation de la mémoire devrait résoudre ce problème.

Une fenêtre de terminal stylisée affiche la commande « ./WP-CLI » en grand texte blanc. À côté, une flèche bleue pointant vers le bas pointe vers une barre horizontale verte, suggérant un téléchargement ou une installation via SSH. L'arrière-plan est gris foncé.

Installer WP-CLI sans accès root ni sudo via SSH sur n’importe quel hébergeur

8 July 202519 mai 2025 by Matt Biscay · Lecture: 3 minutes

Chaque fois qu’un hébergeur n’a pas WP-CLI installé par défaut, je suis déçu : ce puissant outil de gestion WordPress n’est pas disponible ! Heureusement, il est facile d’installer WP-CLI sans accès root ni sudo via SSH.

En suivant cette méthode, vous pourrez utiliser WP-CLI exactement comme s’il avait été installé de manière traditionnelle avec les droits root et placé dans /usr/bin ou /usr/local/bin.

Cet article vous montrera comment installer WP-CLI sur presque toutes les distributions Linux comme CentOS, Debian, Ubuntu, etc., tant que le paquet php-cli est disponible. Tout ce dont vous avez besoin, c’est d’un accès SSH et d’un moyen d’entrer ces commandes, comme le terminal Mac ou PuTTY sous Windows.

Installer WP-CLI sans accès root ni sudo

Nous avons besoin d’un emplacement pour stocker le fichier phar de WP-CLI, créons donc un dossier et entrons dedans :

mkdir -p /tmp/wp-cli
cd /tmp/wp-cli

Téléchargez la dernière version de WP-CLI phar et rendez-la exécutable :

wget -q https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -O wp
chmod 755 wpCode language: JavaScript (javascript)

Ou bien, téléchargez directement le fichier phar WP-CLI dans votre dossier temporaire :

mkdir -p /tmp/wp-cli
wget -q https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -O /tmp/wp-cli/wp
chmod 755 /tmp/wpCode language: JavaScript (javascript)

Ou dans n’importe quel dossier de votre choix :

cd /votre_dossier<br />wget -q https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -O /votre_dossier/wp
chmod 755 /votre_dossier/wpCode language: HTML, XML (xml)

Pour utiliser le WP-CLI que nous venons de télécharger, il faudra ajouter ./ devant wp. Il vous faudra également le chemin d’installation de WordPress.

wp-cli : importer et exporter les utilisateurs WP

20 December 202314 juin 2022 by Matt Biscay · Lecture: 3 minutes

Voici une méthode simple pour exporter tous les utilisateurs d’une base de données WordPress, pour les réimporter sur un autre site, à l’aide de l’excellent wp-cli.

Nous ferons référence à la base de données source en tant que source-db et à la base de données cible en tant que target-db et je supposerai que vous avez accès aux deux instances WordPress via wp-cli.

Étape 1 : exporter les utilisateurs WordPress

Cette étape fonctionnera avec la base de données source-db:

wp db export --tables = $(wp db tables 'wp_*_users') users.sqlCode language: JavaScript (javascript)

notez l’astérisque dans le nom de la table – utilisez-le pour éviter de taper le nom exact de la table pour votre base de données WordPress spécifique
notez le nom du fichier exporté, users.sql – cela permet d’identifier clairement le contenu de ce fichier.

Étape 2 : exporter la méta utilisateur WordPress

Cette étape fonctionnera avec la base source-db. Comme ci-dessus, notez le caractère générique et le nom de fichier:

wp db export --tables = $(wp db tables 'wp_*_usermeta') usermeta.sqlCode language: JavaScript (javascript)

Étape 3 : sauvegarde facultative des utilisateurs et usermeta

Cette étape fonctionnera avec la base target-db. Il s’agit d’une sauvegarde facultative des utilisateurs et des tables usermeta avant d’importer les nouvelles données:

répétez l’étape 1 (mais en travaillant avec target-db)
nommez le fichier backup-users.sql
répétez l’étape 2 (mais en travaillant avec target-db)
nommez le fichier backup-usermeta.sql

Cela nous donne donc:

wp db export --tables = $(wp db tables 'wp_*_users') backup-users.sql
wp db export --tables = $(wp db tables 'wp_*_usermeta') backup-usermeta.sqlCode language: JavaScript (javascript)

Local : importer une base de données depuis le shell

11 March 202204 janvier 2021 by Matt Biscay · Lecture: 2 minutes

Local possède une version d’Adminer dans les options de chaque site qui est très utile puisqu’elle permet d’accéder rapidement à la base de données, ou d’importer une petite base de données.

Par contre, s’il s’agit d’importer une base qui fait plus de 80 Mo, mieux vaut se tourner vers un outil un peu plus robuste: le shell.

Accéder au shell depuis Local

Et cela tombe bien : Local possède son propre shell, accessible sur simple clic-droit sur le nom du site sur lequel vous souhaitez ouvrir une fenêtre de terminal:

Voici la marche à suivre : Démarrez votre site > sélectionnez le nom du site > clic-droit > Open Site Shell

Importer une base de données dans un site Local

Lorsque j’ai besoin de répliquer un site rapidement, je copie la base données dans le répertoire app du site Local en question.

Pour mon site de test (skyminds-2020 ), le chemin sur ma machine est /Users/matt/Local Sites/skyminds2020/app . C’est dans ce dossier que je place le fichier SQL à importer.

Ensuite, dans le shell Local, il suffit de faire un simple import SQL dans la base qui, par défaut, s’appelle local (et ce, pour tous vos sites Local, bien qu’elles soient toutes indépendantes).

L’utilisateur est root et le mot de passe root également, ce qui est plutôt pratique.

Le shell est par défaut sous app/public donc on remonte d’un cran dans l’arborescence pour pointer vers notre fichier (qui se trouve dans /app ).

Voilà ce que cela nous donne:

mysql -u root -proot local < ../db.sql

Résultat:

mysql: [Warning] Using a password on the command line interface can be insecure.
bash-3.2$Code language: HTTP (http)

L’importation de la base de données SQL ne prend que quelques secondes, alors que cela se plante allégrement lorsque l’on utilise Adminer.

A utiliser sans modération, cela ne vaut vraiment pas le coup de s’embêter avec une interface graphique (ou à placer le fichier dans le répertoire d’adminer comme il l’indique sur la page d’importation).

Redémarrer la machine virtuelle de Local by Flywheel photo

Local : résoudre les problèmes d’importation de la base de données

27 September 202414 mai 2020 by Matt Biscay · Lecture: 3 minutes

Aujourd’hui, on importe la base de données d’un site existant dans la nouvelle version de Local Lightning, estampillée 5.4.1.

D’habitude, je lance Adminer > Import, je sélectionne mon fichier de base de données et boom, la base est importée. Mais aujourd’hui, rien ne se passe comme prévu: Adminer mouline, mouline, perd la moitié du design de sa page et n’importe pas la base.

SSH à la rescousse

Je me dis qu’on aura peut-être plus de chance depuis la console SSH. Dans Local, faites un clic droit sur le site > Open Site Shell. Une fenêtre de terminal apparaît alors.

Utilisation de WP-CLI

On commence d’abord par la méthode wp-cli. On copie notre fichier adminer.sql sous /app/public et on lance la commande suivante:

wp db import ./adminer.sqlCode language: JavaScript (javascript)

Résultat:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)Code language: JavaScript (javascript)

Cela commence bien. La version 5 de Local utilise MySQL 8 donc certaines choses ne sont peut-être pas tout à fait au point. Comme il n’y a pas de socket mysql dans /tmp/mysql.sock, nous allons manuellement spécifier notre socket MySQL dans notre commande. Local nous donne l’adresse du socket dans l’onglet Database:

wp db import ./adminer.sql --socket="/Users/matt/Library/Application Support/Local/run/rvrb6Ce-Z/mysql/mysqld.sock"

Résultat:
ERROR 1067 (42000) at line 23841 in file: './adminer.sql': Invalid default value for 'comment_date'
Code language: JavaScript (javascript)

La bonne nouvelle, c’est que l’on peut se connecter à la base de données MySQL. Mais tiens donc, nous sommes déjà tombés sur cette erreur Invalid default value for comment_date !

Configuration de MySQL

Pour régler le problème sous Local, la marche à suivre diffère un peu de ce que nous avions lancé sur notre serveur puisqu’il n’y a pas une mais deux variables de configuration de mysqld à modifier.

On se connecte au serveur mysql:

mysql -u root -proot

Commençons par voir ce que les variables sql_mode contiennent:

SELECT @@GLOBAL.sql_mode; SELECT @@SESSION.sql_mode; Code language: CSS (css)

Résultat:

+------------------------------------------------------------------------------------------+
| @@GLOBAL.sql_mode                                                                        |
+------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+------------------------------------------------------------------------------------------+
1 row in set (0,00 sec)

+------------------------------------------------------------------------------------------+
| @@SESSION.sql_mode                                                                       |
+------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+------------------------------------------------------------------------------------------+Code language: JavaScript (javascript)

Le problème est, comme la dernière fois, la présence de ces deux instructions: NO_ZERO_IN_DATE,NO_ZERO_DATE.

On enlève donc ces deux instructions de nos deux directives:

SET @@GLOBAL.sql_mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION";
SET @@SESSION.sql_mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION";Code language: CSS (css)

Voilà ce que nous obtenons au final:

+------------------------------------------------------------------------------------------+
| @@GLOBAL.sql_mode                                                                        |
+------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+------------------------------------------------------------------------------------------+
1 row in set (0,00 sec)

+------------------------------------------------------------------------------------------+
| @@SESSION.sql_mode                                                                       |
+------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+------------------------------------------------------------------------------------------+
1 row in set (0,00 sec)Code language: JavaScript (javascript)

On peut désormais importer notre fichier SQL:

mysql -u root -proot local < ./adminer.sql

Hop l’import de la base de données se passe maintenant sans aucun problème.

Linux et MacOS : lister tous les répertoires de plus de 500 Mo

11 March 202211 février 2020 by Matt Biscay · Lecture: 1 minute

De temps en temps, il faut un peu faire le ménage sur nos disques durs et il est assez utile de chercher à savoir quels sont les dossiers qui prennent le plus d’espace disque.

Lister tous les répertoires de plus de 500 Mo

Sous Linux et MacOS, voici la commande que je lance pour trouver tous les répertoires de plus de 500 Mo, classés par ordre d’importance:

du -m ~/Downloads/* | awk '$1 > 500' | sort -nrCode language: JavaScript (javascript)

Voici le détail de la commande:

du signifie disk usage
-m signifie que l’on souhaite la taille en Mo
~/Downloads/* est le chemin dans lequel se trouvent nos gros dossiers, là où se trouvent nos données
awk '$1 > 500' capture le chemin du dossier lorsqu’il dépasse 500 Mo
sort -nr permet de classer la liste du plus gros dossier au plus petit

Une petite commande à garder sous le coude, cela permet d’éviter de perdre trop de temps à trouver le dossier le plus gourmand du disque!

Réinitialiser le mot de passe root de MySQL ou MariaDB sous Debian

30 September 202128 décembre 2019 by Matt Biscay · Lecture: 2 minutes

Chez l’un de mes clients, nous avons eu besoin de réinitialiser le mot de passe MySQL de l’utilisateur root, qui a été oublié.

Je vous avais déjà décrit comment réinitialiser le mot de passe root d’un serveur MySQL ou MariaDB sous Ubuntu.

Comme le serveur tourne sous Debian, nous avons un moyen très simple d’avoir accès à la base mysql pour modifier le mot de passe root. Cela ne prend que quelques secondes.

L’utilisateur debian-maintenance à la rescousse

Sous les systèmes à base Debian, il existe par défaut un utilisateur nommé debian-sys-maint, qui se charge de routines de maintenance sur la base SQL et qui possède tous les droits d’administration sur toutes les bases de données.

Il se trouve que le mot de passe de l’utilisateur debian-sys-maint est visible, en clair dans ce fichier:

nano /etc/mysql/debian.cnf

Copiez le mot de passe. Ensuite, connectez-vous avec debian-sys-maint au serveur de base de données:

mysql -u debian-sys-maint -p

Vous êtes maintenant connecté au serveur de base de données, en tant qu’administrateur, sous l’utilisateur debian-sys-maint.

Tous les utilisateurs de la base de données sont stockés dans la base mysqldonc on commence par la sélectionner:

use mysql;Code language: PHP (php)

Et on peut maintenant changer le mot de passe de l’utilisateur root avec une simple mise à jour du mot de passe:

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('^*p4!_BHLn6Q&xuft*^5tjyby7^_$)d7_fgf&zec8#ExV@xY');
flush privileges;Code language: JavaScript (javascript)

Il ne reste plus qu’à quitter MySQL monitor:

quit;

Voilà, le mot de passe de l’utilisateur rootest désormais changé. Vous pouvez vous identifier normalement avec le nouveau mot de passe que vous venez de définir plus haut:

mysql -u root -p
Enter password:

Une astuce toujours utile à garder sous le coude!

Changer le nom de fichier par défaut de l’outil capture d’écran sous MacOS X

3 October 202105 décembre 2019 by Matt Biscay · Lecture: 1 minute

Depuis que je suis passé à MacOS X Catalina, j’ai ajouté l’outil capture d’écran dans la Touchbar, histoire de toujours l’avoir à portée de main.

Pour les puristes, vous pouvez capturer l’écran avec Shift-Command-5 (à partir de Mojave et supérieur) ou Shift-Command-3.

Par contre, toutes les captures d’écran sont préfixées par défaut avec “Capture d’écran” suivie de la date et de l’heure. Cela peut être gênant lorsque l’on publie cette image sur internet, étant donné que les noms de fichiers accentués ne sont pas toujours bien gérés.

Voici donc une petite astuce pour changer le préfixe pour celui de votre choix. Dans mon exemple, je l’ai tout simplement changé pour “Screenshot”.

Changer le nom de fichier par défaut de l’outil capture d’écran

Ouvrez le terminal puis lancez la commande suivante, en remplaçant “Screenshot” par le préfixe de votre choix:

defaults write com.apple.screencapture name "Screenshot"Code language: CSS (css)

Relancez ensuite le service SystemUI:

killall SystemUIServer

Lancez ensuite l’outil de capture d’écran et enregistrez votre capture. Elle est maintenant préfixée par ce que vous avez choisi.

SSH : solution pour l’erreur “Permissions 0644 for ‘id_rsa.pub’ are too open”

15 March 202229 septembre 2019 by Matt Biscay · Lecture: 1 minute

Lors d’une connexion SSH sur le serveur d’un client chez WPEngine, je suis tombé sur le message d’erreur suivant:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/matt/.ssh/id_ed25519.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/matt/.ssh/id_ed25519.pub": bad permissionsCode language: PHP (php)

Voici la commande que j’avais entré:

ssh -i ~/.ssh/id_ed25519.pub -o IdentitiesOnly=yes EXAMPLE@wEXAMPLE.ssh.wpengine.netCode language: JavaScript (javascript)

Au lieu d’utiliser ma clé privée, j’ai utilisé ma clé publique (id_ed25519.pub) qui – comme elle est publique – bénéficie de droits plus large que la clé privée.

Il faut donc relancer la commande en retirant l’extension .pub du chemin de la clé, pour que la clé privée soit prise en compte:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes EXAMPLE@wEXAMPLE.ssh.wpengine.netCode language: JavaScript (javascript)

Dès lors, plus de problème de connexion et la connexion sur le serveur WPEngine se fait sans souci:

  ____  _____  _____
 ╱   ▕ ▕    ▕ ▕    ▕
▕    ▕ ▕    ▕ ▕    ▕
▕____▕  ╲___╱  ╲___▕                                      ▫
 ____           ____     ▃  ▃  ▃  ▃▃▃    ___   __    __      __   ___
▕    ▕    _    ╱   ▕     █  █  █ ▕█▀▀▙  ▕___) |  ▕  ╱  ▕ ▕  |  ▕ ▕___)
▕    ▕   ( )  ▕    ▕      ██ ██  ▕███▛  ▕     |  ▕ ▕   ▕ ▕  |  ▕ ▕
▕____╱    ‾    ╲___▕       █ █   ▕█      ╲__╱ |  ▕  ╲__▕ ▕  |  ▕  ╲__╱
 ____    ___   ___                                  ___╱
▕    ╲  ╱   ╲ ▕    ╲
▕    ▕ ▕    ▕ ▕    ▕
▕____╱ ▕____▕ ▕____▕

WP Engine Shell - PHP 7.3

Utiliser Git pour envoyer du code versionné sur Github

29 September 202422 août 2019 by Matt Biscay · Lecture: 2 minutes

Git – et son homologue Github – permet de versionner votre code afin de pouvoir commenter les changements de code, revenir en arrière et annuler une modification en cas de problème, tenir une feuille de route, accepter des demandes de modifications venant d’autres développeurs (pull requests) et permettre la collaboration de plusieurs personnes sur un même projet.

Voici un petit tuto pour vous donner les commandes essentielles qui permettent de créer le dépôt, ajouter du code et l’envoyer sur Github.

Installation de Git

Commençons par l’étape obligatoire qui est l’installation de Git sur votre système d’exploitation:

MacOSX : résoudre l’erreur xcrun: error: invalid active developer path

Sous MacOSX, lorsque vous lancez une commande git, vous pouvez obtenir le message d’erreur suivant:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrunCode language: JavaScript (javascript)

Cela signifie qu’il vous manque les outils de développement XCode. Cela peut arriver après chaque mise à jour d’OSX donc vous pouvez les installer avec:

sudo rm /Library/Developer/CommandLineTools -rf
sudo xcode-select --install

Créer un nouveau dépôt Git et l’associer à votre dépôt GitHub

Placez-vous dans le répertoire qui contient votre code. On crée un nouveau dépôt Git avec:

git init

Cela initialise votre répertoire avec les dossiers cachés de git. On ajoute maintenant l’adresse de notre dépôt sur GitHub:

git remote add origin https://github.com/example/example-projectCode language: JavaScript (javascript)

Nous allons maintenant pouvoir ajouter notre code.

Ajouter et valider votre code

Pour ajouter des fichiers, on utilise la directive add:

git add *
git add <filename>Code language: HTML, XML (xml)

Ensuite, on valide avec un message qui explique la validation des changements:

git commit -m "Ajout des fichiers du projet"Code language: JavaScript (javascript)

A ce stade, le fichier est dans le HEAD de git, mais pas encore dans votre dépôt distant. On l’envoie donc sur GitHub avec:

git push origin master

Pour mettre à jour votre dépôt local vers les dernières validations qui se trouvent sur GitHub (attention, cela écrase les fichiers locaux!), exécutez la commande:

git pull

Voilà, c’est un petit mémo simple mais il permet déjà de se servir des principales fonctions de git.

Résoudre l’erreur SSH: Missing privilege separation directory: /run/sshd

24 March 202212 août 2019 by Matt Biscay · Lecture: 2 minutes

Sur un nouveau serveur à base d’Ubuntu Server 18.04, j’obtiens cette erreur à la suite d’un test du service ssh:

sshd -t

Could not load host key: /etc/ssh/ssh_host_ed25519_key
Missing privilege separation directory: /run/sshdCode language: JavaScript (javascript)

Les solutions à ces deux problèmes sont triviales, cela se règle en deux petites commandes.

L’erreur Could not load host key

L’erreur Could not load host key survient lorsque certaines clés SSH n’ont pas été générées lors de l’installation du système d’exploitation du serveur.

Dans le cas du serveur qui nous occupe, il nous manque la clé de chiffrement ED25519 qui doit se trouver à l’adresse /etc/ssh/ssh_host_ed25519_key.

Pour générer toutes les clés de chiffrement SSH manquantes, une seule commande suffit:

ssh-keygen -A

L’argument -A signifie que l’on génère toutes les clés (All keys). Voici le résultat sur le serveur:

ssh-keygen: generating new host keys: ED25519Code language: JavaScript (javascript)

L’erreur Missing privilege separation directory: /run/sshd

Cette erreur apparaît lorsque le répertoire mentionné – ici /run/sshd – n’a pas été correctement créé. Il suffit de le créer:

mkdir -p /run/sshd

Vérifiez la configuration SSH:

sshd -t

S’il n’y a plus d’erreur, vous pouvez alors redémarrer le service ssh:

service ssh restart

Et voilà, problèmes réglés.

NginX: éviter le hotlinking

14 January 202416 juillet 2019 by Matt Biscay · Lecture: 2 minutes

Le hotlinking

Le hotlinking (ou liaison automatique ; aussi connu en anglais sous les noms de inline linking, leeching, piggy-backing, direct linking ou offsite image grabs) consiste à utiliser l’adresse d’un fichier publié sur un site web, le plus souvent une image, pour l’afficher sur un autre site, sur un blog, dans un forum, etc.

En d’autres termes, au lieu d’enregistrer l’image et de l’installer sur son propre serveur Web, le hotlinkeur crée un lien direct vers le serveur d’origine.

Si vous êtes sous Apache, voici comment supprimer le hotlinking sous Apache Server.

Désactiver le hotlinking sous NginX

Sous NginX, il peut être très utile d’éviter que des gens publient vos photos ou images depuis votre site sur le leur, en gardant les liens de votre serveur et en consommant toute votre bande passante (ce qui peut représenter un surcoût pour vous).

Il suffit d’éditer votre server block et d’y ajouter cette directive:

location ~ \.(gif|png|jpeg|jpg|svg|webp|avif)$ {
    # Define allowed referers - your own domain and specific external domains
    valid_referers none blocked 
                  ~\.google\. 
                  ~\.bing\. 
                  ~\.yahoo\. 
                  ~\.facebook\. 
                  ~\.pinterest\. 
                  ~\.twitter\. 
                  yourdomain.com 
                  *.yourdomain.com 
                  server_names;

    # Block requests with no or invalid referer
    if ($invalid_referer) {
        return 403;
    }
}
Code language: PHP (php)

N’hésitez pas à rajouter les domaines que vous souhaitez whitelister et qui sont autorisés à utiliser vos fichiers média.

Relancez ensuite NginX avec:

service nginx restart

Cela devrait quelque peu soulager votre serveur et garantir votre bande passante à vos visiteurs.