WordPress

Les journaux WordPress aident à comprendre un incident en conservant des messages techniques. Commencez par les traces déjà disponibles chez l’hébergeur, puis identifiez l’heure et l’action concernées. Le journal PHP, les accès web et debug.log n’ont pas le même rôle. Ce guide explique quoi lire, comment organiser un diagnostic ponctuel et quels extraits transmettre, sans publier de secrets ni afficher les erreurs aux visiteurs.

Une erreur 502 sur WordPress signifie qu’une passerelle ou un proxy a reçu une réponse invalide du serveur en amont. Le message ne démontre pas qu’un plugin est responsable. Repérez le service qui affiche l’erreur, l’adresse et l’heure, puis comparez les traces de chaque couche. Vous pourrez distinguer un incident d’hébergement, un traitement PHP et un problème d’intermédiaire, avant de choisir une correction et ses contrôles.

Une erreur 503 sur WordPress indique qu’un service ne peut momentanément pas traiter la demande. Une maintenance annoncée, une limite de ressources et un traitement défaillant n’appellent pas la même correction. Relevez l’heure, les pages touchées et le message avant de modifier des composants. Ce guide aide à choisir le bon contrôle, transmettre les traces utiles et vérifier le retour du site, sans désactiver toutes ses protections.

Une erreur de l’API REST de WordPress concerne un échange entre le site et une application, par exemple l’éditeur. Le statut HTTP et le message de la réponse permettent de distinguer une restriction, une route introuvable et une panne de traitement. Relevez l’appel exact avant de modifier le serveur ou les protections. Un index wp-json accessible ne prouve pas que toutes les actions authentifiées fonctionnent ; validez le parcours qui échouait.

Si wp-admin est inaccessible, le blocage peut venir de l’adresse de connexion, du compte, de la session ou d’une panne technique. Comparez d’abord le site public et le tableau de bord, puis relevez le message exact. Un mot de passe refusé, une erreur 403 et une boucle ne demandent pas la même intervention. Utilisez la voie de récupération adaptée, sans multiplier les tentatives ni retirer toutes les protections du site.

Pour réinstaller WordPress sans réinitialiser le site, ciblez les fichiers du cœur et préservez les contenus, la base et la configuration. Cette opération peut servir si des fichiers natifs sont absents ou altérés ; elle ne corrige pas tous les conflits et ne constitue pas un nettoyage complet après piratage. Préparez une sauvegarde, identifiez la version et la langue, choisissez une méthode adaptée à vos accès, puis testez les fonctions importantes.

Pour désactiver un plugin WordPress, utilisez le lien Désactiver dans Extensions installées si l’administration reste accessible. Sinon, un renommage ciblé de son dossier peut empêcher son chargement, avec les précautions et le retour arrière nécessaires. Ne confondez pas désactivation et suppression : les effets et les données concernées diffèrent. Testez ensuite la fonction en panne et les fonctions dépendantes avant de réactiver ou remplacer l’outil.

La taille de téléversement WordPress dépend de plusieurs plafonds, notamment upload_max_filesize et post_max_size côté PHP, mais aussi du serveur, d’un réseau multisite ou de l’outil utilisé. Relevez d’abord le message et la limite affichée dans Médias → Ajouter. Optimisez le fichier si cela suffit ; sinon, adaptez le réglage de l’environnement concerné. Un plafond relevé ne garantit pas à lui seul que le transfert et le traitement du fichier aboutiront.

La mémoire PHP de WordPress limite les ressources qu’une exécution peut utiliser. Avant de l’augmenter, vérifiez que le message indique réellement un dépassement mémoire, repérez la tâche concernée et relevez les valeurs actives. Les constantes WordPress et la configuration PHP jouent des rôles différents ; l’hébergement peut limiter ce que vous pouvez modifier. Après un changement, refaites la tâche et examinez sa consommation plutôt que de chercher une valeur maximale universelle.