Voici une sélection d’astuces pratiques pour WordPress, revues et mises à jour pour les versions récentes (WordPress 6.x). Sauf indication contraire, le code PHP se place dans le fichier functions.php de votre thème — idéalement un thème enfant, afin de ne pas perdre vos modifications à chaque mise à jour du thème.
Cacher la barre d’administration
La barre d’administration de WordPress s’affiche en haut du site lorsqu’on est connecté. Si elle ne vous sert pas, masquez-la proprement avec le filtre dédié :
add_filter('show_admin_bar', '__return_false');
Astuce : chaque utilisateur peut aussi la désactiver pour lui-même depuis Utilisateurs → Profil.
Alléger l’en-tête HTML généré par WordPress
Par défaut, WordPress ajoute dans l’en-tête de vos pages plusieurs balises souvent inutiles (numéro de version, liens oEmbed, lien de l’API REST, scripts d’emojis…). On peut les retirer pour un en-tête plus léger :
add_action('init', function () {
// Numéro de version de WordPress
remove_action('wp_head', 'wp_generator');
// Lien "shortlink"
remove_action('wp_head', 'wp_shortlink_wp_head');
// Liens de découverte oEmbed
remove_action('wp_head', 'wp_oembed_add_discovery_links');
// Lien vers l'API REST (balise rel api.w.org)
remove_action('wp_head', 'rest_output_link_wp_head');
// Scripts et styles des emojis
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
});
À noter : les anciennes lignes pour retirer rsd_link (RSD) et wlwmanifest_link (Windows Live Writer) ne sont plus nécessaires — ces balises ont été supprimées du cœur de WordPress à partir de la version 6.7 (octobre 2024).
Pour supprimer les liens de flux RSS automatiques, l’ancienne fonction automatic_feed_links(false) est dépréciée depuis WordPress 3.0. On utilise désormais :
add_action('after_setup_theme', function () {
remove_theme_support('automatic-feed-links');
});
Astuces pour le fichier wp-config.php
Maîtriser les révisions d’articles
Plutôt que de désactiver complètement l’historique, il est souvent préférable d’en limiter le nombre :
// Conserver au maximum 5 révisions par article
define('WP_POST_REVISIONS', 5);
// ... ou tout désactiver : define('WP_POST_REVISIONS', false);
Régler l’autosauvegarde et la corbeille
// Intervalle d'enregistrement automatique, en secondes
define('AUTOSAVE_INTERVAL', 300);
// Vider automatiquement la corbeille au bout de 7 jours
define('EMPTY_TRASH_DAYS', 7);
Activer l’outil de réparation de la base
Une fois activé, il est accessible à l’adresse /wp-admin/maint/repair.php (pensez à le redésactiver ensuite) :
define('WP_ALLOW_REPAIR', true);
Forcer l’URL du site
Pratique pour réparer une mauvaise URL saisie dans Réglages → Général (utilisez bien https) :
define('WP_HOME', 'https://www.mon-site.fr');
define('WP_SITEURL', 'https://www.mon-site.fr');
Mises à jour sans identifiants FTP
Si WordPress réclame des identifiants FTP à chaque mise à jour, forcez la méthode directe :
define('FS_METHOD', 'direct');
Durcir la sécurité
Quelques constantes de durcissement : désactiver l’éditeur de fichiers de thèmes/extensions intégré à l’admin (souvent exploité après un piratage), forcer le HTTPS sur l’administration et la page de connexion, et activer les mises à jour automatiques mineures (correctifs de sécurité) :
/* Durcissement WordPress */
define('DISALLOW_FILE_EDIT', true);
define('FORCE_SSL_ADMIN', true);
define('WP_AUTO_UPDATE_CORE', 'minor');
Note : derrière un reverse proxy en SSL offload, FORCE_SSL_ADMIN suppose que WordPress détecte bien le HTTPS (voir la section X-Forwarded-Proto plus bas), sinon vous risquez une boucle de redirection sur l’admin.
Migrer le site vers un nouveau domaine
L’ancienne méthode par requêtes SQL UPDATE … REPLACE est aujourd’hui déconseillée : elle casse les données sérialisées (réglages de thème, widgets, options d’extensions), car la longueur des chaînes n’est pas recalculée. La bonne méthode passe par WP-CLI, qui gère correctement la sérialisation :
# Toujours sauvegarder la base AVANT toute opération wp db export sauvegarde-avant-migration.sql # Simulation (dry-run) pour verifier l'ampleur des remplacements wp search-replace 'https://ancien-domaine.fr' 'https://nouveau-domaine.fr' --all-tables --dry-run # Si le rapport est correct, on relance pour de vrai wp search-replace 'https://ancien-domaine.fr' 'https://nouveau-domaine.fr' --all-tables # Purger le cache d'objets si present (Redis/Memcached) wp cache flush
Sans accès à WP-CLI, l’extension Better Search Replace fait la même chose en toute sécurité depuis l’admin.
Désactiver XML-RPC
Le fichier xmlrpc.php (qui gérait notamment les pingbacks et l’ancien Windows Live Writer) est aujourd’hui une cible fréquente d’attaques par force brute. Si vous ne l’utilisez pas, désactivez-le :
add_filter('xmlrpc_enabled', '__return_false');
WordPress derrière un reverse proxy : SSL offload et X-Forwarded-Proto
Lorsqu’un reverse proxy ou un load-balancer (HAProxy, Nginx, Traefik…) assure le SSL offload — il termine le HTTPS et transmet la requête en HTTP clair au serveur WordPress — WordPress ne « voit » que du trafic HTTP. Conséquences classiques : URLs générées en http://, contenus mixtes (mixed content) bloqués par le navigateur, et parfois des boucles de redirection dans l’administration.
La parade : le reverse proxy transmet le protocole d’origine via l’en-tête X-Forwarded-Proto, et on indique à WordPress de le prendre en compte. À placer en haut de wp-config.php, avant la ligne require_once ABSPATH . ‘wp-settings.php’ :
// Tenir compte du protocole réel transmis par le reverse proxy (SSL offload)
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Encore faut-il que le reverse proxy envoie bien cet en-tête. Exemples côté proxy :
# Nginx (dans le bloc qui transmet vers le backend WordPress) proxy_set_header X-Forwarded-Proto $scheme; # HAProxy (frontend HTTPS, avant de router vers le backend en clair) http-request set-header X-Forwarded-Proto https