Bonjour,
voulant effectuer la dernière mise à jour de sécurité, j’obtiens ce message : « Impossible de récupérer le fichier https://www.spip.net/spip_loader.api »
avant de poster j’ai vérifié tout ceci
hébergeur en php 8.1
SPIP actuel : 4.1.7 aprés migration récente de la 4.0 à la 4.1.7 (peut être au final un bug à ce niveau … ?)
allow_url_fopen : on
En utilisant le texte « document distant » j’arrive depuis le site à obtenir https://www.spip.net/spip_loader.api. J’obtiens à l’écran de la ligne de code qui commence par : {« api »:2,« versions »:{« dev »:« spip/dev/spip-master.zip »,« 4.2.2 »…
ai demandé à mon hébergeur (LIKUID) si changement sur le serveur. Réponse de leur part : non.
ai transféré le dernier spip loader via ftp en binaire.
ai vidé le cache
ai mis à jour tous les plug-in et vérifié que les obsolètes étaient en INACTIFS
et là je cale … une idée ?
En tous les cas bonne journée à toutes et tous.
et bien l’erreur survient une fois que l’url monsite/spip_loader.php est lancée. La page d’erreur avec le message apparait. Je ne sais pas si cela répond à la question…
Super, après avoir lancer le script de la beta debug, j’ai eu accès au lancement de la mise à jour MAIS !ca n’a jamais abouti et maintenant plus d’accès à mon site !
super conseil ! # Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at webmaster@neomens.net to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
Ha ben c’est vrai ça, quel scandale ces gens qui souhaitent aider les autres ! :\
Sérieusement, ça sent le timeout sur l’étape de suppression des fichiers obsolètes, quelle est l’adresse complète de la page qui affiche cette erreur ?
ok, on va dire que je participe à l’amélioration du loader.
L’adresse complète n’y changera rien. Plus d’accès que ce soit en visiteur ou en administrateur. Le serveur ne répond plus depuis le lancement du script.
Si tu donnes l’adresse ça permettra peut-être à un développeur de voir ce qui se passe… Sinon il faut que tu creuses par toi-même : des fois ce genre d’erreur peut être provoquée par un .htaccess un peu ancien, ou un plugin qui entrerait en conflit (donc renommer le dossier plugins le temps de retrouver l’accès ?).
Il y a sans doute d’autres causes possibles à chercher dans ton installation.
En tout cas chez moi le nouveau loader marche bien.
Non rien n’y fait mais ça valait le coup d’essayer. Merci.
Les plug-in étaient à jour (mais j’ai testé en renommant le dossier), le HTACCESS non plus je pense (j’ai testé sans et avec un fichier plus récent). Ce qui est rageant c’est qu’enfin avec ce loader j’ai pus lancer la procédure mais elle a fini dans les choux après un long moment.
Je viens de faire une mise à jour manuelle via FTP de la 4.19 vers ma 4.17.
Pas mieux, plus aucun accès.
Côté hébergeur le log des erreurs indique qu’il ne trouve pas spip.php (file does not exist) durant tous les essais. Bien entendu spip.php est bien présent dans le répertoire mais c’est comme si le serveur ne le voyait pas.
il s’est affiché correctement sur ton hébergement ?
il n’indiquait plus la précédente erreur ( « Impossible de récupérer le fichier …spip_loader.api ») ?
il a semblé fonctionner (jusqu’à un timeout).
Ça semble un progrès par rapport à la version 6.0, non ?
Je ne sais que te dire pour le reste… j’ai vaguement l’impression que l’hébergement en question n’est pas très véloce… Pour la lecture des fichiers, est-ce que ça peut être un problème de chmod ? Tu peux le voir dans le ftp que les fichiers sont accessibles en lecture ?
[quote=« marcimat, post:15, topic:167942 »]
Questions @HHHH sur le loader testé
il s’est affiché correctement sur ton hébergement ? OUI c’était parfait
il n’indiquait plus la précédente erreur ( « Impossible de récupérer le fichier …spip_loader.api ») ? En effet avant je n’avais pas l’affichage du loader
il a semblé fonctionner (jusqu’à un timeout). OUI
Jusqu’a présent pas de soucis avec cet hébergeur. Ca fait dix ans que le site tourne sans problème avec les mises à jour du loader en version 3 puis 4.
C’était en effet les droits.
Les droits des fichiers racines et répertoires Ecrire et Config étaient restés en 0666 suite j’imagine au fait que le loader n’a pas pu aller jusqu’au bout (timeout)
A l’aide d’une copie chez un autre hébergeur j’ai rétabli les droits en 755 sur les bons fichiers et tout est rentré apparemment dans l’ordre.
Voilà pour mon rapport de crash-test de cette Beta. Merci encore à tous.