[Résolu] Problème d’upload de "médias" (images) sur un blog WordPress

[Sardequin]

Déjà, bon dimanche à tous !

J’ai blog Wordpress (hébergé chez OVH) que j’alimente quasi quotidiennement. Tout à l’heure, j’essaye d’uploader une image (comme je le fais habituellement) et j’ai ce message d’erreur :

image.jpg n’a pas pu être mis en ligne Un dossier temporaire est manquant !

Le problème est apparu en tout cas aujourd’hui, puisque vendredi j’ai pu uploader une image sans souci.

J’ai testé les différentes méthodes proposées sur WordPress (glisser/déposer ou en passant par le navigateur). Rien à faire toujours le même résultat, et quelque soit le poids de l’image.

J’ai alors, pris d’une certaine angoisse tenté d’uploader un thème wordpress, résultat, même message d’erreur.

Je fait une mise à jour en passant par la console d’admin de Wordpress et là aussi :

Téléchargement de la mise à jour depuis https://downloads.wordpress.org/release/fr_...ss-4.4.2.zip…

Le téléchargement a échoué.: Impossible d’ouvrir le gestionnaire de fopen() pour /tmp/wordpress-4.4.2-bds3rv.tmp

Échec de l’installation

J’ai créé un article, pas de souci, mais bien sur impossible d’y uploader une image, en revanche, pas de problème pour les images déjà présente dans la bibliothèque. Testé avec Safari et Firefox, pareil, désactivé tous les plugins, pareil. Vérifié sur le FTP si le dossier upload était bien présent, il y est. J’ai même testé avec un second compte administrateur et pareil, même problème.

Bref, je ne sais pas si le souci vient de l’hébergeur (OVH), de la base de données (elle semble OK puisque j’ai pu ajouter un article).

Si quelqu’un a une idée, ça serait sympa de m’éclairer un peu.

(L’adresse du blog est dans ma signature)

Ce message a été modifié par Sardequin - 7 Apr 2016, 16:25.

[yponomeute]

Salut,

à tout hasard tu n'aurais pas atteint la taille limite autorisée sur ton hébergement ?

[Sardequin]

Salut,

J’y ai pensé, il faut que j’aille vérifier, mais je pense quand même plutôt à un problème de serveur ! Sinon, je devrais avoir un message différent non ?

Je viens d’aller vérifier, j’utilise 11 Go sur 25, donc ce n’est pas un problème d’espace ! La version de php est la 5.6 donc à jour (les versions plus anciennes ne sont plus supportées par OVH), donc, ce n’est sans doute pas ça non plus.

J’ai quand même envoyé un ticket d’incident à OVH, mais avec le week-end de Pâques je vais sans doute attendre leur réponse.

[Sardequin]

Bon, le problème 'est "résolu" de lui-même. je viens de tester et de uploader plusieurs images de tailles et poids différents sans difficulté de même que l’upload d’un thème wordpress !

Ça devait être un problème de serveur !

[Sardequin]

De nouveau le problème à l’instant ! C’est d’un pénible !

[Sardequin]

Problème résolu (enfin j’espère) !

Réponse d’OVH :

Bonjour,

Au vu du message je dirais qu'un autre utilisateur à saturé le /tmp (en ouvrant trop de session, en exécutant un backup de son site via un plugin utilisant le /tmp, ...) du coup, celui-ci étant mutualisé il ne vous est pas possible de l'utiliser. Un solution est d'utiliser votre espace client personnel plutôt que le /tmp.

Cdt,
Ludovic,
DevOps @ WebHosting (a.k.a. Mutu)

Logique semble-t-il !

C’est le courant alternatif chez OVH. Hier, tout était OK, aujourd’hui, rebelote donc ! Un coup ça fonctionne, un coup ça ne fonctionne plus. Pénible !

Ce message a été modifié par Sardequin - 30 Mar 2016, 15:04.

[No6]

C'est un peu normal, tu a choisi un hébergement mutualisé et à bas cout, en plus avec du Word Press, faut pas t'attendre à des performances ni à des fonctionnalités toujours disponible !

Ce message a été modifié par No6 - 2 Apr 2016, 12:41.

[Sardequin]

Oui, sauf que ça fait 3 ans que j’ai le blog Wordpress et que c’est la première fois que j’ai un problème avec l’upload direct dans wordpress.

Tiens, ce matin, ça fonctionne bien, entre 8h et mettons 11h. Et là à l’instant (11h40), pouf, dossier temporaire manquant.

