Spip loader illisible

Bonjour,
J’ai téléchargé spip_loader 6.1.1 (UTF local)
Je l’ai ouvert depuis mon ordinateur mais j’ai le message: contient des caracteres non valides.

Malgré tout je l’ai téléversé par le FTP intégré au FAI en mode binaire et il est rempli de caractères illisibles.
Que puis-je faire?
D’autre part il reste à la racine de mon site deux anciens fichiers spip_loader_list.json et un autre tradloader_fr.php. Faut-il les jeter?

Bonjour,

non on ne peut pas lire ce fichier en local, tu veux voir quoi dedans ?

Bonjour,

Je voudrais seulement seulement pouvoir changer de version de spip en utilisant le spip loader.

comme d’habitude.

Sur le serveur du site, j’ai jeté l’ancienne version du spip loader, téléversé la plus récente 6.1.1.

Et l’appel monsit.tld/spip_loader.php retourne une page blanche.

Sur le serveur, j’ai ouvert spip_loader. C’est du code en anglais (sur la version précédente, il y avait des commentaires en francais). De plus c’est mélangé avec des caractères japonais (mojibake). Je ne sais pas où renseigner les personnes habilitées à utiliser le spip_loader

J’ai en outre deux fichiersloader trad et loader list à garder ou à jeter avant de faire une nouvelle tentative?

···

Le 14/05/2023 à 03:36, Pierre KUHN via Discuter de SPIP a écrit :

Bonjour,

non on ne peut pas lire ce fichier en local, tu veux voir quoi dedans ?

Spip Loader est un fichier binaire maintenant (seuls les caractères du tout début du fichier sont lisibles — le «stub» de l’archive phar, le reste est compressé et illisible dans un éditeur de texte)

C’est plus ennuyant, cela indique une erreur côté PHP, qui doit certainement être loggée quelque part côté serveur, si tu peux accéder aux logs. Difficile d’en dire plus sans connaître l’erreur.
Quelle est la version de PHP utilisée ? La version de SPIP actuelle ?

Tu peux tenter d’activer le mode debug du loader, via un fichier de conf (mais il sera peut être chargé trop tard et n’aura peut être pas d’effet) : en ajoutant un fichier spip_loader_config.php avec

return [
    'debug' => true,
];

j’ai en outre deux fichiersloader trad et loader list

Tu peux les supprimer (des fichiers pour l’ancien loader)

Bonjour Matthieu et merci pout a reponse

···

Le 15/05/2023 à 02:38, Matthieu Marcillaud via Discuter de SPIP a écrit :

Mon FAI est japonais et dans l’ancienne version du spip_loader, le début du fichier était parfaitement lisible et en francais. Ici avec le 6.1.1, c’est lisible en grande partie mais certains caractères accentués ou autres sont remplacés par des kanjis et il n’y a plus de texte en francais. Il y a donc un problème avec ce fichier. De plus je ne vois pas où indiquer les administrateurs qui peuvent lancer le spip_loader. Il me reste un ancien bug, bien qu’administrateur, je dois renseigner un autre numéro d’administrateur.

PHP 7.4 CGI

Merci pour l’info. C’est fait.

Je viens de relire le manuel du FAI.

Il indique de changer de mot de passe pour la base de données *au dessus de PHP 7.1. Je viens de le faire. Ce qui a mis mon site en travaux. Une heure après c’est de nouveau visible sans l’habillage du squelette que j’utilise (Escal). Je vais donner un peu de temps au serveur pour qu’il remette tout ca en place.

Merci encore, je reviendrai poster le résultat.

[SPIP][Général] Spip loader illisible
Matthieu Marcillaud via Discuter de SPIP
15/05/2023, 02:38

Sujet :
De :
noreply@discuter.spip.net
Date :

Pour :
lisez@comet.ocn.ne.jp

Matthieu Marcillaud marcimat
Mai 14

Spip Loader est un fichier binaire maintenant (seuls les caractères du tout début du fichier sont lisibles — le «stub» de l’archive phar, le reste est compressé et illisible dans un éditeur de texte)

