Impossible de récupérer le fichier https://www.spip.net/spip_loader.api

Général
#1

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

  1. hébergeur en php 8.1
  2. 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 … ?)
  3. allow_url_fopen : on
  4. 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 »…
  5. ai demandé à mon hébergeur (LIKUID) si changement sur le serveur. Réponse de leur part : non.
  6. ai transféré le dernier spip loader via ftp en binaire.
  7. ai vidé le cache
  8. 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.

erreur spip_loader 6.0.2 ?
#2

Heu… à quel endroit tu as cette erreur ?

« Impossible de récupérer le fichier https://www.spip.net/spip_loader.api »

Dans spip_loader.php ? Dans SPIP ?

#3

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…

#4

Si ça répond à la question.

Le spip-loader devrait s’afficher correctement donc a priori, mais il ne parvient pas à récupérer le fichier indiqué.

Je sèche pour le moment sur le pourquoi…

#5

Est-ce que tu pourrais tester un petit script PHP (genre hhhh_test.php) qui ferait

<?php
$api = file_get_contents('https://www.spip.net/spip_loader.api');
var_dump($api);
$sl_version = file_get_contents('https://get.spip.net/version');
var_dump($sl_version);

Que tu enverrais à côté du fichier spip_loader en l’appelant dans l’URL mon_site.tld/hhhh_test.php pour voir ce que cela donne et nous dire ?

Merci :slight_smile:
PS: tu le supprimes dans la foulée :slight_smile:

#6

ok,
j’ai obtenu
bool(false) bool(false)

#7

C’est bizarre car ça répond comme si allow_url_fopen n’était pas activé.

Bon, cela dit on sait qu’on doit améliorer ce point (entre autres choses) sur le Loader.

#8

@HHHH tu devrais tester Spip Loader 6.1.0-beta :wink:

#9

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.

#10

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 ?

#11

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.

#12

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.

#13

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.

#14

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.

#15

Questions @HHHH sur le loader testé

  1. il s’est affiché correctement sur ton hébergement ?
  2. il n’indiquait plus la précédente erreur ( « Impossible de récupérer le fichier …spip_loader.api ») ?
  3. 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 ?

#16

Au plaisir ! :slight_smile:

#17

[quote=« marcimat, post:15, topic:167942 »]
Questions @HHHH sur le loader testé

  1. il s’est affiché correctement sur ton hébergement ? OUI c’était parfait
  2. 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
  3. 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.

Je vais vérifier les droits : bonne idée !

#18

Oui bon j’avais un peu les nerfs sur le moment. Mes excuses @JamesRezo pour la pique alors qu’en effet ça partait d’une démarche d’aide.

#19

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.