[spip-dev] Contrib et fichiers des plugins

Holla,

le débardeur avait ajouté plein de zip qui perturbaient le script de synchronisation entre plugins.spip.net et contrib.

En attendant une refont de la maquette filaire de contrib, j'ai discuté avec Eric, et nous avons décidé de mettre en œuvre un quickfix pour retrouver correctement les zip des plugins.

J'ai essayé de faire ce quickfix en donnant un résultat qui soit visuellement aussi proche que ce que nous avions avant.

Concrètement :

- suppression du script de synchro, on utilise directement les infos en base (préfix sur les rubriques + tables PLUGINS / PAQUETS), j'ai dépublié par conséquent l'article que j'avais écrit il y a un an.
- je sépare deux types de documents :
- les plugins proprement dits trouvés via SVP:
- actualisé automatiquement via SVP
- ne sont plus des pièces jointes
- on n'a pas l'info sur la taille au niveau de svp / débardeur, du coup on l'affiche plus, on va pas s'amuser à faire des requêtes juste pour ça (mais peut être une fonction à ajouter dans le futur=
- les autres documents joints (par exemple si une personne met une doc complémentaire, la présentation ne change pas
- tous les docs distants dépendant de files.spip.net/org sont automatiquement masqués. En fait on pourrait carrément les supprimer en base, vu que ce sont les documents ajoutés auparavent par le synchronisateur
- les mots clés sur les versions de SPIP ne sont *a priori* plus utiles, à part pour les articles qui ne concernent pas des plugins. On les garde donc, mais sauf exception on n'aura plus à se préoccuper de les poser.
- il faudra cependant comment voir pour lister tout les articles compatibles avec une certaine version des plugins, sachant que :
- pour les plugins, ce sont des infos dans les tables PAQUETS/PLUGINS
- pour les articles non plugins, une minorité, l'info se trouve en mot clé
- on n'utilise plus la syndication pour afficher le lien vers le code/la dernière mise à jour, mais uniquement les infos fournies par le débardeur
- on pourrait désabonner tous les flux de commit pour économiser des ressources
- pour la future version vraiment refondue fusion plugins/contrib, sans doute devrait-on remettre, mais en se basant sur l'API de gitea, et en voyant comment gérer le cache
- une remarque en passant : idéalement on devrait avoir via SVP/débardeur/archives.xml l'info sur l'autodoc des plugins, plutôt que d'avoir un champ spécial dans contrib
- le label "utilisé par contrib" est calculé automatiquement, ce n'est plus un mot clé :
- je ne sais pas si c'est utile de faire une page qui liste tous ces plugins ? à voir
- le logo est le vieux png, si des gens veulent en faire un svg, allez y :slight_smile:

Enfin j'ai profité pour améliorer la dispersion des chaines de langues, en mettant tout ce qui était dans local dans galactic_contrib + en branchant galactic_contrib sur salvatore.

Bref, on n'est pas encore sur la fusion plugins/contrib, mais on a déjà des choses plus cohérentes niveau contrib.

Amicalement

Maïeul

Super, merci !

Hop,

En attendant une refont de la maquette filaire de contrib, j'ai discuté avec Eric, et nous avons décidé de mettre en œuvre un quickfix pour retrouver correctement les zip des plugins.

Merci :slight_smile:

Quelques remarques et commentaires, désolé par avance si vous pensez qu'il faut poster sur un autre canal.

- on n'a pas l'info sur la taille au niveau de svp / débardeur, du coup on l'affiche plus, on va pas s'amuser à faire des requêtes juste pour ça (mais peut être une fonction à ajouter dans le futur=

Amha ça n'est pas vital, on peut très bien s'en passer ça permet d'alléger le contenu des pages.

- tous les docs distants dépendant de files.spip.net/org sont automatiquement masqués. En fait on pourrait carrément les supprimer en base, vu que ce sont les documents ajoutés auparavent par le synchronisateur

Gogogo, mode ménage de printemps, ça fera ça de moins dans la base :slight_smile:

- les mots clés sur les versions de SPIP ne sont *a priori* plus utiles, à part pour les articles qui ne concernent pas des plugins. On les garde donc, mais sauf exception on n'aura plus à se préoccuper de les poser.

Pas certain de parler de la même chose, mais j'ai un doute sur le résultat, exemple avec GIS 4 qui indique être compatible de SPIP 1.9 à SPIP 3.2 :

Je pense que ça vient du fait que dans aside/article.html · master · spip-galaxie / contrib.spip.net · GitLab tu boucles sur le plugin et non le paquet. À froid je n'ai pas d'idée concrète pour améliorer ça, mais peut-être faut il chercher directement dans les paquets en fonction de l'url de doc (qui est celle de l'article en cours), sauf que très souvent les paquets référencent l'adresse en mode lien court, etc.

- on n'utilise plus la syndication pour afficher le lien vers le code/la dernière mise à jour, mais uniquement les infos fournies par le débardeur

Top !

- on pourrait désabonner tous les flux de commit pour économiser des ressources

Idem que pour ma seconde remarque, délestons-nous des infos qui ne sont plus utiles, ça permettra économiser de l'espace en base et de la ressource.

- pour la future version vraiment refondue fusion plugins/contrib, sans doute devrait-on remettre, mais en se basant sur l'API de gitea, et en voyant comment gérer le cache

Amha osef, l'info de dernière mise à jour est présente, le lien vers la code source aussi et il permet de consulter les logs de commits, ça fait très bien le job.

- je ne sais pas si c'est utile de faire une page qui liste tous ces plugins ? à voir

Non.

Enfin j'ai profité pour améliorer la dispersion des chaines de langues, en mettant tout ce qui était dans local dans galactic_contrib + en branchant galactic_contrib sur salvatore.

Todobien :slight_smile:

Hop,

En attendant une refont de la maquette filaire de contrib, j'ai discuté avec Eric, et nous avons décidé de mettre en œuvre un quickfix pour retrouver correctement les zip des plugins.

Merci :slight_smile:

Quelques remarques et commentaires, désolé par avance si vous pensez qu'il faut poster sur un autre canal.

- on n'a pas l'info sur la taille au niveau de svp / débardeur, du coup on l'affiche plus, on va pas s'amuser à faire des requêtes juste pour ça (mais peut être une fonction à ajouter dans le futur=

Amha ça n'est pas vital, on peut très bien s'en passer ça permet d'alléger le contenu des pages.

je suis assez d'accord

- tous les docs distants dépendant de files.spip.net/org sont automatiquement masqués. En fait on pourrait carrément les supprimer en base, vu que ce sont les documents ajoutés auparavent par le synchronisateur

Gogogo, mode ménage de printemps, ça fera ça de moins dans la base :slight_smile:

oui mais j'ai pas l'accès pour ca :slight_smile:
enfin je pourrais m'amuser à le faire à la main, mais des gens qui ont un accès sql pourraient le faire en deux couprs de cuillère à pot

- les mots clés sur les versions de SPIP ne sont *a priori* plus utiles, à part pour les articles qui ne concernent pas des plugins. On les garde donc, mais sauf exception on n'aura plus à se préoccuper de les poser.

Pas certain de parler de la même chose, mais j'ai un doute sur le résultat, exemple avec GIS 4 qui indique être compatible de SPIP 1.9 à SPIP 3.2 :

GIS 4 - SPIP-Contrib

Je pense que ça vient du fait que dans aside/article.html · master · spip-galaxie / contrib.spip.net · GitLab tu boucles sur le plugin et non le paquet. À froid je n'ai pas d'idée concrète pour améliorer ça, mais peut-être faut il chercher directement dans les paquets en fonction de l'url de doc (qui est celle de l'article en cours), sauf que très souvent les paquets référencent l'adresse en mode lien court, etc.

a oui, j'avais pas prévu le cas des articles qui recensent une version particulière du plugin. COmme tu peux voir, l'article a beau s'appeler Gis 4, il recense toutes les versions.

C'était pas le cas avant avec le synchronisateur, qui effectivement s'appuyait sur les urls (y compris en gérant les liens courts etc.).

Je sais pas quoi en penser en fait :
- on pourait se rebaser sur documentation, mais je suis pas sur que ce soit une bonne idée :
   - à mon avis le lien de doc dans svp devrait être déterminer automatiquement à partir du référentiel de plugins qu'Eric veut construire, et plus dépendre du paquet
   - si on modifie la maquette, bien possible qu'en fait on présente autrement les choses, en disant "versions du plugins" et pas "doc joint à cet article", du coup peut être attendre la nouvelle maquette
- si on décide de bien séparer la liste des fichiers selon l'article où l'on est actuellement, faudrait peut être repenser le lien

DOnc je dirais : pour ces cas particulier avec des articles correspondant à une version particulière du plugin, attendons le travail des maquetistes. Là ca fait des choses un peu bizarre, mais comme on l'info sur la compat pour chaque version du plugin, c'est pas non plus hyper grave. Si on lit l'article Gis 4 , on sait qu'on veut la version 4 de Gis, et donc on peut voir les compatibilités.

- on n'utilise plus la syndication pour afficher le lien vers le code/la dernière mise à jour, mais uniquement les infos fournies par le débardeur

Top !

- on pourrait désabonner tous les flux de commit pour économiser des ressources

Idem que pour ma seconde remarque, délestons-nous des infos qui ne sont plus utiles, ça permettra économiser de l'espace en base et de la ressource.

même réponse qu'avant : oui mais je peux pas le faire

- pour la future version vraiment refondue fusion plugins/contrib, sans doute devrait-on remettre, mais en se basant sur l'API de gitea, et en voyant comment gérer le cache

Amha osef, l'info de dernière mise à jour est présente, le lien vers la code source aussi et il permet de consulter les logs de commits, ça fait très bien le job.

oui je pense aussi, mais attendons les maquetistes :slight_smile:

Tout à fait d'accord avec ce point car le lien on l'a, chaque paquet.xml référence bien l'article le plus pertinent pour sa version précise, donc on doit être capable d'afficher les infos de cette branche en question, et non du plugin général.

je ferais un quickfix ce soir ou demain

Yo,

oui mais non. Le souci c'est que tu peux avoir des docs par version.
Et c'est le paquet.xml de chaque version qui précise la bonne.
Et du coup tu peux pas te contenter de prendre la version la plus à jour.

Il faut que pour l'article "doc de la version 2",on ait uniquement la version 2
et pour l'article "doc de la version 4" on ait unqiuement la version 4

c'était le cas avant avec le synchronisateur, je rétablis cela

bon c'est fait

et demain Eric affichera uniquement les version X majeures, en attendant la refonte totale.

evidememt comme le dit eric, et comme je le met dans mon message de commit, je suis pas convaincu que la manière dont on gère la doc par paquet.xml soit la bonne solution.

Mais ce sertait un tout autre chantier

Hello,

A la limite, on pourrait « enrichir » l’affichage du zip lié au lien
de doc sur les articles concernés pour bien pointer la correspondance.
J’attends vos retours pour commiter la modification pour les X.
++
Eric

cette option là me parait la meilleure.

et sinon gogocommit