FAQ : dépannage

Cet article aborde les questions de dépannage les plus courantes et leurs solutions.

Lisez également l’article sur les erreurs courantes rencontrées avec WordPress comme :

Désactiver les extensions sans accès au tableau de bord Désactiver les extensions sans accès au tableau de bord

Il peut vous arriver de vouloir désactiver toutes les extensions sans avoir accès au tableau de bord, par exemple car une extension incompatible bloque l’accès au site.

Si vous avez un accès au serveur ou à la base de données, utilisez l’une des techniques suivantes.

Via le serveur

Cette méthode préserve les réglages des extensions mais nécessite de les réactiver manuellement.

Pour désactiver les extensions directement via le serveur, connectez-vous à ce dernier en utilisant un client FTP ou en utilisant le gestionnaire de fichiers de votre hébergeur. Suivez ensuite ces étapes :

  1. Allez dans le dossier wp-content.
  2. Renommez le dossier « plugins » par « plugins_old ».
  3. Connectez-vous à nouveau au tableau de bord et allez dans l’écran des extensions (wp-admin/plugins.php) pour désactiver les extensions manquantes.
  4. Sur le serveur, renommez le dossier « plugins_old » par « plugins ».

Via la base de données

Si vous n’avez pas accès au serveur, vous pouvez désactiver les extensions en éditant la base de données.

Utilisez phpMyAdmin ou l’outil d’administration fourni par votre hébergeur pour visualiser et modifier votre base de données :

  1. Dans la table wp_options, cherchez la ligne ayant pour nom (option_name) « active_plugins ».
  2. Modifiez la valeur de option_value par : a:0:{}.

Haut ↑

Les mises à jour ne sont pas proposées Les mises à jour ne sont pas proposées

Quand une mise à jour ou une nouvelle version de WordPress est publiée, une notification est affichée en haut des écrans d’administration : « WordPress x.x.x est disponible ! Veuillez mettre à jour maintenant. ».

Tous les sites du monde qui utilisent WordPress ne verront pas ce message en même temps : chaque site est programmé pour vérifier les mises à jour disponibles toutes les 12 heures, mais la programmation de ces vérifications est aléatoire. Si votre site a vérifié les mises à jour quelques minutes avant qu’une nouvelle version soit publiée, vous ne verrez peut-être pas ce message avant 12 heures.

Vous pouvez vérifier quand la dernière vérification de mise à jour a eu lieu dans le menu Tableau de bord > Mises à jour. En dessous du numéro de version utilisée et de la date de dernière vérification, vous pouvez cliquer sur le lien Vérifier à nouveau pour lancer une actualisation.

Vous pouvez aussi forcer la vérification en supprimant l’option update_core de la table wp_options de votre base de données. Veuillez noter que les extensions et les thèmes ont leur propre cycle de vérification des mises à jour, contrôlés par les options update_plugins et update_themes de la table wp_options.

Haut ↑

Perte des personnalisations du thème par défaut lors d’une mise à jour Perte des personnalisations du thème par défaut lors d’une mise à jour

Si vous avez personnalisé (modifié) un fichier du cœur de WordPress, y compris d’un thème par défaut (par exemple : wp-content/themes/twentytwentyone/style.css), il y a un risque qu’il ait été remplacé lors d’une mise à jour.

En effet lors d’une mise à jour de WordPress, les anciens fichiers sont supprimés et remplacés si besoin. Cela concerne tous les fichiers situés dans wp-admin, wp-includes, mais aussi tous les thèmes par défaut.
Les anciens fichiers sont listés dans wp-admin/includes/update-core.php.

En revanche, un fichier complètement personnalisé ne sera pas impacté par une mise à jour du cœur de WordPress
(par exemple : wp-content/plugins/mon-plugin/mon-plugin.php).

Si vous avez perdu des modifications dans votre thème et que vous aviez une sauvegarde de votre site, vous pouvez restaurer les fichiers.

Pour éviter que cela ne se reproduise, vous devriez utiliser un thème enfant (en anglais).

Haut ↑

Réparer une table MySQL Réparer une table MySQL

Il peut arriver d’avoir besoin de réparer une table MySQL de votre base de données.

Les raisons peuvent être variées, les erreurs rencontrées également, telles que :  « tbl_name.frm is locked against change », « Can’t find file tbl_name.MYI (Errcode: nnn) », « Unexpected end of file », « Record file is crashed », ou « Got error nnn from table handler ».

Avant toute manipulation sur la base de données, faites une sauvegarde de cette dernière.

Voici les étapes à suivre pour réparer une table en utilisant phpMyAdmin :

  1. Accédez à phpMyAdmin.
  2. Sélectionnez la base de données concernée, si vous n’en avez qu’une seule, elle sera sélectionnée par défaut ;
  3. Dans le panneau principal, vous devriez voir une liste des tables de la base de données : cochez la ou les tables qui ont besoin d’être réparées.
  4. En bas de l’écran, sous la liste des tables, utilisez le menu déroulant pour choisir Réparer la table ou Repair table.

