Comparer deux comptes avec le même petit fichier
Quand un membre de l’équipe peut écrire un article mais voit un refus dès qu’il ajoute une image, commencez par un test que vous pouvez répéter. Sur une copie, choisissez une petite image PNG ou JPEG déjà ouverte avec succès dans une visionneuse. Utilisez le même fichier, le même navigateur ou deux profils comparables, et le même sous-site. Gardez le nom, l’extension, la taille en octets et le texte exact du refus. Une capture sans ces valeurs risque de mélanger deux problèmes différents.
Essayez d’abord depuis **Médias → Ajouter un fichier média**, si le compte voit cet écran. Comparez avec une personne déjà autorisée à déposer des fichiers sur ce site. Si le compte concerné ne voit ni l’entrée de la médiathèque ni le bouton d’ajout, notez-le. Le menu peut être personnalisé. Vérifiez aussi si le problème se reproduit dans l’éditeur, avec le même fichier et dans un document que ce compte a le droit de modifier. Un contrôle dans un formulaire public ou dans un constructeur peut utiliser les règles de ce composant. Pour ce premier relevé, gardez le chemin natif de la médiathèque.
Une fois le résultat noté, vérifiez si l’image figure déjà dans la médiathèque. Une page qui affiche une erreur après un enregistrement interrompu peut laisser un élément utilisable ou incomplet. Recherchez le nom et l’heure avant de réessayer. Gardez le premier cas valide pour les tests suivants afin de comparer toujours les mêmes conditions.
- Si un compte échoue avec le petit PNG et que l’autre l’ajoute dans le même écran, contrôlez d’abord la permission du compte et le site auquel il appartient.
- Si les deux comptes peuvent ajouter le PNG, essayez le fichier qui déclenchait le refus avec le compte autorisé. Un échec lié à ce fichier oriente vers son format, sa taille ou une règle liée à l’écran.
- Si le même compte ajoute le média dans la médiathèque mais échoue dans un article précis, vérifiez qui possède cet article et qui peut le modifier. La liaison au document peut déclencher un contrôle distinct.
- Si les deux comptes échouent aussi sur le petit PNG, recueillez le message et vérifiez le trajet de la requête, le stockage ou le dossier temporaire avant de modifier un rôle.
Approche 1 — Vérifier la capacité de téléverser
Le droit WordPress à vérifier pour la médiathèque native s’appelle upload_files. Dans les rôles natifs, un Contributeur peut préparer ses articles sans disposer de cette capacité. Un Auteur la possède normalement, avec d’autres droits dont celui de publier ses propres articles. Le nom du rôle donne un premier indice. Une extension, une politique de site ou une configuration multisite peut modifier les capacités réellement accordées.
Avec un compte qui gère les utilisateurs, ouvrez **Utilisateurs → Tous les utilisateurs**, puis vérifiez le rôle du compte concerné sur le bon site. En multisite, vérifiez l’appartenance à ce sous-site. Si vous êtes le rédacteur concerné, transmettez le sous-site, l’écran, le fichier témoin et la différence observée. La personne habilitée pourra confirmer le droit sans vous donner accès à l’administration du réseau ou du serveur.
Si la personne doit continuer à travailler avec les droits de Contributeur, un collègue habilité peut déposer le média puis l’insérer dans le document selon le circuit de relecture. Si la tâche nécessite des dépôts réguliers, faites valider la capacité à ajouter et le périmètre de comptes concernés. Sur un site qui dispose déjà de rôles personnalisés, le responsable peut tester sur copie l’ajout de la seule capacité nécessaire à un rôle dédié ou à un compte prévu à cet effet. Promouvoir tout un groupe à Auteur ou Administrateur élargirait aussi d’autres droits. Conservez le rôle ou la configuration précédente pour l’annulation.
Le contrôle suivant s’adresse au responsable qui dispose déjà de WP-CLI et peut charger ce site. Exécutez-le depuis le dossier WordPress. Remplacez l’URL par celle du site ou du sous-site et 123 par l’identifiant du compte à examiner. La commande affiche si le compte possède la capacité dans ce contexte. Reprenez ensuite le test réel dans la médiathèque, car le contexte d’une extension ou d’une demande d’attachement peut appliquer d’autres contrôles.
wp --url=https://exemple.test --user=123 eval 'echo current_user_can("upload_files") ? "oui" . PHP_EOL : "non" . PHP_EOL;'Distinguer la médiathèque et le document auquel joindre le média
Si le compte peut envoyer le même PNG dans **Médias** et qu’il est refusé seulement lors de l’ajout à un article, ouvrez un brouillon qui lui appartient sur la copie. Comparez avec l’article concerné. Relevez si la demande essaie de créer le média seul ou de le joindre à un document que ce compte ne peut pas modifier. Sur la route REST native, WordPress contrôle le droit de modifier le document indiqué lors du rattachement.
Avec le responsable éditorial, choisissez qui doit ajouter l’image à l’article. Un auteur habilité à déposer le fichier peut le mettre dans la médiathèque, puis la personne qui peut modifier l’article l’insère si le processus du site le permet. Si le document doit changer de responsable, faites traiter son affectation dans le circuit de publication. Vérifiez le résultat dans l’article exact et depuis l’aperçu, puis relisez le statut du brouillon. En cas d’erreur, retirez le seul bloc ou rattachement ajouté et conservez le fichier s’il sert ailleurs.
La recette a reproduit cette distinction avec deux rôles natifs. Le Contributeur a reçu rest_cannot_create avec le PNG intact. L’Auteur a reçu rest_cannot_edit lorsqu’il a essayé de joindre le même PNG au brouillon de l’autre compte. Il a pu déposer le fichier seul dans la médiathèque. Le contrôle WP-CLI a indiqué « non » pour le Contributeur et « oui » pour l’Auteur.
Approche 2 — Comparer le type et la taille avec le compte habilité
Cette approche convient quand le compte peut déposer le fichier témoin ou que plusieurs comptes échouent sur un fichier particulier. Ouvrez le fichier qui pose problème dans l’application qui l’a produit, puis relevez son extension et son format réel. Un fichier renommé de .heic en .jpg garde ses données d’origine. Pour obtenir un JPEG, exportez ou convertissez une copie avec une application qui lit le format de départ. Rouvrez le fichier converti avant l’envoi et gardez l’original hors de la médiathèque de test.
Sur la copie, faites trois essais à partir du même écran. Envoyez le petit PNG de référence, puis un fichier de même famille dont le site doit accepter le format. Enfin, essayez une version réellement exportée du fichier qui échouait. Si les images de référence passent et que l’original seul est refusé, relevez le message et le type exact. WordPress tient compte de son ensemble de formats admis et vérifie la cohérence du fichier. Le type indiqué par le navigateur n’est qu’une partie du contrôle. Certaines images peuvent aussi dépendre des formats pris en charge par les bibliothèques du serveur.
Si l’organisation a besoin d’un type supplémentaire, demandez au responsable de vérifier sa politique de fichiers, les formats pris en charge et la façon dont ce type sera servi. Sur un réseau multisite, les types autorisés par le réseau peuvent s’ajouter aux règles de WordPress. Testez la décision sur copie avec un fichier approuvé et gardez la valeur antérieure. Une conversion en format déjà accepté suffit souvent quand le document n’a pas besoin de conserver son format natif. Pour revenir en arrière, retirez le fichier de test après avoir vérifié qu’il n’a pas été utilisé. Rétablissez le réglage précédent si vous avez changé la politique de formats.
Une conversion réussie doit produire un média identifiable avec le bon type et un aperçu cohérent. Regardez le résultat dans la médiathèque, puis dans un brouillon si l’image doit servir dans un article. Une vignette manquante alors que le fichier figure dans la liste demande de vérifier le traitement d’image ou l’écriture des fichiers dérivés. C’est une étape différente du refus initial.
Lire la limite qui s’applique à l’envoi
Dans **Médias → Ajouter un fichier média**, relevez la taille maximale affichée si elle est disponible. Avec un compte habilité, **Outils → Santé du site → Informations** peut aider à relever les paramètres PHP et les données sur les médias ou le serveur. En multisite, le responsable peut aussi vérifier la taille autorisée par fichier et l’espace restant du site. La valeur affichée par WordPress ne tient pas forcément compte d’un plafond plus bas imposé par le service qui reçoit la demande avant PHP.
Sur la copie, comparez deux images réellement valides du même type, une petite et une plus lourde. Gardez la taille en octets, l’heure et le message de chaque essai. Dans **Réseau**, cherchez la requête de téléversement correspondante. Si le navigateur reçoit une page d’erreur **413**, la requête a pu être refusée par le serveur web, un proxy ou un autre relais. Le statut seul ne désigne pas le composant exact. Transmettez l’heure et le chemin utile au responsable pour qu’il puisse vérifier la bonne couche. Si la réponse est un message WordPress, relevez le code et son détail.
Si une version moins lourde convient, exportez-la et vérifiez sa qualité à la taille d’affichage prévue. Si l’équipe doit recevoir le fichier original, faites ajuster uniquement la limite démontrée par le responsable de la couche concernée. Conservez la valeur de départ et vérifiez que la nouvelle limite couvre aussi la requête entière. Refaites le test avec le fichier valide qui échouait et avec le petit PNG. Pour annuler le changement, remettez la valeur conservée et vérifiez le comportement. Le plafond reste une règle du site ou du service. Évitez de l’ajuster pour une personne dont le compte ne possède pas la capacité de téléverser.
upload_max_filesizelimite la taille de chaque fichier traité par PHP. Quand cette limite est franchie mais que PHP a pu traiter le corps multipart, PHP peut fournir le codeUPLOAD_ERR_INI_SIZE. WordPress affiche alors un message relatif au fichier.post_max_sizelimite le corps total envoyé. Un envoi multipart contient le fichier et les séparateurs ainsi que les autres champs. Si ce plafond est dépassé, PHP peut laisser les données de formulaire et les fichiers vides. L’application peut alors annoncer qu’aucun fichier n’a été fourni.- Un quota multisite, un manque d’espace ou un dossier temporaire inaccessible peut aussi empêcher l’écriture. Demandez quelle ressource a réellement manqué. Un plafond relevé dans PHP ne résout pas un quota ni un refus du proxy.
Isoler un formulaire qui refuse le fichier
Si le même compte dépose le même PNG dans la médiathèque mais échoue dans un formulaire de dépôt sur le site, testez les deux écrans séparément. Sur la copie, ouvrez les outils du navigateur, affichez l’onglet Réseau, videz la liste, puis envoyez un seul fichier. Relevez la méthode et le chemin de la requête qui échoue. Le dépôt natif peut passer par la route des médias alors qu’un formulaire utilise sa propre adresse et applique sa propre taille maximale.
Cherchez dans les réglages du champ les types de fichiers acceptés, la taille maximale et les conditions d’accès. Si l’interface refuse le fichier avant tout départ réseau, relevez le message du champ et comparez avec un autre fichier conforme. Si la demande part et revient avec une erreur, notez l’heure, le statut et le texte affiché. Pour transmettre le relevé, copiez ces seules informations. Un export réseau complet peut contenir la session de connexion ou les données du formulaire.
Refaire les comparaisons après la correction
Sur WordPress 7.1.4, la recette a envoyé les fichiers en HTTP multipart vers PHP sur la boucle locale. Elle a fait traiter les demandes par la route native des médias, avec les deux rôles témoins. L’Auteur a reçu **201** et un identifiant de média pour le PNG de référence. Un petit fichier texte portant une extension fictive non admise a été refusé après réception par PHP. La réponse WordPress indiquait le type de fichier, alors que le même compte avait le droit de téléverser.
Sur le serveur PHP de la recette, la limite par fichier était de 16 Kio et celle du corps de 64 Kio. Un PNG valide situé entre ces deux limites a produit le code PHP **1** et un message nommant upload_max_filesize. Un PNG qui dépassait la limite du corps est arrivé à WordPress sans fichier et a produit rest_upload_no_data. Le code HTTP **500** rencontré pour certains refus WordPress de la recette ne désignait donc pas une cause unique. Pour départager ces cas, le message et le code PHP étaient plus précis.
Après une correction de droit, vérifiez que le compte prévu dépose le petit PNG et qu’un compte qui doit rester Contributeur conserve son périmètre. Après une correction de format ou de taille, reprenez le même fichier approuvé qui échouait, avec le même compte et le même écran. Retrouvez le média une seule fois dans la bibliothèque et ouvrez son aperçu. Si l’ajout devait se faire dans un article, vérifiez séparément son insertion dans le bon document. Le résultat attendu est un média utilisable et une permission cohérente avec le rôle prévu.
Consignez la cause et la valeur que vous avez changée. Gardez le site, l’écran, la taille et le message plutôt qu’un journal contenant le contenu du document. Si le test échoue encore, transmettez ces éléments avec l’heure et la comparaison des deux comptes ou des deux fichiers. Retirez les médias fictifs de la copie à la fin et vérifiez que le vrai fichier est disponible avant de retirer la version précédente.