liberte:

Et l’appel monsit.tld/spip_loader.php retourne une page blanche.

C’est plus ennuyant, cela indique une erreur côté PHP, qui doit certainement être loggée quelque part côté serveur, si tu peux accéder aux logs. Difficile d’en dire plus sans connaître l’erreur.
Quelle est la version de PHP utilisée ? La version de SPIP actuelle ?

Tu peux tenter d’activer le mode debug du loader, via un fichier de conf (mais il sera peut être chargé trop tard et n’aura peut être pas d’effet) : en ajoutant un fichier spip_loader_config.php avec

return [
    'debug' => true,
];

j’ai en outre deux fichiersloader trad et loader list

Tu peux les supprimer (des fichiers pour l’ancien loader)


Voir le sujet ou répondre à ce courriel pour répondre.

Pour vous désabonner de ces courriels, cliquez ici.

L’hébergeur me répond *traduction automatique

PHP Fatal error : Uncaught PharException : manifest cannot be larger than 100 MB in phar « /home/users/1/main.jp-franc-parler/web/franc-parler.info/spip_loader.php » in /home/users/web/franc-parler.info/spip_loader.php : 19

Pour l’erreur ci-dessus, probablement 15 const AUTOLOADER =’phar : //spip_loader.phar/vendor/autoload.php’;
Il semble que la taille du fichier que vous essayez de lire est trop grande.

En outre, des erreurs similaires peuvent être affectées par l’effondrement de l’aménagement du site.

Et il me dit de me débrouiller…

Avant de le recontacter, pour demander la marche à suivre, quelqu’un aurait-il une idée pour retrouver au moins le site?

Rebonjour,

Puisque l’hébergeur me répond que spip_loader dépasse 100 mb et met le bazar, j’ai jeté le spip_loader. Sans effet pour le moment.

···

Le 15/05/2023 à 18:25, Eric Priou a écrit :

Bonjour Matthieu et merci pout a reponse

Le 15/05/2023 à 02:38, Matthieu Marcillaud via Discuter de SPIP a écrit :

[SPIP][Général] Spip loader illisible
Matthieu Marcillaud via Discuter de SPIP
15/05/2023, 02:38

Sujet :
De :
noreply@discuter.spip.net
Date :

Pour :
lisez@comet.ocn.ne.jp

Matthieu Marcillaud marcimat
Mai 14

Spip Loader est un fichier binaire maintenant (seuls les caractères du tout début du fichier sont lisibles — le «stub» de l’archive phar, le reste est compressé et illisible dans un éditeur de texte)

Mon FAI est japonais et dans l’ancienne version du spip_loader, le début du fichier était parfaitement lisible et en francais. Ici avec le 6.1.1, c’est lisible en grande partie mais certains caractères accentués ou autres sont remplacés par des kanjis et il n’y a plus de texte en francais. Il y a donc un problème avec ce fichier. De plus je ne vois pas où indiquer les administrateurs qui peuvent lancer le spip_loader. Il me reste un ancien bug, bien qu’administrateur, je dois renseigner un autre numéro d’administrateur.

liberte:

Et l’appel monsit.tld/spip_loader.php retourne une page blanche.

C’est plus ennuyant, cela indique une erreur côté PHP, qui doit certainement être loggée quelque part côté serveur, si tu peux accéder aux logs. Difficile d’en dire plus sans connaître l’erreur.
Quelle est la version de PHP utilisée ? La version de SPIP actuelle ?

PHP 7.4 CGI

Tu peux tenter d’activer le mode debug du loader, via un fichier de conf (mais il sera peut être chargé trop tard et n’aura peut être pas d’effet) : en ajoutant un fichier spip_loader_config.php avec

return [
    'debug' => true,
];

j’ai en outre deux fichiersloader trad et loader list

Tu peux les supprimer (des fichiers pour l’ancien loader)

Merci pour l’info. C’est fait.

Je viens de relire le manuel du FAI.

