Bienvenue au club. Sur la discussion sur le forum de Drupal, il n'y a toujours que des gens hébergés chez OVH qui ont ce problème.
Au vu du nombre de personnes signalant de problème, celui-ci semble bien venir de OVH.
Messieurs les "Helpers" vous avez du travail.
> par contre si l'on telecharge le fichier manuellement et qu'on l'upload via cette meme page de soucis.
Ok mais quand il y en a plein c'est plus possible la bricole…
Alors tous avec Gaston ! Messieurs d'OVH faites qqchose Merci ! 
Voici la réponse d'OVH pour contourner le problème !!
"Merci de noter qu'il n'est pas conseillé de faire des mises à jour automatique
des modules drupal, Prestashop et autres directement au niveau de vos
interfaces administrateurs sous risque de voir vos sites générés des erreurs
que vous serez obligés de corriger à votre niveau.
En cas de dernière version stable de votre module drupal, la solution qui
s'offre à vous est de la télécharger puis l'installer manuellement via votre
serveur FTP . "
Et la mienne
"Je n'utilise pas un pack pré-déployé par ovh mais une version de drupal que j'ai envoyée par ftp moi-même.
Votre réponse, ne répond pas à mon problème. Libre à moi de choisir ma méthode d'update qui fonctionnait jusqu'à récemment.
Envoyer manuellement les fichiers est risque d'erreur.
Merci de me dire pourquoi cela ne fonctionne plus et pourquoi d'autres utilisateurs ovh rencontre le même problème."
Grr !!
LOL cette réponse d'OVH…
bonjour,
merci de passer en environnement stable via le guide ci dessous, cela a régler le problème de mon coté.
https://docs.ovh.com/fr/fr/web/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/
Bonjour,
Je viens d'avoir OVH au téléphone , il faut modifier le fichier .ovhconfig sur le ftp et rajouter la ligne :
container.image=stable
Un technicien me l'a fait en direct et j'ai pu tester le téléchargement ça marche 
maintenant le pourquoi du comment… l'explication d'OVH va être remontée sur ce fil.
Bonne journée
Bonjour Boulvard,
Tu as totalement raison. La configuration HTTPS des sites de drupal semble s'être renforcée récemment, ce qui rend la configuration legacy obsoléte. Un passage en configuration stable, contenant un openssl bien plus récent, devrait régler vos soucis.
(Pour info, jusque maintenant, l'environnement stable était simplement nécessaire pour Drupal 8 qui a besoin d'un drivers php-mysql récent. Maintenant, c'est obligatoire pour drupal 7 aussi)
Cordialement,
Vincent
En effet ça fonctionne avec Stable.
Et quel est la différence entre toutes versions, stable, testing, legacy, jessie ?
au temps pour moi, c'est expliqué ici : https://docs.ovh.com/fr/fr/web/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/
Eh bien voilà !
Merci aux contributeurs.
Bonjour,
Merci de votre aide, je vais retransmettre cela sur le forum de la communauté Drupal. Personnellement je verrai si ça marche lors de la prochaine mise à jour de modules, je ne vais pas simuler un retour en arrière.
Cela dit, je ne comprends toujours pas pourquoi:
- les archives des modules concernés n’apparaissent pas dans la liste du contenu du dépôt sous navigateur (là on ne passe pas du tout par OVH),
- alors qu'on arrive quand même à les télécharger à la main
Mais bon.
Et sans commentaire sur le fait que:
- la réponse officielle de OVH soit une réponse de bouffon : "merci de pendre en compte que vous ne pourrez plus utiliser votre admin panel pour faire les maj…"
- et que la réponse officielle ne nous ait pas été communiquée officiellement par OVH mais officieusement , grâce à un utilisateur, merci à lui, qui nous a fait part de sa communication téléphonique avec le support.
Merci à vous.
PS : je ne coche pas encore dans "résolu", j'attends un peu, si des fois il y aurait une autre mise à jour de module sous peu.
"legacy" signifie "héritage" c'est-à-dire en gros, c'est la config où on fait en sorte que les "vieux logiciels" marchent encore. "stable" signifie que le site est au point, "testing" qu'on est en train de bricoler dessus et donc notamment qu'il va envoyer pas mal de messages d'erreur qu'il n'enverrait pas en "stable".
Jusqu'à présent pour Drupal 7, qui était réputé être du "legacy" puisqu'il y a Drupal 8, on nous disait de mettre "legacy" dans le .ovhconfig, mais maintenant, donc, suite aux problèmes observés, on va mettre "stable".
Le fait est que Drupal 7 n'est pas si "legacy" que ça, on continue à le maintenir voire à y développer, et personnellement je ne sais pas si je passerai en Drupal 8 de mon vivant.
PS : "jessie", je ne sais pas ce que c'est.
PS : à oui, autant pour moi, je n'ai pas vu que tu avais vu où c'était expliqué 
Jessie est le nom d'une version de Debian, qu'ainsi on demande sur notre serveur.
> - et que la réponse officielle ne nous ait pas été communiquée officiellement par OVH mais officieusement , grâce à un utilisateur, merci à lui, qui nous a fait part de sa communication téléphonique avec le support.
C'est un peu dur à entendre. Il me semble qu'on est assez réactif. Moins d'une journée pour investiguer un soucis dans des codes que nous ne maitrisons pas, c'est pas mal non ?
Bref, soucis résolu
Comment procéder alors pour la configuration STABLE de PHP 3.5 ?
Je pense que **_PHP 3.5_** n'est plus proposé sur les mutualisés.
Bonjour
Je fais face au même souci de mise à jour des modules drupal sur un des mutualisés que je gère.
Lorsque j'essaye de passer en mode 'stable' ou 'jessie' (ce qui a l'heure actuelle est la même image mais bon j'ai quand même essayé), voici ce que me répond drupal
PDOException: SQLSTATE[HY000] [2000] mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD('your_existing_password'). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file in lock_may_be_available() (line 167 of /home/odelicesa/www/includes/lock.inc).
j'avoue être un peu perdu, drupal ayant été installé en v6 via l'interface OVH, puis migré en v7 à la main, la base de donnée liée au module n'apparait pas dans mon gestionnaire…
Merci d'avance
(je retourne en legacy en attendant )
Bonjour,
c'est tout simplement car drupal avait été installé avec le "1clic" OVH, là vous devez transférer la BDD du SQL module a un SQL "normale" que vous devez créer dans le manager.
Cordialement, janus57
Pour les serveurs web mutualisés perso et pro version 2010, on a pas accès aux versions php via l'espace client.
Et pour changer les versions php il n'y a pas de fichier .ovhconfig qui remplace le fichier .htaccess à la racine avec les fichiers .bash_logout, .bash_profil etc…
Il faut donc le créer à la main
pour plus d'informations sur ce fichier:
https://docs.ovh.com/fr/fr/web/hosting/activer-loptimisation-php-sur-son-hebergement-mutualise-ovh/
avec ces infos :
app.engine=php
app.engine.version=(5.6 ou 7.0 etc comme tu veux)
http.firewall=none
environment=production
container.image=stable
cette modif a résolu le problème pour moi
Chez moi c'est juste la partie
container.image=stable
qui manquait.
Et là ça marche et c'est cool