Mon ticket ouvert chez OVH a eu une réponse, ils ont pu reproduire l’erreur et ils me confirme qu’il y a un problème sur le serveur. Normalement, ils sont en train de voir pour installer un correctif ! Mais ça traîne.
J’ai l’impression que le serveur, à partir d’une certaine heure, patine dans la semoule.

Alors, en effet, c’est un hébergement mutualisé, et pas cher. mais, je n’ai pas une utilisation professionnelle justifiant de payer plus que ça ! Quant à Wordpress, les performances et les fonctionnalisés ne m’ont jamais fait défaut depuis 3 ans. Pas la peine de lever les yeux au ciel donc ! Clairement, le problème ne vient pas de Wordpress mais du serveur OVH !

Ce message a été modifié par Sardequin - 3 Apr 2016, 10:48.

[No6]

Relis mieux mon message, stp.

Si je comprends bien la réponse d'ovh, le serveur que tu utilise chez eux est en surchauffe parce qu'un autre client d'ovh [voire plusieurs autres] qui est logé sur le même serveur (normal, parce que ce serveur est mutualisé), cet autre client donc doit avoir un site qui accapare les ressources de ce serveur, au point de saturer le répertoire "tmp" que tu utilise aussi quand tu upload tes images.

Leur message te conseille de passer par un autre répertoire pour les uploads, mais manque de bol pour toi, WordPress est codé pour utiliser ce répertoire.

C'est pour cela que j'ai écris que c'était normal, parce que tu utilises un serveur mutualisé à bas coût, ce qui ce traduit par le fait que ton site se trouve sur un serveur devant héberger un nombre conséquent d'autres sites, et que ses ressources sont en partage.
Tant que tu as des voisins tranquilles, tout ce passe bien, mais il suffit qu'il y en ait un de « turbulent » pour que les tracas commencent, et ton site se retrouve ralenti et/ou pénalisé, comme par exemple ce qui t'arrive pour les uploads.

Depuis 3 ans tu n'a pas connu ce genre de problème, et tant mieux pour toi, mais visiblement pour ton site la chance à tournée.

WordPress c'est très bien tant que ça marche, au fil du temps et pour causes de multiples évolutions et autres failles en sécurité, le code de WordPress est devenu d plus en plus lourd, perso je trouve que c'est une usine à gaz.

Note bien que je ne te reproche pas ni ton choix d'hébergement, ni le choix de WordPress, je dis juste que tu ne peux pas en attendre un fonctionnement impeccable tout le temps.
Et si si te retrouve avec ce premier pépin depuis 3 ans, c'est heureux, et j'imagine qu'ovh fait sont maximum pour avoir un comportement décent pour tous les sites de ces clients, mais il ne faut pas s'attendre non plus à des miracles de leur part.

Et de ce que je lis du travail sur un correctif, c'est plutôt cool de leur part, parce qu'ils n'y sont pas vraiment obligés, et parce que ce correctif en question doit ce faire sur Wordpress et sa partie de code concernant le répertoire « tmp » mutualisé.
En fait il ne te font pas vraiment une fleur, parce qu'il doit y avoir un tas de sites en WordPress sur leur serveurs et que tôt ou tard cette erreure de conception de WordPress va leur donner du fil à retordre un peu partout dans leur cheptel de sites , et qu'ils préfferrent éviter d'avoir à gérer ce bordel.

Bref au final, ovh finira sans doute à mettre un patch de plus sur WordPress et tout rentrera dans l'ordre pour toi, jusqu'au prochain emmerdement (que je ne te souhaite pas de sitôt, mais il y a les lois de Muphy qui ont l'air de t'avoir à l’œil).

Depuis WordPress, les systemes de Blogs se sont améliorés, je pense à jekyllrb.com ou hexo.io par exemple...

[Sardequin]

Alors, on va dire que j’étais quelque peu agacé par ce problème très aléatoire, fonctionnement correct le matin et serveur à genoux dans la fin de matinée pour le reste de la journée. Et un smiley peut parfois n’être pas toujours pertinent !

Donc, OVH vient de régler le problème et le "correctif" a été appliqué aujourd’hui ! On peut dire ce qu’on veut, mais même si ça a pris une semaine, c’est quand même un service rendu. Est-ce que c’est un problème WordPress, ou OVH, je ne suis pas assez compétent pour ça ! Les deux sans doute. Mais le correctif est sans doute sur leur serveur, pas dans WordPress, je doute que OVH intervienne dans le code de WordPress !