Il indique de changer de mot de passe pour la base de données *au dessus de PHP 7.1. Je viens de le faire. Ce qui a mis mon site en travaux. Une heure après c’est de nouveau visible sans l’habillage du squelette que j’utilise (Escal). Je vais donner un peu de temps au serveur pour qu’il remette tout ca en place.

Merci encore, je reviendrai poster le résultat.


Voir le sujet ou répondre à ce courriel pour répondre.

Pour vous désabonner de ces courriels, cliquez ici.

Le fichier fournit actuellement fait moins de 300Ko. Ton hébergeur t’a mal informé, à moins que lors de sa mise en place, tu l’aies considérablement modifié… ce dont je doute.

Une recherche rapide sur Internet avec « Uncaught PharException : manifest cannot be larger than » donne ce résultat : Uncaught PharException : manifest cannot be larger than at DuckDuckGo

Et les liens indiquent que le fichier uploadé a été « corrompu » ou modifié.

Rappel : depuis qu’il est distribué sous forme compressée, le loader n’est plus lisible, ni modifiable. Le problème que tu rencontres vient peut-être de là. As-tu modifié le fichier avant de le transférer sur ton hébergement ?

Merci pour ta reponse.

Sur mon ordinateur, en effet, il pèse 265 ko.
Dans mes souvenirs après téléchargement, je me suis retrouvé avec 1 fichier spip_loader-1 que j’ai ouvert pour vérifier que c’était bien 6.1.1. Je n’ai touché à rien à l’intérieur. J’ai juste renommé ce fichier spip_loader.php avant de le téléverser chez l’hébergeur. J’ai appelé monsite.tld/spip_loader.php qui a retourné une page blanche. J’ai ensuite changé le mot de passe de la BDD car ma version de PHP est 7.4 graphique, comme conseillé par l’hébergeur et depuis plus de site en ligne.

Donc on passe de « spip_loader illisible » à « j’ai changé le mot de passe de la base de donnée ». C’est plus vraiment le même problème . :wink:

Des gens pour aider @liberte ?

Remettre le bon mot de passe pour la bdd serait bien déjà non ?

l’hébergeur dit que c’est peut-être le problème du loader qui est trop lourd et qui cause le chamboulement du site.
J’ai fait le changement du mot de passe comme indiqué par l’hébergeur. Si je veux remettre l’ancien mot de passe, je dois renseigner le plus récent, ca risque de compliquer la situation actuelle. Je peux le faire mais d’abord, je vais recontacter l’hébergeur.

J’ai vu dans un autre post de RealIT qui dit que chez ovh les droits sont 755 .

Sur spip.net spip_loader fait 259 ko.
Téléchargé chez moi, il fait 265 ko.
Téléversé depuis chez moi vers l’hébergeur, il fait 264951 (Ko ?) et les droits deviennent 644.
Où est l’erreur?

264951 est la taille exacte en octets du loader 6.1.1

  • divisé par 1000 => 264,951 soit environ 265 millliers d’octets (ko)
  • divisé par 1024 => 258,7412109 soit environ 259 KiB

Voir Octet — Wikipédia

Merci James Rezo, je suis rassuré pour la taille.

J’ai trouvé quels sont les differents Droits des Fichiers et dossiers mais ca dépasse ma compréhension.

Puisque l’hébergeur dit que le fichier dépasse les 100 MB, il se peut que j’aie touché par mégarde au contenu du spip_loader. J’ai donc jeté ce fichier et refait un téléversement.
Le site est toujours sens dessus-dessous.

Y aurait-il un cache/dossier/fichier a vider depuis le serveur auquel j’ai accès directement?

J’ai changé les droits en 755 .
Nada.

Je doute que ce soit spip_loader qui soit responsable du fait que ton site est HS. spip_loader.php n’intervient plus après qu’il a fait son travail. Si tu as eu un problème pendant son exécution et qu’il a mal fait son travail alors, oui il faut le relancer…
Il y a une url où on peut voir le souci ?

Bonjour,

Oui moi aussi je pense que l’hébergeur a trouvé un bouc émissaire.