Vider une table de la base de données

Lisez l’article Vider une table de la base de données.

Haut ↑

Les e-mails ne sont pas reçus Les e-mails ne sont pas reçus

Lorsque vous vous enregistrez sur un site ou réinitialisez votre mot de passe, WordPress indique qu’un e-mail vous a été envoyé mais vous ne le recevez pas.

Tout d’abord, assurez-vous que l’e-mail ne se trouve pas dans votre dossier des indésirables ou spams.

Comment fonctionne l’envoi d’e-mails dans WordPress ? Comment fonctionne l’envoi d’e-mails dans WordPress ?

WordPress, qui fonctionne avec PHP, utilise la fonction standard mail(), qui elle même utilise le serveur de messagerie sendmail.
Aucune information de compte est nécessaire, et en général ce n’est pas un problème si vous utilisez un hébergement mutualisé ou infogéré, le prestataire aura configuré le serveur en conséquence.

Si vous utilisez votre propre serveur, vous devrez installer un serveur SMTP et le configurer, autrement les e-mails ne seront jamais envoyés.

Haut ↑

Serveurs *NIX (Unix ou Linux) Serveurs *NIX (Unix ou Linux)

Sur les serveurs Unix ou Linux, vous devez avoir un serveur mail installé et configuré (postfix ou sendmail). Faites une recherche sur votre moteur de recherche pour trouver des tutoriels à ce sujet.

Si vous ne souhaitez pas configurer un serveur mail, vous pouvez utiliser le paquet msmtp, qui vous fournira un client SMTP.

Haut ↑

Serveurs Windows Serveurs Windows

Sur un serveur Windows, vous pouvez utiliser un simulateur de sendmail, comme Glob SendMail (en anglais).

Haut ↑

Problèmes courants et leurs solutions Problèmes courants et leurs solutions

Relai du serveur sur Windows Relai du serveur sur Windows

Sur les serveurs Windows, vérifiez le réglage Relai du serveur SMTP virtuel : donnez les accès à l’adresse 127.0.0.1, puis dans le fichier php.ini, définissez le réglage SMTP sur la même adresse IP. Définissez également le réglage smtp_port sur 25.

Haut ↑

Informations d’expéditeur Informations d’expéditeur

Assurez-vous que les informations d’expéditeur/réponse sont correctes : par défaut, WordPress utilisera l’adresse wordpress@votredomaine.com et WordPress comme nom.

L’adresse e-mail utilisée doit être valide. Vous pouvez utiliser votre véritable adresse e-mail, ou une adresse spécifique à votre site.

Même si l’adresse wordpress@votredomaine.com n’existe pas, le serveur mail délivrera normalement les e-mails pourvu que le nom de domaine (votredomaine.com) soit configuré pour fonctionner sur ce serveur, au moins pour les e-mails.

En revanche, si vous utilisez une adresse qui comporte un nom de domaine qui n’est pas géré par le même serveur que WordPress ou configuré pour, il se peut que les e-mails ne soient pas envoyés (par exemple : exemple@gmail.com).

Haut ↑

Indésirables/spams Indésirables/spams

Il est possible que les e-mails envoyés par WordPress soient traités comme des indésirables. Ils seront alors placés dans un dossier indésirables/spams de votre boîte mail, ou pire, supprimés car considérés comme malveillants.

Il y a plusieurs choses à faire pour améliorer les chances que vos e-mails soit considérés comme acceptables et délivrés. Voici les deux principaux protocoles utilisés pour lutter contre les indésirables. Nous n’aborderons pas en détail ces points, internet vous fournira de nombreux tutoriels à ce sujet.

  • SPF : (Sender Policy Framework) c’est la mesure la plus couramment utilisée pour lutter contre les indésirables.
    Si votre site est sur un hébergement mutualisé ou infogéré, il y a de fortes chances que l’hébergeur l’ait configuré pour le serveur de messagerie que vous utilisez.
    Pour vérifier que le SPF est bien en place et configuré correctement, faites en sorte de recevoir un e-mail de votre site (en demandant un changement de mot de passe par exemple). Vérifiez ensuite les en-têtes de cet e-mail.
    Si le SPF ne semble pas correct, vous pouvez modifier sa configuration dans les enregistrements DNS du nom de domaine utilisé par l’adresse e-mail. Vérifiez également les informations de l’expéditeur.
  • DKIM (Domain Key Identified Mail) : ce système est également utilisé pour lutter contre les indésirables.
    Il est possible d’utiliser SPF et DKIM dans un même e-mail. Là encore, tout comme avec SPF, vous pouvez vérifier si votre serveur de messagerie a vérifié la clé de domaine de votre serveur en vérifiant l’en-tête de l’e-mail.
    Il est probable qu’aucune clé de signature n’ait été fournie, ce qui indique que le serveur de messagerie a choisi de ne pas utiliser ce protocole. Comme avec SPF, si vous pouvez modifier vos enregistrements DNS et que le serveur de messagerie appartient à votre nom de domaine, vous pouvez configurer vous-même les identifiants DKIM.