Quant à WordPress, je suis passé d’un blog Dotclear totalement obsolète (et avec des mises à jour devenues impossibles à faire à cause de ma procrastination). Je ne suis pas un pro, j’ai testé plusieurs systèmes à l’époque, même le système de blog de Google (bon, on va dire que ça dépanne). J’ai trouvé WordPress plutôt performant et surtout facile à mettre à jour. C’est tout ce que je demande, et je n’ai pas envie pour le moment de me prendre la tête à changer de plateforme de blog.

Je viens de passer une petite dizaine de minutes sur le lien jekylirb.com, et j’avoue ne pas avoir trouvé ça très simple. Mais bon, je prendrais plus de temps pour étudier ça ! Mais ça à quand même l’air d’être pas si évident que ça à installer !

Les seuls problèmes que j’ai pu avoir avec ce blog, c’est en fait avec OVH, et pas avec WordPress et donc avec l’hébergement plus qu’avec ce que j’ai mis dessus.

Et la loi de Murphy, avec deux soucis en 3 ans et ½, ça passe encore !

Édit 1 : Vu le nombre de sites WordPress que OVH doit héberger, si ce bug venait de WordPress, le forum français de WordPress serait inondé de messages, et pas que sur OVH justement ! Or, ce n’est pas le cas. Donc le bug est (était) chez OVH !


Édit 2 : Je viens de lire un article sur Jekylirb, c’est clairement destiné à un public de développeur, ce n’est donc pas pour moi !

Ce message a été modifié par baron - 5 Apr 2016, 02:31.

Raison de l'édition : Mini-rectifications d'orthographe…

[No6]

En fait, c'est tout simple, il y a juste à paramétrer correctement le fichier php.ini qu'utilise le code de wordPress.

Php.ini : directive interne = upload_tmp_dir string

Le répertoire temporaire utilisé pour stocker les fichiers lors du chargement. L'utilisateur sous lequel fonctionne PHP doit avoir les droits en écriture sur ce répertoire. Si non spécifié, PHP utilisera celui par défaut du système.
Si le dossier renseigné ici n'est pas accessible en écriture, PHP se rabat alors sur le dossier temporaire par défaut du système. Si open_basedir est activé, alors le dossier temporaire par défaut du système doit être autorisé pour que le chargement des fichiers puisse fonctionner.

Sinon, envoyer un correctif chez un fabricants de logiciels (comme WordPress) n'est pas très compliqué, et ça arrive tous les jours.
Et ils sont plutot attentifs à ce genre de chose, parce que ceux qui leur écrivent peuvent le faire pour signaler une faille dans leur systèmes, et qu 'ils pas trop intérêt à ignorer ce type de message.

