Dépannage WordPress
Erreur « Failed to write file to disk » dans WordPress
Cette erreur signifie que PHP a reçu le fichier mais n’a pas pu l’écrire à l’emplacement attendu. Elle se distingue d’un fichier trop volumineux ou d’un format refusé : le diagnostic porte sur le stockage et les droits effectifs.
Ce que ce symptôme signifie réellement
Les causes fréquentes sont un volume plein, un quota atteint, un dossier temporaire indisponible, un propriétaire incorrect ou un répertoire uploads non accessible au processus PHP.
Ouvrir tous les droits sur wp-content expose le site sans expliquer la cause. Les droits corrects dépendent du compte qui possède les fichiers et de l’utilisateur du serveur web.
Avant toute modification : préserver les preuves et le retour arrière
Notez l’heure, l’URL, le message exact, le code HTTP et le dernier changement connu. Vérifiez ensuite qu’une sauvegarde récente couvre bien les fichiers et la base de données, qu’elle est lisible et qu’un retour arrière limité est possible. Une sauvegarde non testée ne suffit pas pour une intervention risquée.
- Ne transmettez jamais de mot de passe, clé privée, jeton, fichier
wp-config.phpou export de base dans un formulaire ou une capture. - Travaillez d’abord sur un staging ou une copie isolée lorsque le diagnostic exige une mise à jour, une modification de code ou une opération de base de données.
- Conservez les journaux et les fichiers suspects avant nettoyage : ils peuvent être nécessaires pour comprendre la cause ou vérifier l’étendue d’un incident.
Diagnostic : avancer du signal le plus fiable au test le moins intrusif
Reproduisez avec un petit fichier autorisé et notez l’erreur exacte. Contrôlez l’espace, les inodes, les quotas et la configuration temporaire avant de modifier des permissions.
- Lire le code d’erreur d’upload PHP et les journaux WordPress/PHP à la même heure.
- Contrôler espace disque, inodes, quota du compte et accessibilité du dossier temporaire PHP.
- Comparer propriétaire, groupe et permissions de
wp-content/uploadsavec un fichier récemment créé par WordPress. - Vérifier le chemin d’upload configuré et l’existence du sous-dossier année/mois sans le recréer avec des droits ouverts.
Correction : appliquer une action ciblée et réversible
Corrigez la ressource réellement en défaut : capacité, dossier temporaire, propriétaire ou droit d’écriture minimal.
- Libérer ou étendre l’espace après identification des fichiers responsables, sans supprimer journaux ou sauvegardes utiles au hasard.
- Rétablir le propriétaire attendu et des permissions minimales cohérentes avec l’hébergement.
- Corriger le dossier temporaire PHP au niveau serveur si le test natif échoue aussi hors WordPress.
- Créer le répertoire uploads manquant avec le bon propriétaire, puis refaire un upload de test non sensible.
Contrôles après correction
Une page qui se recharge ne suffit pas à prouver que le problème est résolu. Contrôlez le parcours concerné, une page non connectée, l’administration, les erreurs console et réseau, les journaux serveur, le cache et les redirections. Vérifiez aussi les écrans mobile et desktop si le symptôme touchait le rendu.
- Upload d’une petite image puis génération des tailles sans erreur.
- Aucun répertoire world-writable et aucun changement global non nécessaire.
- Espace, inodes et journaux surveillés après la correction.
Quand arrêter et demander une intervention
Un serveur plein ou un propriétaire incohérent après déploiement peut affecter sauvegardes, sessions et mises à jour : faites vérifier le système avant de multiplier les chmod.