Haut ↑

Les articles ne s’affichent pas Les articles ne s’affichent pas

Si les articles ne s’affichent pas sur votre blog et que vous avez le message « Désolé, aucun article ne correspond à vos critères », essayez de vider votre cache et vos cookies.

Haut ↑

Corriger l’erreur Cannot modify header information – headers already sent Corriger l’erreur Cannot modify header information – headers already sent

Warning: Cannot modify header information - headers already sent

Cette erreur est en général provoquée par un espace ou un caractère situé avant ou après l’ouverture des balises PHP (<?php ?>) dans un fichier. L’erreur devrait vous indiquer le fichier concerné.

Interpréter le message d’erreur

Si le message indique :

Warning: Cannot modify header information - headers already sent by (output started at /path/blog/wp-config.php:34) in /path/blog/wp-login.php on line 42

Alors l’erreur est située à la ligne 34 du fichier wp-config.php, et elle a uniquement été provoquée à la ligne 42 du fichier wp-login.php. Vous devriez donc chercher un espace ou un caractère invalide dans le fichier wp-config.php, à la ligne 34.

Si vous ne trouvez pas l’erreur, commencez par vérifier le fichier wp-config.php : ouvrez ce fichier en vous connectant via FTP et vérifiez qu’il n’y a aucun espace ou caractère avant ou après les balises d’ouverture et de fermeture PHP.

Si vous ne parvenez pas à résoudre le problème, remplacez les fichiers du cœur de WordPress par ceux d’une sauvegarde ou téléchargés sur wordpress.org.

Si l’erreur est toujours présente, cela peut être dû à un problème d’encodage :

  1. Téléchargez le fichier mentionné par l’erreur en FTP.
  2. Ouvrez ce fichier dans un éditeur de texte (et pas un traitement de texte).
  3. Vérifiez que le tout premier caractère n’est pas suivi d’un espace ou d’une nouvelle ligne.
  4. Avant d’enregistrer le fichier, ou en utilisant le menu Enregistrer sous, assurez-vous que l’encodage est UTF-8 et non UTF-8 BOM.
  5. Téléversez le fichier sur le serveur.

Bonnes pratiques pour écrire du PHP

Évitez de séparer inutilement des blocs de code.

Mauvais exemple :

<?php some code; ?> <?php some other code; ?>

Qui devrait être remplacé par :

<?php some code; some other code; ?>

Haut ↑

Les boutons Publier et Enregistrer le brouillon ne fonctionnent pas Les boutons Publier et Enregistrer le brouillon ne fonctionnent pas

En général, cela est dû à une incompatibilité d’extension. Essayez de les désactiver une par une pour trouver celle qui est en cause.

Cela peut également être un problème avec votre navigateur. Vous pouvez essayer de vider le cache et les cookies, ou de diagnostiquer les erreurs.

Haut ↑

Erreur 404 avec les permaliens optimisés Erreur 404 avec les permaliens optimisés

Si vous rencontrez une erreur 404 alors que vous utilisez les permaliens optimisés, vérifiez que votre configuration serveur est correcte, notamment pour le mode_rewrite de Apache.

Haut ↑

Un compte administrateur/administratrice n’est pas listé comme auteur/autrice Un compte administrateur/administratrice n’est pas listé comme auteur/autrice

Si vous remarquez que le compte d’un administrateur ou d’une administratrice n’est pas listé comme auteur ou autrice, essayez la manipulation suivante :

  1. Créez un nouveau compte administrateur/administratrice (par exemple : admintest).
  2. Connectez-vous avec ce nouveau compte admintest.
  3. Passez le rôle du compte concerné par le problème de administrateur/administratrice à abonné⋅e.
  4. Connectez-vous à nouveau sur votre compte admin principal.

Si cela ne fonctionne pas :

  1. Créez un nouveau compte administrateur/administratrice (par exemple : newadmin).
  2. Connectez-vous à ce nouveau compte.
  3. Supprimez l’ancien compte et assignez ses contenus au nouveau compte newadmin.
  4. Créez à nouveau un compte admin.
  5. Connectez-vous à ce nouveau compte.
  6. Supprimez le compte newadmin créé à l’étape 1 et assignez ses contenus au compte créé à l’étape 4.

Haut ↑

Le nom de l’auteur/autrice affiché sur le blog est incorrect Le nom de l’auteur/autrice affiché sur le blog est incorrect

Ce problème est en général résolu de la même façon que pour « Un compte administrateur n’est pas listé comme auteur/autrice ».

Ressources utiles

Traduit par Marie Comet
Relu par Jb Audras & Bruno Tritsch
Dernière mise à jour le 19 février 2021

Contribuer à la documentation en français de WordPress