Ovh à même fait une page pour ses clients pour les aider à combattre les attaques qui peuvent subir (dans le cas ou une faille est exploitée et que le correctif de WordPress n'existe pas encore)

c'est par la : https://www.ovh.com/fr/g1392.procedure-fermeture-hack-ovh




http://www.futura-sciences.com/magazines/h...ordpress-58085/

mais ça normalement tu devrai déjà connaître...

[Sardequin]

Hello Baron, l’édit pour "orthographe", c’est pour éviter les inquisiteurs de la grammaire ?

@No6

Pour les mises à jour WP, pas de souci, les mises à jour "critiques" sont faites automatiquement, et pour les grosses mises à jour, je les fais régulièrement. Il y a quand même un assez bon suivi, donc pas de soucis.

Et pour cette histoire de fichier php.ini, je vais prendre le temps d’étudier ça.

[baron]

Hello Baron, l’édit pour "orthographe", c’est pour éviter les inquisiteurs de la grammaire ?

Pour mon confort moral, et ta réputation…

[Sardequin]

Ma réputation ? Bigre ! tant que je passe pas pour un FanBoy ! Mais parfois, à lire certains messages, je me sens une furieuse envie d’être un FanBoy ! Enfin bref !

Heu ! Il y avait tant de fautes que ça ?

Bon, de toute manière le problème a été résolu par OVH, et il venait bien du serveur (mutualisé).

[No6]

et il venait bien du serveur (mutualisé).

Nan, il venait d'une bête erreur de configuration du PHP.INI, présent sur chaque site hébergé.
Comme il est configuré par défaut avec cette mauvaise directive, ovh à du lancer un script pour tous les corriger à la place de leurs clients.

Enfin, si tu préfére râler sur l'incompétence d'ovh, c'est ton choix, mais c'est pas cool.

[Sardequin]

Alors, déjà, je ne râle pas contre l’incompétence de OVH, mais je marmonne dans ma barbe un peu contre leur relative lenteur à répondre ! Une semaine pour réparer une je te cite «bête erreur» de configuration d’un fichier PHP.INI, c’est quand même pas rapide.

De plus, s’il s’agissait d’un problème spécifiquement lié à WordPress, vu la quantité de site wordpress installés chez OVH, il y aurai eu bien plus que ma simple remontée d’incident. Et sur le forum OVH, et sur le forum wordpress français, il y aurait eu bien plus que mon post. Or, avant de poster, j’ai passé un bon moment à chercher, et je n’ai rien trouvé !

Enfin bref, si tu penses que c’est WordPress qui est en cause, tu as sans doute raison…

Juste pour info, sur les serveurs mutualisés OVH, il n’y a pas d’accès à php.ini ! Il n’y a que OVH qui peut le faire ! La seule chose qu’on peut faire c’est de modifier le fichier ovh.config pour désigner la bonne version de php à utiliser (la 5.6 actuellement).

Donc, les clients sur les hébergements mutualisés OVH ne peuvent absolument pas modifier ça, sauf à bricoler, avec des risques certains, le fichier .htaccess et encore, je n’en suis pas certain !

[No6]

Grmllml..

J'ai pensé à un pb sur WordPress au début, mais ensuite, j'ai vu que c'était un problème de configuration de PHP.
Ce n'était donc ni un pb de WordPress, ni autre, mais uniquement pb de configuration de PHP..
Pas tout confondre.
Le CMS WordPress fonctionne grâce à plusieurs sous-couches logicielles et PHP en est la première.

Et Ok, j'avais oublié qu'en hébergement mutualisé on à pas accès au PHP.INI.

Sinon, une semaine pour résoudre un PB de ce type c'est largement acceptable ; comme je l'ai écris plus haut tu n'es pas dans un système de client à forte priorité et payant pour un service de résolution d'incidents dans les 24h.

Allez: un sourire

[Sardequin]

Tu as raison, une semaine ce n’est pas grand chose ! Il y a bien plus grave tous les jours !

Bon, j’ai un peu râlé (dans ma barbe de 3 jours), parce que une semaine, quand le problème est totalement aléatoire, ça semble long. En même temps, au bout de 2 jours, j’ai trouvé un plugin qui permets de faire apparaitre dans la bibliothèque de média WP les fichiers (médias) uploadés par FTP. Donc, un moindre mal !



Et puis un bon disque sur la platine aujourd’hui, ça permet de penser à autre chose qu’aux petits tracas.

[filibert]

Bonjour
je suis tombé sur votre topic en faisant des recherches car le problème d'ajout d'images est le même pour moi. Mon hébergeur est Planet Hoster je les ai donc appelé car je gère une dizaine de site par mois sous WordPress (je suis formateur) et pour chaque site la problématique était identique 'erreur HTTP' lors d'un ajout d'image. Pour eux il s'agit d'un problème lié à WordPress et sa dernière version et pour résoudre le problème il m'ont proposé d'appliquer une version PHP indépendante de WordPress. Le problème devra être résolu en une demi journée du moins c'est ce qu'ils m'ont promis (ils sont habituellement très réactifs)

[Sardequin]

Bonjour,

Le problème a bel et bien été résolu chez moi depuis mon dernier message. En fait l’hébergeur (OVH) a appliqué un « correctif » sur le serveur qui a réglé le bug. Mais, pas certain que votre problème soit totalement identique. J’ai parfois eu cette erreur « http » lors de l’ajout d’image. il s’agissait soit d’un fichier média trop lourd, et en effet, c’est peut-être une limitation de WordPress, mais il y a eu un moment ou cette erreur était liée à un problème de version de php chez mon hébergeur et avec WordPress, sachant que les dernières version de WordPress fonctionnent mieux avec PHP 5.6 et même PHP 7 (sauf plugins/extensions incompatibles).
Je pense que c’est ce que va faire votre hébergeur, indiquer à WordPress une version de PHP compatible. Par exemple, chez OVH, ça peut se faire en ajoutant un fichier .ovhconfig à la racine de l’espace disque de l’hébergement.