Voici l’url:

www.franc-parler.jp

Le 18/05/2023 à 01:13, Jack31 via Discuter de SPIP a écrit :

Je doute que ce soit spip_loader qui soit responsable du fait que ton
site est HS. spip_loader.php n’intervient plus après qu’il a fait son
travail. Si tu as eu un problème pendant son exécution et qu’il a mal
fait son travail alors, oui il faut le relancer…
Il y a une url où on peut voir le souci ?

Alors on voit que tu es toujours en 3.2.14, il faudrait urgemment passer en 3.2.19 avant de penser changer de version.
Il faudrait déjà vérifier que tu n’as as été hacké (il y a d’autres posts récents sur le sujet)
Estce que tu as accès la partie privée ?
Si tu lances spip_loader il devrait te proposer de mettre à jour en 3.2.19. Est-ce que spip_loader se lance ?
Aussi, quelle est ta version de php? SPIP 3.2.19 fonctionne jusqu’en php 7.4 mais pas les versions inférieures ce qui peut potentiellement générer ton problème.
Tu as beaucoup de plugins, si ça ne fonctionne pas il faudrait désactiver tous les plugins par exemple en renommant le dossier plugins en plugins-truc. Puis (une fois maj) les réactiver un à un (te sont-ils tous utiles ?)
On est loin d’un problème de spip_loader semble-t-il…
Bon courage,
Jacques

1 « J'aime »

Le 18/05/2023 à 14:26, Jack31 via Discuter de SPIP a écrit :

Alors on voit que tu es toujours en 3.2.14, il faudrait urgemment
passer en 3.2.19 avant de penser changer de version.
Je voudrais procéder ainsi.

Il faudrait déjà vérifier que tu n’as as été hacké (il y a d’autres
posts récents sur le sujet)
Estce que tu as accès la partie privée ?

Non pas d’accès depuis Spip. Par contre je peux aller dans les
fichiers par ftp.

Je vais lire posément les autres posts.

Si tu lances spip_loader il devrait te proposer de mettre à jour en
3.2.19. Est-ce que spip_loader se lance ?

Non spip_loader ne se lance pas.

Aussi, quelle est ta version de php? SPIP 3.2.19 fonctionne jusqu’en
php 7.4 mais pas les versions inférieures ce qui peut potentiellement
générer ton problème.

Php 7.4 donc compatible avec Spip 3.2

Tu as beaucoup de plugins, si ça ne fonctionne pas il faudrait
désactiver tous les plugins par exemple en renommant le dossier
plugins en plugins-truc. Puis (une fois maj) les réactiver un à un (te
sont-ils tous utiles ?)
Bonne question. Je vais faire le ménage et faire selon on conseil
On est loin d’un problème de spip_loader semble-t-il…
Bon courage,
Jacques

Merci pour tes conseils et encouragements (restons positifs, j’apprends
beaucoup).

À propos, je viens de vérifier que la DB est en version 5.1 *de
quoi??alors que mon autre site est 5.4.

J’y pense il y a longtemps lorsque je suis passé de spip3.1 à 3.2, j‘ai
eu un problème d’autorisation, un bug qui fait que je devais donner en
tant qu’administrateur un autre numéro. Je dois fouiller dans le forum
de spip car d’autres personnes avaient eu le même problème.

Bon, j’ai du pain sur la planche.

Merci encore.

J’ai retrouvé le lien:

https://forum.spip.net/spip.php?page=recherche&recherche=Auteur+dupliqué+avec+ID+-1+%3A+bug+%3F

Maintenant lorsque je j’appelle www.franc-parler.jp/spip_loader.php, j’obtiens un accès interdit.

Dans les fichiers du serveur où puis-je trouver le numéro de l’autre administrateur. ou bien comment puis-je savoir maintenant sous quel nom d’administrateur je suis loggé?
J’ai bien créé un fichier spip_loader_config.php *mais codé automatiquement en ASCII, pas réussi en utf
avec <?php

return [
‹ authorized.users › => [1, -1],
]

mais ca ne marche pas.