Comprendre où l’écriture échoue
Vous envoyez une image ou un document, puis WordPress indique qu’il ne peut pas écrire le fichier sur le disque. Le transfert a parfois déjà commencé, les anciens médias restent visibles et l’administration semble fonctionner. Le résultat recherché est simple : enregistrer un nouveau fichier dans la médiathèque sans modifier inutilement les droits du reste du site.
Un envoi classique traverse deux emplacements. PHP, le logiciel qui exécute WordPress sur le serveur, reçoit d’abord le fichier dans un dossier temporaire. WordPress peut ensuite le déplacer dans le dossier définitif des médias. Un échec à la première étape et un échec à la seconde demandent des vérifications différentes. Le mot « disque » ne désigne donc pas nécessairement le dossier uploads.
Cette procédure concerne l’enregistrement du fichier. Si le message annonce plutôt une taille maximale dépassée, un format interdit ou un traitement d’image impossible après réception, utilisez le diagnostic correspondant. Augmenter la mémoire ou autoriser un nouveau format ne répare pas un emplacement devenu impossible à écrire.
Relever le message avant de choisir une réparation
Copiez le texte complet de l’erreur, l’heure avec votre fuseau horaire et l’écran utilisé. Une traduction, une extension ou un formulaire peut modifier le libellé. Le support pourra retrouver la requête correspondante plus facilement avec ces renseignements qu’avec une capture montrant seulement une barre rouge.
Lorsque le code PHP est disponible dans un diagnostic privé, le code 6, UPLOAD_ERR_NO_TMP_DIR, indique l’absence d’un dossier temporaire. Le code 7, UPLOAD_ERR_CANT_WRITE, signale un échec d’écriture pendant la réception PHP. WordPress traite ces erreurs avant le déplacement vers la destination finale. Ne concluez donc pas que les permissions de la médiathèque sont responsables.
Un message indiquant que le fichier ne peut pas être déplacé vers un chemin, ou que ce chemin ne peut pas être créé, oriente vers la destination. Il reste à distinguer stockage saturé, mauvais propriétaire et accès refusé. Le libellé seul ne permet pas de choisir un nouveau nombre de permissions.
Faire un essai limité et conserver les indices
Gardez votre original sur l’ordinateur. Préparez un petit fichier sans données personnelles, déjà lisible localement et d’un type normalement accepté sur ce site. Donnez-lui un nom reconnaissable pour éviter de le confondre avec une publication existante. Depuis Médias, utilisez Ajouter un fichier média ou l’intitulé équivalent de votre interface.
Effectuez un seul envoi, puis examinez le résultat. Avant toute nouvelle tentative, recherchez ce nom dans la médiathèque : un message général peut apparaître alors qu’une partie de l’opération a abouti. Des essais répétés risquent surtout d’accumuler des doublons.
Si le petit fichier échoue de la même manière, conservez ce résultat pour le diagnostic. S’il réussit, ne considérez pas le serveur comme définitivement sain : une capacité presque épuisée peut encore accepter un petit fichier. Comparez alors le message du fichier initial. Si seul un formulaire échoue alors que Médias fonctionne, signalez ce point d’entrée au responsable du formulaire ; ses réglages peuvent utiliser un autre emplacement.
Choisir l’approche et vérifier vos accès
Sur un WordPress autohébergé, l’administration du site et le panneau de l’hébergeur sont deux accès distincts. Un compte administrateur WordPress ne donne pas automatiquement le droit de modifier la configuration PHP, le propriétaire des fichiers ou les quotas. Préparez l’accès au bon compte d’hébergement avant de suivre une manipulation.
Dans Outils, Santé du site, Informations, relevez les versions de WordPress et de PHP, puis consultez les rubriques des répertoires et des permissions du système de fichiers. Ces informations constituent des indices. Un dossier principal déclaré accessible ne garantit pas que son sous-dossier du mois, le stockage temporaire ou toutes les limites du compte conviennent.
- Commencez par l’approche 1 lorsqu’un indicateur de stockage est saturé ou que plusieurs opérations d’écriture échouent.
- Choisissez l’approche 2 si le message ou le diagnostic vise le dossier temporaire PHP ou le code d’erreur 7.
- Suivez l’approche 3 si l’erreur désigne la création du dossier des médias ou le déplacement vers celui-ci.
Approche 1 : identifier la capacité réellement épuisée
Ouvrez le panneau de l’hébergeur et sélectionnez le compte qui héberge ce domaine. Cherchez Utilisation du disque, Stockage ou Ressources. Dans cPanel, la rubrique Disk Usage décrit l’espace utilisé par le compte. Relevez la consommation et la limite, plutôt qu’une simple barre colorée, ainsi que l’heure de la consultation.
Contrôlez séparément le nombre de fichiers ou d’inodes lorsqu’il est affiché. Un inode représente ici une entrée de stockage pour un fichier ou un dossier. Une limite atteinte peut empêcher une nouvelle création alors qu’il reste des gigaoctets disponibles. La capacité en octets et le nombre de fichiers répondent à deux questions différentes.
Le quota est l’allocation de votre compte. Le disque qui l’héberge possède aussi ses propres limites, et le dossier temporaire peut dépendre d’un autre emplacement. Un tableau de bord rassurant ne suffit donc pas à exclure toute saturation. Demandez au support de vérifier l’espace et les inodes sur les emplacements effectivement utilisés pour la réception temporaire et la destination.
Notez les résultats séparément. Si l’hébergeur confirme une saturation de l’infrastructure partagée, son équipe doit intervenir ; vos réglages WordPress ne libéreront pas ce stockage.
Récupérer de la capacité sans sacrifier les médias
Lorsqu’une limite de votre compte est confirmée, identifiez ce qui occupe la ressource concernée. Une vieille archive de migration connue et conservée ailleurs peut être une candidate à retirer. Une galerie encore publiée ne l’est pas. Une archive volumineuse réduit surtout l’espace occupé ; une multitude de petits fichiers peut surtout expliquer les inodes.
Avant un retrait, vérifiez la copie extérieure au compte et son contenu. Ne lancez pas une nouvelle sauvegarde complète dans un espace déjà saturé : sa création peut échouer et consommer la marge restante. Faites valider par le support les fichiers techniques dont vous ignorez l’usage. Les dossiers temporaires partagés et les fichiers de sessions ne sont pas une réserve à vider manuellement.
Si aucun élément dispensable n’est identifié, demandez un ajustement ciblé de capacité ou une solution de stockage adaptée. Après intervention, attendez l’actualisation du compteur ou faites confirmer la valeur réelle, puis refaites l’essai limité. Si la capacité est redevenue disponible mais que la même erreur persiste, poursuivez avec l’emplacement indiqué. Ne multipliez pas les suppressions pour un problème de permissions.
Approche 2 : vérifier le dossier temporaire de PHP
Cette approche concerne la réception initiale du fichier. Le paramètre upload_tmp_dir désigne le dossier temporaire des téléversements PHP. S’il n’est pas défini, PHP utilise le dossier temporaire du système. Une valeur vide n’est donc pas, à elle seule, une anomalie.
Le dossier doit être accessible en écriture à l’identité qui exécute PHP. Si le dossier configuré n’est pas inscriptible, PHP tente le dossier temporaire système. Une restriction open_basedir, qui limite les chemins accessibles à PHP, doit également permettre l’emplacement de repli. Il faut examiner la configuration effective, pas simplement constater qu’un dossier nommé tmp existe quelque part dans votre compte.
Demandez ce contrôle pour le PHP qui sert le domaine concerné. Une vérification réalisée uniquement avec PHP en ligne de commande peut utiliser une autre configuration. Fournissez au support le code d’erreur et l’heure de l’essai ; il pourra vérifier le chemin utilisé, l’identité du processus et l’état du stockage à cette étape.
Ne créez pas de page publique phpinfo() ou de script de test accessible aux visiteurs pour obtenir ces renseignements. Utilisez les diagnostics privés du panneau ou l’assistance de l’hébergeur.
Corriger le temporaire par le réglage prévu
upload_tmp_dir est un paramètre de niveau système. Ajouter un appel ini_set() dans WordPress ou une ligne dans .user.ini ne constitue pas une correction valable de ce paramètre. Si votre panneau propose ce réglage, vérifiez d’abord auprès de l’hébergeur qu’il agit sur le PHP du domaine.
La correction doit rétablir un dossier autorisé, disponible et utilisable par le service. Le prestataire peut réparer l’emplacement existant ou fournir un chemin dédié. Ce dernier doit être protégé contre l’accès public : recevoir des fichiers temporaires dans un répertoire exposé du site n’est pas un bon dépannage.
Ne confondez pas ce réglage avec WP_TEMP_DIR. Cette constante intervient dans le choix du temporaire pour certaines opérations internes de WordPress. Elle ne remplace pas la configuration de réception des fichiers par PHP. La définir au hasard dans wp-config.php risque de laisser l’erreur initiale intacte tout en ajoutant une configuration à maintenir.
- Consignez le réglage précédent et le chemin proposé par le prestataire.
- Appliquez uniquement sa procédure pour ce domaine, avec le rechargement du service s’il est nécessaire et autorisé.
- Faites confirmer la valeur effective, puis testez un envoi depuis Médias.
- En cas d’échec, transmettez le nouveau message et faites restaurer la configuration précédente si le changement n’est pas retenu.
Approche 3 : retrouver la destination exacte des médias
Cette approche suppose que l’erreur vise la création d’un dossier ou le déplacement du fichier reçu. Reprenez le chemin indiqué, puis ouvrez le gestionnaire de fichiers du bon domaine. Ne partez pas de l’hypothèse que tous les sites du compte utilisent le même dossier public.
Dans une installation habituelle, les médias se trouvent sous wp-content/uploads, éventuellement répartis par année et mois. Ce chemin peut être personnalisé. Un réseau multisite ou une solution de stockage externe peut également organiser les fichiers autrement. Faites confirmer le chemin réel avant de créer un répertoire ou de modifier ses propriétés.
Vérifiez si le dossier final existe et si son parent existe. Une panne au changement de mois peut coïncider avec la création d’un nouveau sous-dossier ; c’est une piste, pas une preuve. Comparez ses propriétés avec celles d’un dossier voisin fonctionnel, sans les recopier automatiquement.
Après une migration, un ancien chemin absolu peut aussi rester dans une configuration personnalisée. Faites corriger le réglage identifié par la personne qui l’a installé. Créer artificiellement l’ancienne arborescence ou modifier des options de base de données au hasard masquerait la cause.
Distinguer le propriétaire des permissions
Le propriétaire d’un fichier est un compte du système d’hébergement, pas l’auteur affiché dans WordPress. Les permissions définissent ensuite ce que ce propriétaire, son groupe et les autres comptes peuvent faire. Le service PHP doit disposer des droits adaptés pour créer un fichier dans la destination.
Un accès SFTP réussi ne prouve donc pas que PHP peut écrire au même endroit : les deux opérations peuvent utiliser des identités différentes. À l’inverse, la lecture des anciennes images dans le navigateur ne démontre pas la possibilité d’en créer de nouvelles. Présentez ces observations comme des indices distincts.
Un dossier restauré par un autre compte peut avoir des permissions apparemment habituelles mais un propriétaire inadapté. Dans ce cas, demandez à l’hébergeur de corriger l’association au compte ou au groupe prévu. Élargir les droits pour compenser un mauvais propriétaire laisse le problème de fond en place.
Les valeurs courantes 0755 pour les dossiers et 0644 pour les fichiers ne constituent pas une prescription universelle. Le fonctionnement dépend de l’identité PHP et de la politique du serveur. N’appliquez jamais 777 pour contourner l’erreur, même temporairement.
Appliquer uniquement la correction de permissions confirmée
Si le propriétaire est correct et que l’hébergeur confirme une valeur de permissions pour un dossier précis, vous pouvez effectuer cette modification avec l’accès autorisé. Dans cPanel, ouvrez le gestionnaire de fichiers, sélectionnez uniquement ce dossier puis Permissions. D’autres panneaux proposent une commande similaire dans les propriétés.
Photographiez ou notez la valeur actuelle, le chemin et la valeur attendue. Vérifiez qu’aucune option d’application aux sous-dossiers et aux fichiers n’est cochée. Une modification récursive touche toute une arborescence : elle dépasse le besoin si seul un dossier a été mal créé.
Enregistrez la correction, puis refaites l’envoi limité. Si l’erreur reste identique, remettez la valeur précédente, sauf consigne explicite du support de conserver la nouvelle. Transmettez le résultat au lieu d’essayer successivement des permissions plus ouvertes. Un changement de propriétaire relève généralement du prestataire lorsque votre compte n’en a pas le droit.
Lorsque les droits et l’identité sont corrects, demandez si le stockage est passé en lecture seule ou si une règle d’accès propre au serveur empêche l’écriture. Ces situations nécessitent un diagnostic d’infrastructure. Ne désactivez pas une protection globale et ne modifiez pas tous les dossiers du site pour les contourner.
Adapter la procédure à WordPress.com et au multisite
Sur WordPress.com, commencez dans le tableau de bord d’hébergement, sélectionnez le site puis consultez son aperçu et son stockage. Les capacités et les accès techniques dépendent de l’offre. Un accès aux fichiers, lorsqu’il existe, ne signifie pas que vous pouvez administrer le temporaire du service PHP.
Si l’espace autorisé est disponible et que l’erreur d’écriture persiste, transmettez le cas à l’assistance de la plateforme. Évitez d’ajouter des réglages destinés à un serveur que vous administreriez vous-même. La limite de stockage et une panne de l’infrastructure doivent être examinées séparément.
Dans un réseau multisite, faites intervenir l’administrateur réseau. Le sous-site peut atteindre son allocation de médias alors que le serveur dispose encore de place. Les réglages réseau d’envoi et les éventuels réglages propres au site doivent être vérifiés avant toute intervention sur le système de fichiers.
Précisez quel sous-site est concerné et si d’autres sont touchés. Cette comparaison aide à cibler l’enquête sans justifier une modification commune. Les chemins et les identités restent à confirmer pour ce réseau ; changer les permissions de toute l’installation pour un seul sous-site n’est pas une réparation ciblée.
Vérifier l’enregistrement après la correction
Utilisez d’abord le petit fichier de contrôle, puis un fichier représentatif du besoin initial. Vérifiez que chaque envoi produit une seule entrée dans Médias, que le fichier s’ouvre depuis son URL et qu’il s’affiche correctement dans l’aperçu d’un brouillon. N’écrasez pas une image existante pour réaliser cette vérification.
Si le fichier original est accessible mais que ses variantes ne se créent pas, l’écriture initiale a progressé ; relevez le nouveau message et poursuivez avec le diagnostic du traitement des images. Une erreur différente n’autorise pas à déclarer tout le parcours réparé, mais elle évite de revenir indéfiniment sur la même étape.
Retirez uniquement les fichiers de contrôle que vous identifiez et qui ne sont utilisés nulle part. Conservez une note du réglage réellement efficace, de son périmètre et de la date. Les changements sans effet doivent avoir été annulés ou explicitement validés par le prestataire avant de clore l’incident.
Transmettre un dossier utile et prévenir la récidive
Si aucune cause n’est confirmée, adressez au support un relevé compact des observations. Demandez où l’écriture échoue et quelle identité tente l’opération. Une réponse limitée à « vérifiez les permissions » ne suffit pas : il faut connaître le dossier concerné et la correction compatible avec cet hébergement.
Après résolution, activez les alertes de stockage proposées par le prestataire et vérifiez la destination des sauvegardes. Faites conserver dans les notes de migration le propriétaire attendu et toute configuration temporaire particulière. Ces informations permettront de comparer une prochaine panne avec un état connu, sans ouvrir davantage les accès.
- Indiquez le domaine, le sous-site éventuel, l’écran utilisé et l’heure exacte avec le fuseau.
- Joignez le message complet, le code PHP s’il est connu et le résultat de l’essai limité.
- Précisez les versions WordPress et PHP, ainsi que toute migration, restauration ou modification d’hébergement récente.
- Ajoutez les mesures disponibles d’espace et d’inodes, les chemins examinés et les changements déjà annulés ou conservés.
- Transmettez les chemins internes et extraits de journaux dans le ticket privé, en retirant les données personnelles, jetons et identifiants inutiles.
