mise à jour d’un site SPIP 3.1 vers un SPIP 4.4 avec les copies d’un site d’une cliente, dans une zone de test de mon serveur, située dans un sous-dossier « /web/websites/ ».
serveur apache, ubuntu 22.04, php 8.1.1, chez OVH.
Mon problème :
Une fois la mise à jour effectuée, iel m’est par défaut renseigné la disponibilité du dépôt « SPIP-Zone-Plugins » dans l’espace admin, mais :
quand je cherche des plugins en renseignant leur noms, très peu apparaissent en résultats, et jamais le plugin recherché. J’ai par exemple essayé de récupérer le plugin « Menus » présent sur le SPIP 3.1 pour le 4.4 sans succès. J’ai l’impression donc que le contenu du dépôt ne m’est pas accessible.
si je supprime le dépôt pour tenter de le réinstaller, j’ai l’erreur suivante qui apparait « L’adresse « https://plugins.spip.net/depots/principal.xml » est incorrecte », et ce en renseignant correctement l’adresse du SPIP-Zone-Plugins, soit « https://plugins.spip.net/depots/principal.xml » et mon mot de passe.
Aussi, quand j’installe un SPIP 4.4 vierge dans le même sous-dossier de mon serveur, je peux installer le dépôt SPIP-Zone-Plugins sans problèmes et faire correctement mes recherches de plugins pour installation.
Quelqu’un.e a-t-iel une idée d’où peut venir le problème?
Merci par avance pour la considération de mon problème
Je reproduis sur une installation neuve, j’ai un message d’erreur « Le format csl n’est pas supporté par le téléporteur » lorsque je tente d’ajouter le dépôt https://plugins.spip.net/depots/principal.xml pour la 1ère fois.
Erreur d’analyse XML : données incompréhensibles après l’élément de document
Emplacement : https://files.spip.net/spip-zone/archives.xml
Numéro de ligne 8, Colonne 1 :
<archives>
^
Par reproduction, parlez-vous bien tous les deux de faire une maj de 3.1 vers 4.4?
b_b, du fait de la non validité du xml du repo, cela impose-t-iel de passer par une méthode alternative pour bénéficier des contenu des dépôts et en installer sur la site?
Non pas du tout, SVP le gestionnaire de plugins s’accommode sans problème du format de ce fichier
Je te conseille d’activer les logs verbeux cf Les aides au débuggage de squelettes - SPIP et de regarder dans tmp/log/distant.log ce qui se passe quand tu tentes d’ajouter le dépôt.
Je ne reproduis pas à partir d’une installation neuve en SPIP 4.4
C’est moins simple de tester depuis une migration 3.1 → 4.4 cela étant dit.
Est-ce que tu vois le même message « Le format csl n’est pas supporté par le téléporteur » dans les logs de SPIP (tmp/log/spip.log possiblement) ?
Cela étant dit, indépendamment de ton problème je vois deux choses
il enregistre le fichier dans IMG/distant/csl/principalxml.xxx.csl (je me suis souvent demandé pourquoi csl/, qui n’est pas le bon type, sans chercher particulièrement). Je me demande si cela ne vient pas de distant_trouver_extension_selon_headers() qui à un moment prendrait la première entrée application/xml de spip_types_documents (qui correspond à csl). Il faudrait pousser un peu l’analyse de notre côté.
Je vois qu’il me crée plusieurs fichiers, notamment le XML de 9Mo et celui thin d’1Mo… ce qui pour le coup, si on espérait une amélioration de téléchargement avec nos améliorations récentes de SVP, n’est pas démontrée (je pense que c’est bon côté mémoire cela dit car il ne lit peut être que le plus léger quand même)
Je suis développeur php, mais débutant sur SPIP, donc je ne saisi pas la profondeur des deux points que tu abordes désolé
Je vais comparer un peu les dossier /IMG, celui copié du site de ma cliente lors de la mise à jour vers 4.4, et celui crée lors d’une installation 4.4 vierge.
Je précise que la mise à jour est réalisée avec spip_loader.php, et que le seul dossier qui reste sur le serveur au moment de l’installation de 4.4 est le dossier /IMG. Peut-être que le dossier garde des informations de la version 3.1 incompatible avec la 4.4?
Aussi je n’ai pas réalisé de vidage du cache avant de faire mon export sql de la base de donnée de ma cliente avec phpmyadmin. Peut-être est-ce une partie du problème? Je vois que les fichiers pointés dans les logs sont des fichiers .tmp. Cela peut-iel avoir un rapport avec la gestion du cache?
J’ai eu le même problème après avoir mis à jour pas à pas mon site
3.2.19 en 4.4.3. Je me suis retrouvé avec des plugins obsolètes bien
sûr et des difficultés à pouvoir atteindre les dépôts. J’aurai dû noter
la manière dont j’ai procédé; mais j’ai dû essayer de réinstaller mes
plugins par téléchargement par filezilla puis et en mettant l’adresse
xml des dépôts par copier collé ça a marché . Aussi il ne me restait
plus qu’à mettre à jour sauf les deux qui n’existaient plus en version
4.4 .
J’ai aussi trouvé un plugin « Modèles de documents SPIP 3.2 1.1.0 » que je
n’utilise plus, massicot étant à jour.
Ok, autre chose : lorsque je réalise une installation vierge de SPIP 4.4 et que je me connecte à la base de données importée de ma cliente à partir de cette version, je n’ai pas de problème d’installation de dépôt et j’ai accès aux plugins disponibles sur le dépôt sans problèmes.
Ça rabat le problème donc vers le dossier /IMG copié du site de ma cliente.
De mon côté j’aimerai éviter de me rabattre sur l’installation par FTP des plugins, ce qui fonctionne d’après ce que j’ai pu constater.
Je souhaite comprendre le problème autant parce que je suis un peu obsessionnel sur la résolution des bugs, déformation de développeur :), que pour essayer d’apporter des informations utiles pour la communauté SPIP si possible.
je ne saisi pas la profondeur des deux points que tu abordes désolé
Ces deux points concernent d’autres problèmes que le tiens du coup !
Ceci étant dit, tu peux certainement supprimer IMG/distant/csl/principal* voire tout le répertoire IMG/distant/csl car il ne contient certainement que ces éléments, et voir ce qui se recrée dedans ensuite.
Je n’ai pas vraiment d’idée de ce qui se passe réellement sur ton installation. Logiquement tu peux aussi relancer spip_loader.php dessus plusieurs fois : s’il trouve des incohérences il devrait copier des fichiers dans un répertoire ‹ obsolète › avec une date (je n’ai plus le nom exacte en tête).
Je viens de passer le dossier /IMG/distant/csl/ en chmod 777 et l’installation du dépôt a réussi, merci b_b pour ta suggestion J’ai également accès aux plugins recherchés, qui s’installent sans problèmes donc tout roule merci
Cela dit un chmod 777 n’est-iel pas trop laxiste en terme de sécurité?
Si 777 est trop laxiste, mais cela sous-entends un problème de user/group derrière qui n’est pas toujours facile à identifier en local en fonction des outils techniques utilisés . Tu n’as pas besoin de 777 si le group des fichiers est le même que celui utilisé pour ton service web (apache, nginx) ; j’imagine que tu es sous linux ou macos, parfois des chown peuvent aider ; parfois cela vient de la configuration de l’outil web utilisé (lamp, mamp, ddev, docker ou autres…)
