Re: [spip-dev] [Spip-zone-commit] [cambio] fix lien credit

2021-05-08 Par sujet RastaPopoulos
Le 08/05/2021 à 20:01, Manu a écrit :
> Comme c'est assez fréquemment écrit comme ça ("[" placé en fin de ligne), 
> j'imagine qu'il y a bien une raison ? Quelqu'un·e pour éclairer ma lanterne ?

Car sinon ça fait des sauts de ligne dans le résultat final même quand telle 
balise ne renvoie rien.

Parfois c'est pas immensément grave (juste HTML moins beau à la fin), mais 
parfois c'est impératif, de ne pas avoir ni saut de ligne ou même espace à des 
endroits où on n'en veut pas, ça peut casser des affichages, CSS ou autre, si 
des éléments sont séparés par des espaces alors qu'on voudrait que les blocs 
html soient collés.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Intervalles de compat et fonctions associées

2021-05-08 Par sujet RastaPopoulos
Le 08/05/2021 à 15:11, Eric Lupinacci a écrit :
> Des avis ou des idées ?

Sur les utilisations réelles je ne sais pas, mais sur la logique c'est un peu 
plus compliqué non ? L'étoile devrait représenter le max possible 999 si c'est 
la borne sup d'une comparaison MAIS devrait représenter 0 c'est si la borne 
inférieure, non ?

3.0.* < 3.0.7  ça devrait faire 3.0.0 < 3.0.7 ?

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet RastaPopoulos
Le 07/05/2021 à 20:06, tcharlss a écrit :
> Et donc oui, c'est ce genre de cas auxquels on ne pense pas forcément dès le 
> début, mais on tombe souvent sur ces exceptions après coup.

Je rajoute une bille sur la simplification :)

Là on parle d'une recommandation pour SPIP 4. Grosse version, gros changements.

Ça ne me parait pas *du tout* déconnant, et en plus c'est vraiment un 
"incompatibilité" super minime, de dire aux gens : bah oui à partir de 
maintenant arrêtez de laisser votre bordel à la racine et rangez votre chambre, 
merde.
On va pas s'empêcher d'avoir des noms simples et bien rangés, parce que 3 
pauvres gens laissent leurs chaussettes sales.

Donc pour moi, même prefixe.svg suffit en théorie.

Aux gens qui font des squelettes en bordel de mettre leurs images dans… 
/images. Suffit de l'écrire clairement dans la release.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [cartes] Initialisation du plugin Cartes. Permet de définir des (...) => nom trop générique ?

2021-05-07 Par sujet RastaPopoulos
Le 07/05/2021 à 17:04, Eric Lupinacci a écrit :
> Oui je vois plus ou moins, la différence c'est que vous ne voulez pas être 
> lié à un territoire et à son contour mais à une quelconque forme GIS.
> Donc c'est exact que c'est moins restrictif.
> D'ailleurs vous pourriez très bien vous brancher aussi sur un territoire qui 
> à déjà son contour...

Ah mais tout à fait, j'y pensais dans le lot :)
J'ai commencé une architecture, mais j'ai pas encore tout bien calé, l'idée 
c'était déjà de pouvoir partir rapidement sur les options connues de GIS (qui 
comprennent flux de points et contours en fichiers joints), pour avoir un truc 
utilisable rapidement, mais en ayant bien en tête de pouvoir aussi ajouter 
d'autres sources possibles si stockés ailleurs (les contours de territoire sont 
stockés dans quoi ?)

> Pas de souci à laisser le préfixe cartes et l'objet carte.
> Je vais passer le préfixe à "carter" (j'aime les cacahuètes) et la table sera 
> renommée territoires_cartes.
> Je prends le temps de faire ça la semaine prochaine.

Merci :)

Huhu "carter" ? Ça peut tout simplement être "territoires_cartes" aussi pour le 
préfixe hein :) 
=> Raccord avec l'objet + ça permet tout de suite de voir (y compris dans les 
projets Git) que c'est un sous-projet de Territoires.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [cartes] Initialisation du plugin Cartes. Permet de définir des (...) => nom trop générique ?

2021-05-07 Par sujet RastaPopoulos
Le 18/04/2021 à 17:39, Eric Lupinacci a écrit :
> Initialisation du plugin Cartes.
> Permet de définir des ensemble de Territoires affichables dans une carte GIS

Yo, je reviens sur cette ajout d'il y a quelques semaines,

il me semble que le nom utilisé ici est vraiment trop générique par rapport à 
l'objet du plugin : ne s'occupe que des objets Territoires du plugin éponyme. 
C'est un sous-plugin (ou connexe) *de Territoires uniquement* quoi.

On avait discuté ya 1 ou 2 mois avec Maieul d'un plugin Cartes vraiment 
générique dans le sens où là il s'agirait d'un plugin qui ajouterait un objet 
"Cartes", permettant essentiellement d'englober des configs de cartes dans un 
objet stocké en base, donc réutilisable facilement, afin de pouvoir ensuite 
l'afficher plusieurs fois à tout moment, c'est-à-dire
1) sans retaper à chaque fois tous les params nécessaires du modèle de GIS (que 
ce soit dans un contenu ou dans un squelette)
2) avec une interface du coup !

Non-exhaustivement, pouvoir configurer au moins :
- le titre et une description
- les params d'affichage (zoom, fonds, cluster ou pas, etc)
- quel "flux de points" insérer (param objet)
- quel(s) tracés ajouter en plus (geojson)
- etc

Là l'idée c'est que quand je clique sur "Créer une nouvelle carte", je 
configure vraiment n'importe quelle carte, avec *n'importe quelles sources de 
données*.

-- 
RastaPopoulos

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip bonux

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 17:46, tofulm a écrit :
> y a t'il encore un intérêt a garder la fonction export_csv dans bonux ? Cela 
> oblige a reporter les modifs du corps dans bonux.

Tu veux parler de ce ticket ?
https://git.spip.net/spip-contrib-extensions/spip-bonux/issues/1

Mais apparemment c'est pas important :)

Et donc il semblerait ancré que l'idée soit d'avoir un plugin Bonux à vie, à 
l'infini, jusqu'à la mort des internets.
(Ou pas si on se met à releaser le noyau plus souvent ?)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [spip-bonux] [ui] logo on laisse tomber la lessive pour une cerise (...)

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 13:45, Eric Lupinacci a écrit :
> Oui, parce que sémantiquement ce n'est pas la même.

Ok moi ça me va, et c'est pas gênant vu qu'on parle de logo qui font 3ko quoi…

Et vu que ça marche déjà aussi en 3.2, il faudrait donc noter que désormais la 
recommandation c'est tout simplement : "une image du nom du préfixe à la 
racine", ni plus ni moins.

Plugin Patates => patates.svg à la racine

Simple et de bon goût.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [spip-bonux] [ui] logo on laisse tomber la lessive pour une cerise (...)

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 13:20, Matthieu Marcillaud a écrit :
> Ça marche la compat png-svg (3.2 - 4.0) si c'est pas dans prive/theme/ ?

Pour info même en 3.2 dans SVP, les logos *de plugin* en SVG marchent 
parfaitement, ils sont insérés dans un  ça marche pour n'importe quel type.
Cf 
https://git.spip.net/spip-contrib-extensions/dons/src/branch/master/paquet.xml#L7
que je vois bien en 3.2 comme il faut.

Moi je suis partisan de même pas mettre de XX dans ce cas : une image à la 
racine exactement du même nom que le préfixe du plugin.

Là où je me pose plus la question c'est : si l'image est *aussi* déjà utilisé 
dans l'interface pour des liens/boutons, dans ce cas elle va aussi être dans 
prive/theme : est-ce qu'il faut pas prévoir de quand même pouvoir déclarer 
cette image dans le XML dans le futur, histoire de réutiliser une existante, 
sans doublonner ? Sinon on va devoir mettre une même image à la fois à la 
racine et dans prive/theme si on l'utilise aussi ailleurs.

Mais pour les cas simple ou les cas où l'image du plugin n'est pas l'image d'un 
des objets ajoutés par le plugin, alors : une image à la racine *pile* du nom 
du préfixe.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Ô mega ! c’est SPIP 4.0 alpha

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 11:50, Pierre-Jean Colliot a écrit :
> dans les emplacements dédiés aux logos (à gauche de la page de vue d'un objet 
> notamment).

Bé c'est déjà ce que fait le plugin Rôles de documents :)
Il ne change pas les habitudes des gens, le bloc est toujours au même endroit, 
même si derrière ça met le rôle sur un document normal.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 11:37, Cerdic a écrit :
> La démarche c’est pas que les css par défaut des formulaires doivent styler 
> tous les cas inimaginables, mais bien uniquement les cas de la charte et 
> ensuite les cas particuliers sont stylés comme des cas particuliers 
> (formulaire par formulaire)

Oui mais le cas oui/non dans un même choix… c'est un cas du core ! :)

Du coup je suppute que tcharlss pensait bien faire en se disant : si c'est 
utilisé par le core, c'est que ça doit être prévu dans les styles.

Mais on peut bien sûr parfaitement décider que c'est le core qui faisait 
n'importe quoi et prenait des libertés, et donc : corriger le core.

C'est ma préférence aussi, ce qui évite d'ajouter un concept rare en plus de 
groupe de choix, on corrige les forms de contenus d'articles, etc qui ont des 
oui/non dans la même ligne. D'ailleurs tcharlss disait que ça serait 
possiblement bien de les corriger pour des cases à cocher, mieux que des 
oui/non généralement, mais bon faut voir l'implication en terme de chaines.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Ô mega ! c’est SPIP 4.0 alpha

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 11:34, pierre laszczak a écrit :
> Serait-il possible de clarifier la situation des rôles dans spip4 ?

Ya rien de différent à 3.2 donc depuis des années déjà pareil hein. Rien de 
nouveau sur les Rôles en SPIP 4 pour l'instant. :)

- Le noyau fournit une API PHP.
- Le plugin Rôles fournit des éléments d'interface. (Et cette partie pourrait 
intégrer le noyau aussi un jour, ça serait mieux que séparé il me semble)
- Des plugins nécessitent Rôles pour ajouter cette interface à des objets 
existants.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Ô mega ! c’est SPIP 4.0 alpha

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 11:30, Pierre-Jean Colliot a écrit :
> Si c'est le cas, est-il assez prudent d'anticiper ce schéma en exploitant 
> directement un rôle "logo" depuis Rôle de documents ?

Je ne saisis pas trop le sens final de cette question :)

Ça fait 6 ans qu'il existe ce plugin, et il a été conçu justement comme 
remplaçant des anciens logos, afin d'utiliser les vrais documents (et vraiment 
partagés dans la médiathèque), et d'en faire une expérimentation grandeur 
nature pour la suite de SPIP.

Alors si ton besoin c'est que tous les docs soient au même endroit, et que pour 
un logo tu puisses bien réutiliser un doc existant (et possiblement plusieurs 
fois le même) bah oui c'est ce plugin qu'il faut utiliser.

Après ça peut encore être amélioré, question ergonomie notamment, mais le but 
d'origine c'est bien de partir de cette base, pour le futur du plugin Médias, 
pas depuis 0.

En attendant ça marche (très bien) depuis 6 ans, faut juste arriver à le faire 
re-fonctionner en SPIP 4, surtout que c'est un des rares plugins manquants, la 
majorité des autres fonctionnent bien déjà. :(

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Ô mega ! c’est SPIP 4.0 alpha

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 11:06, pierre laszczak a écrit :
> On reste sur le plugin rôle_document?

Oui mais il n'est pour l'instant pas fonctionnel en SPIP 4 (arg), on a commencé 
à regarder mais ya pas que du trivial :(

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Ô mega ! c’est SPIP 4.0 alpha

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 10:58, pierre laszczak a écrit :
> Il y a bien une colonne role  sur la table documents_liens avec avec un role 
> document.

Non, c'est le plugin Rôles de documents qui fait ça uniquement

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 09:08, Jean-Christophe Villeneuve a écrit :
> Merci pour ces explications, je vais essayer de corriger mon code.
> Où peut-on trouver cette fameuse charte des forms dans spip ?

Yop c'est dans le plugin "Dev" (fourni par l'équipe noyau, dans l'orga /spip

Quand tu l'installes tu as alors accès à des pages de charte de l'admin.

Mais sinon sur le site spip.net il y a une page sur la normalisation des 
formulaires. Cependant elle n'est pas très à jour… :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet RastaPopoulos
Le 05/05/2021 à 23:20, tcharlss a écrit :
> Ça rentre dans la définition ? Charte, pas charte ?

Pour moi non, on appelle un choix un choix :p

Après entre les .choix on peut mettre des sortes d'intertitres ou des 
explications pourquoi pas mais pas 50 radios dans un même choix

Bon sachant que là en plus dans le lien d'escal je sais pas si t'as vu mais 
tout est DANS un div.explication en plus ! Là ça m'a l'air vraiment du grand 
n'importe quoi par rapport à la charte des forms :) 
Ya même des .choix dans le .choix qui entoure tout…

.editer (encore en ul li en plus alors que ça fait des années que c'est plus 
des li)
  .explication
texte intertitre à l'extérieur du .choix
span.choix
  input label moult fois
  texte intertitre à l'intérieur
  input label moult
  texte intertitre
  .choix etc

Bref c'est grave WTF là :)


Là ça devrait être des fieldsets contenant des radios : c'est la norme 
consacrée pour être accessibles pour les radios désormais.

Et après des .editer n'ayant rien à voir pour les input text de largeur etc, 
qui n'ont aucun rapport avec les .choix radio.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet RastaPopoulos
Le 05/05/2021 à 22:53, tcharlss a écrit :
> En tout ce qui est permis ou pas dans ces .choix est clairement à documenter 
> dans la charte.

De ce que j'ai compris de l'explication justement ya aucune règle pour 
l'intérieur des .choix, à part cette seule règle : c'est un seul choix dedans. 
Mais ensuite on peut mettre n'importe quoi, input, explication, hidden, image 
que sais-je

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] test spip4 alpha - plugin necessite

2021-05-05 Par sujet RastaPopoulos
Le 05/05/2021 à 16:49, Jean-Christophe Villeneuve a écrit :
> Ok je peux l'installer mais ça fait des manips en plus.
> Est-ce voulu ou pas ?

La majorité des plugins ne sont pas encore validés pour SPIP 4, dans leur XML, 
et pas dans plugins.spip qui génère le flux des plugins disponibles. Et donc 
pas dans ton SVP local de ton site en bout de chaine.

Donc normal que ça ne sache pas trouver les dépendances en cascade.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-05-05 Par sujet RastaPopoulos
Le 29/04/2021 à 21:26, Arnaud Martin a écrit :
> La grosse limite de tout faire avec Compositions, pour moi, c’est que ça va 
> forcément laisser le choix d’utiliser un squelette qui n’a pas été prévu pour 
> être généralisé à l’ensemble du site. 

Eh non, depuis le début Compositions a une option quand t'es webmestre : 
"Verrouiller la composition". Dans ce cas ya que la personne s'occupant de la 
maintenance technique qui va choisir la composition, et les autres personnes 
qui utilisent le site au quotidien admins et rédacs ne pourront plus rien 
modifier pour cette rubrique.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Au cas où ça intéresse quelqu’une/quelqu’un

2021-05-04 Par sujet RastaPopoulos
Le 04/05/2021 à 09:59, Bruno Bergot a écrit :
> J'étais emballé "par la hype", mais j'ai moins kiffé quand j'ai vu qu'un clic 
> milieu sur le logo du header pour revenir à l'accueil de leur site ne 
> fonctionne pas ^^

D'où ma toute première remarque pour dire qu'il faut voir si on peut l'utiliser 
en mode amélioration progressive, avec les vrais liens et formulaires normaux 
par défaut. :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Au cas où ça intéresse quelqu’une/quelqu’un

2021-05-03 Par sujet RastaPopoulos
Le 03/05/2021 à 23:28, Luis Speciale a écrit :
> https://htmx.org/

Il faut que je cherche plus avant si on peut l'imaginer dans un contexte 
"amélioration progressive" où des choses marchent en GET et POST classiques 
(rechargement complet des pages), et avec leur truc en surplus qui améliore par 
dessus.

Mais sinon à part ça, c'est super simple à comprendre, quand je vois le code et 
ce que ça permet en juste 2 ou 3 attributs HTML ajouté, je suis carrément hypé, 
merci pour la découverte.

https://htmx.org/examples/

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] alpha 4.0.0

2021-05-02 Par sujet RastaPopoulos
Le 02/05/2021 à 13:30, team spipfactoy a écrit :
> Une idée, une piste, un tuto

Bé peut-être le premier truc, ce serait de tester un plugin *marqué ok pour 
4.0* non ? :)
Si tu parles d'install sans personnaliser la constante des compat de plugins.

https://git.spip.net/spip-contrib-extensions/adminer/src/branch/master/paquet.xml#L6

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


[spip-dev] Changer le label "Squelettes" du menu principal car 4.0

2021-04-30 Par sujet RastaPopoulos


Il y a déjà un ticket là dessus qui argumente pourquoi : 
https://core.spip.net/issues/4626
et je ne voyais aucun problème à attendre puisqu'on devait juste sortir une 
3.3, aucune urgence.

Mais désormais ça va être une 4.0. Dans ce cas, je pense vraiment que ça ne 
doit pas attendre, puisque version majeure + déjà plein de modifs dans l'admin.
Pour moi ça doit donc en faire partie, car c'est un problème, bug ergonomique, 
que je retrouve vraiment pour 100% des gens pour qui j'ai fait des sites et que 
je dois former ensuite.

Résumé TLDR : 
- 100% des personnes pour qui j'ai fait des sites n'ont aucune idée de ce que 
signifie ce mot, il n'a aucun rapport avec leurs tâches ni éditoriales ni de 
config
- ces personnes n'ont justement pas à connaitre ce mot (ni même à savoir 
qu'elles utilisent SPIP !) pour utiliser leur site, configurer ses 
fonctionnalités : en lisant l'interface, ses labels, elles doivent comprendre 
ce qu'elles peuvent faire
- quand on fait la liste réelles des fonctionnalités qui s'y ajoutent 
actuellement, 95% des choses ont rapport avec le fait de configurer des points 
de mise en page (quels contenus à quels endroits) et/ou d'affichage (styles 
graphiques) : style de box, menus, compositions, noizetier, adaptive images, 
style des liens de réseaux sociaux, etc.

Merci si possible d'argumenter directement dans le ticket, pour ne pas suivre 
plusieurs conversations à la fois.
Et donc d'argumenter, suivant ce que contient déjà et contiendrait dans le 
futur ce menu.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet RastaPopoulos
Le 29/04/2021 à 17:55, Matthieu Marcillaud a écrit :
> Tout n'est pas mauvais dedans pourtant : certaines choses n'ont pas changé 
> (l'aide sur la date de publication par exemple). Mais pour d'autres éléments 
> (je parle même pas des captures d'écran) on trouve : «la page de « 
> Configuration précise » ... choix interface simplifiée / interface complète, 
> ... » ou encore le «cookie de correspondance» (enlevé aussi)... C'est assez 
> trompeur quoi.

Je crois qu'on est à peu près tou⋅tes d'accord pour dire que dans l'absolu, 
avoir de l'aide c'est bien *mais* que énormément de choses sont obsolètes (en 
contenu et en affichage, capture).

La question est donc : est-ce qu'il ne vaut pas mieux aucune aide, qu'une aide 
obsolète ?

Pour l'instant j'ai plutôt tendance à penser que c'est mieux sans.

Et peut-être qu'aucune aide visible pendant un moment nous poussera mieux à 
nous saisir du sujet, possiblement en imaginant ensemble un nouveau système 
plus pérenne, en prenant le temps de le concevoir de 0. Sans essayer de réparer 
le système actuel qui ne va pas du tout (le fait d'avoir la même aide quelque 
soit la version notamment).

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet RastaPopoulos
Le 29/04/2021 à 17:44, Eric Lupinacci a écrit :
> Maintenant, franchement je ne vois pas pourquoi le JSON poserait des 
> problèmes à partir du moment où obtient les mêmes tableaux de wheels en 
> décodant le YAML ou le JSON.

Pour l'instant, un des arguments répondu, était que les wheels font parfois de 
nombreuses choses compliquées, dans un ordre précis, et que le YAML permet de 
faire des commentaires entre chaque morceau, ce qui n'est pas le cas du JSON.
https://git.spip.net/spip/textwheel/src/branch/master/wheels/spip/spip-listes.yaml#L31

Après les wheels… c'est un système qui me parait obsolète de nos jours, où il y 
a des vrais parseurs de grammaire désormais performants (avec PHP 7, PHP 8), et 
on devrait utiliser ça dans le futur plutôt que des regexs.

Concrètement les wheels actuelles, donc qui ont des commentaires dans le YAML, 
ces fichiers n'ont pas bougé depuis… 10 ans… 7 ans… suivant les fichiers.
Du coup c'est peut-être pas grave de ne plus avoir ces commentaires. En tout 
cas placés à cet endroit.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Récuperer des valeurs tableau d'un formulaire

2021-04-23 Par sujet RastaPopoulos
Le 23/04/2021 à 14:42, CSI a écrit :
>> Malheureusement ce n'est pas fournie avec le core de spip, et quand j'avais 
>> soumis l'idée on m'avait dit que c'était un cas trop rare...
> bizarre j'ai l'impression d'avoir le cas chaque fois que je fais un formulaire

À vrai dire il y a même un ticket dédié : https://core.spip.net/issues/4548

Et je compte bien faire la PR un jour, car vraiment c'est pas du tout énorme au 
niveau du code, peu de choses à maintenir à priori, ça ferait une super 
amélioration qui facilite plein de choses en peu de lignes de code.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Labels des saisies dans le back-office

2021-04-22 Par sujet RastaPopoulos
Le 22/04/2021 à 11:23, CSI a écrit :
> mais il y a probablement une raison ...

S'il y a une raison, elle va avoir du mal à être valable, ça faisait juste 
chier tout le monde :p

> Merci pour toutes les pistes que vous pouvez nous donner !

La piste c'est : c'est déjà corrigé en 3.3, il y a maintenant un jeu de classes 
pour mettre les labels soit en inline soit en bloc, et il faudra corriger la 
Fabrique pour générer les bonnes classes.
https://git.spip.net/spip/spip/commit/9dfa247747b85801ce4c3bc9dc09b08963ce23c0
+
https://git.spip.net/spip/spip/commit/c82d781469d7071c907140a6ea9138992da31f6f

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [spip] 2 commits

2021-04-21 Par sujet RastaPopoulos
Le 21/04/2021 à 09:46, Cerdic a écrit :
> En regardant de plus près, je pense que la solution serait de mettre dans le 
> core un filtre |image_recadre_avec_fallback (ou meilleur nom à trouver)

C'est… la toute première chose que j'ai immédiatement répondu hier déjà… :D

> avec un filtre dédié eventuellement (surchargeable du coup).
> 
> Genre #LOGO|image_transformation_prive
> 
> et un filtre_image_transformation_prive() avec dedans un test si ya pas de 
> lib, une réduction simple, et si ya une lib, un image_recadre avec focus, par 
> défaut
> 
> et en plus de ça, ça serait surchargeable si pour tel site on veut un truc 
> perso



-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [spip-commit] [spip] Et si on teste [(#CONFIGimage_process|==gd2| ?…

2021-04-20 Par sujet RastaPopoulos
Le 20/04/2021 à 14:12, Bruno Bergot a écrit :
> Et si on s'envoyait des mails au lieu de polluer l'historique du core ? ^^

Ou faire des PR :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [spip] 2 commits

2021-04-20 Par sujet RastaPopoulos
Le 20/04/2021 à 13:27, nicod_ a écrit :
> Attention, image_recadre et/ou image_reduire ne sont pas forcément 
> disponibles si on n'a pas encore activé la config GD2 ou autre...

Oui c'est voulu depuis des années qu'il n'y a pas image_recadre ou ce genre de 
gros filtres dans l'admin, il n'y a que la réduction qui peut se faire (car 
fallback quand pas de lib serveur).
Il faut donc revert ça à priori.

L'autre jour je demandais : ya pas moyen de savoir si on a une lib configurée 
ou pas, et faire l'un ou l'autre ? Même avec un filtre dédié eventuellement 
(surchargeable du coup).

Genre #LOGO|image_transformation_prive

et un filtre_image_transformation_prive() avec dedans un test si ya pas de lib, 
une réduction simple, et si ya une lib, un image_recadre avec focus, par défaut

et en plus de ça, ça serait surchargeable si pour tel site on veut un truc perso

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Accéder à git.spip.net

2021-04-19 Par sujet RastaPopoulos
Le 19/04/2021 à 15:26, Brice Boucard a écrit :
> Bonjour, oui, j'accepte sans aucune réserve la charte, si l'on parle
> bien de https://git.spip.net/CharteDeFonctionnement.html !

Non, on parle de https://www.spip.net/fr_article6431.html :)

Mais supprimez cette page de git.spip, elle n'a aucun sens ! (surtout que la 
charte devenue officielle sur le site portail central était déjà en ligne bien 
avant l'utilisation de git.spip)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Accéder à git.spip.net

2021-04-19 Par sujet RastaPopoulos
Justement comme l'a bien expliqué Mathieu : la coloration du code devrait en 
fait être juste une amélioration progressive en plus (de la déco), qui 
n'empêche pas du tout d'accéder au contenu lui-même quand il n'y a pas JS 
activé.

Par défaut sans JS, tu aurais le code, dans un balisage sémantique qui dit que 
c'est du code (). Et *si* tu as JS disponible : tu as de la déco de 
couleur en plus.

Ce serait donc même mieux qu'actuellement, à priori. :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Accéder à git.spip.net

2021-04-17 Par sujet RastaPopoulos
Le 17/04/2021 à 16:33, Matthieu Marcillaud a écrit :
> En général on préfère ne pas multiplier les plugins qui font la même chose 
> (ici de la coloration syntaxique). Ma préférence serait donc l'adaptation du 
> plugin coloration code, mais c'est peut être plus compliqué à faire.

+1 si tu te sens ok avec Git pour faire une branche de dev, ou trouver une 
personne pour te créer la branche s'il faut

En gros :

cd coloration_code
git checkout master
git branch dev/prismjs
git checkout dev/prismjs
=> tout casser dans cette branche :)
git push origin dev/prismjs
=> demander aux gens de tester :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Une 4.0 plutôt qu'une 3.3

2021-04-15 Par sujet RastaPopoulos
Le 14/04/2021 à 19:27, Bruno Bergot a écrit :
> Même avis, qui n'en est pas vraiment pas un pour moi, 3.3 ou 4.0 tant que ce 
> fameux 4.0 ne repousse pas la release plus loin que début mai, sans quoi on 
> va y coller what mille trucs (comme c'est le cas depuis un mois) pour au 
> final releaser dans 2 ans :p

Alors justement à propos de repousser ou pas : si on dit que parce qu'il y a 
pas mal de modifs *dont notamment l'admin* qui change un peu de tête (surtout 
graphiquement, pas vraiment ergonomiquement), et bien comme tu le dis très 
justement dans un ticket : "actuellement en 3.3 l'admin fait un peu sapin de 
noël" !

=> est-ce qu'on a vraiment envie de sortir une version majeure où les gens se 
disent "euh ça fait sapin de noël" ?

Pour le coup en terme de communication je ne trouve pas ça super justement…
Moi perso ça ne me va pas (je précise plus explicite : ça ne me va pas si c'est 
avec un numéro majeur).

Et du coup :
- soit il faudrait attendre de se mettre d'accord sur l'iconographie mais 
justement ça peut prendre trop longtemps, alors qu'on veut sortir cette version 
dans 2-3 semaines
- soit il ne faut pas que ce soit une majeure


Annexement pour moi une 4.0 serait : 
- soit pour Composer
- soit pour une réelle refonte ergo de l'admin, pas juste les styles graphiques 
améliorés

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [bigup] une icone svg pour bigup

2021-04-15 Par sujet RastaPopoulos
Le 15/04/2021 à 12:05, RealET a écrit :
> l'utilise sur tous les sites en 3.2)

Pareil j'ai Bigup sur 100% des sites en prod en 3.2 stable, donc faut pas le 
péter :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Nouveaux icônes/logos 3.3

2021-04-13 Par sujet RastaPopoulos
Le 13/04/2021 à 15:14, jeanmarie a écrit :
> Est-ce qu'ils viennent d'une source unique ou on les prend un peu ou on peut 
> ? (je pense aux plugins)
> 
> Dans l'idée de garder une cohérence (autant que possible), est-ce qu'il y 
> aurait un filtre/style à appliquer dessus ou quelque chose du genre ?

Je me pose la même question et Erational a aussi posé la même sur IRC ya une ou 
deux semaines.

On utilisait pour le moment un set d'icône PNG fatcow transformé en sepia, et 
on piochait dedans au maximum pour les nouveaux besoins.

Mais qu'en est-il maintenant pour maximiser la cohérence ? Juste prendre "du 
SVG" par ci par là ne suffit pas, et du coup c'est un peu au petit bonheur du 
choix des gens ? (là pour l'instant de cerdic qui fait une passe sur core et 
plugins-dist, avec parfois erational qui passe derrière)

Erational, un avis là dessus ? (et les autres aussi)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [produits] Un yaml pour inserer modeles mais il faudrait savoir (...)

2021-04-12 Par sujet RastaPopoulos
Le 12/04/2021 à 10:29, Maïeul Rouquette a écrit :
> 
> https://git.spip.net/spip-contrib-extensions/inserer_modeles/commit/fc78176
> ce serait pas ca la solution au pb ?

Mmmh il ne me semble pas à priori. Ma question ne porte pas sur le défaut, mais 
bien sur la toute fin, une fois qu'on a tout remplis, juste avant de générer à 
la chaine finale du modèle à insérer, savoir si on peut transformer certaines 
valeurs à ce moment.

Là par ex le but étant d'avoir une saisie qui génère forcément un tableau 
(cases multiples par ex), sauf que pour le résultat final c'est une chaine, ça 
existe pas la notion de tableau, donc savoir comment le transformer en liste à 
virgules.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] suivi des todo doc

2021-03-31 Par sujet RastaPopoulos
Le 31/03/2021 à 08:40, JLuc a écrit :
> Vous imaginez autant de tickets dans le trac ?

Bah… OUI… puisqu'ils existent *déjà* pour la plupart !

Relisons : comme déjà dit, une grosse partie de ta liste, concerne des 
évolutions *qui ont déjà un ticket* !

Donc à aucun moment il ne s'agit de créer ex-nihilo 29 tickets. Seulement 
passer les tickets déjà existants en "documentation", surtout *en ne les 
fermant pas* (donc les devs, cédric, b_b, moi, etc, doivent aussi penser à ne 
pas fermer les tickets quand une évolution nécessite de la documenter).

Et ensuite seulement certains ajouts ont été faits sans qu'il n'y ait eu de 
demande, de ticket avant. Et là oui il faudrait les créer en plus, mais il ne 
me semble pas que ce soit la majorité, non ?

Après si vraiment tu veux une page genre *texte libre* en "liste à puces" ou 
"liste todo/checklist" qui récapitule tout : il suffit de créer UN ticket 
"Suivi de la documentation" qui liste les autres tickets à documenter (et 
parfois des lignes sans lien vers des tickets quand il n'y en avait pas).
- Un jeu de class .label-(none|inline|inline-block|block)  [3316] (lien vers le 
ticket) + 123456abc (lien vers le commit)
- Autre truc [1234]
Et on peut même lier vraiment aux tickets (pas juste lien dans le texte libre 
mais vrai liaison)


Ou au pire une page "Suivi de la documentation" du wiki, sur contrib, avec une 
liste de todo. Dans les deux cas pas besoin d'un outil externe supplémentaire, 
avec un lien qu'on ne saura pas où retrouver.
Possiblement en activant le plugin Todo (qui est déjà là mais en inactif) : 
https://contrib.spip.net/Todo
Mais pour moi ça serait vraiment en dernier recours, car ça fait vraiment caché 
bidouille dans le wiki, alors qu'on a des tickets pour les tâches à faire.


-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] suivi des todo doc

2021-03-30 Par sujet RastaPopoulos
Le 30/03/2021 à 17:52, JLuc a écrit :
> Sinon voyez vous qqchose ?

Il y a déjà un tracker "documentation" sur les tickets du core exprès pour ça : 
as-t-on besoin d'ajouter un autre système en plus ?

Quand c'est pour documenter un truc qui avait déjà un ticket, il suffit de 
changer le tracker *et le laisser ouvert* (ne pas fermer juste parce qu'il est 
résolu au niveau du code s'il faut encore le documenter).
Et pour ce qui n'avait pas de ticket (ça arrive mais plus rare), créer un 
ticket exprès.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Titre et alt et légendes des images

2021-03-20 Par sujet RastaPopoulos

Excuse moi de te dire ça mon pauvre José, mais je crois que tu confonds un peu 
tout… :p

Tu parles d'un commit qui ne s'occupe que du alt, et ensuite tu fais des 
reproches sur la complication de faire des images sans légende. Ça c'est un 
truc fait depuis bien bien avant, dans la refonte complète des modèles, avec le 
fait que maintenant c'est unifié et ça s'affiche toujours pareil.

La séparation du alt ya déjà un ticket dessus, et justement le *bon* exemple 
c'était WP. Puisqu'un alt n'a possiblement rien à voir avec une légende quand 
on fait bien les choses. Le alt c'est la description précise de l'image ("Une 
photographie de ma famille et moi rigolant autour d'un tiramisu"), tandis que 
la légende peut être absolument n'importe quoi, n'expliquant rien de l'image 
("C'était trop cool cette journée !"). Si tu formes les gens en leur disant que 
le titre (qui peut vraiment être n'importe quoi) suffit pour le alt, ça allait 
vraiment pas niveau accessibilité justement ! Alors que désormais on peut faire 
un truc accessible comme il faut.

Quant aux images décoratives, sans légende sans rien, c'est complètement autre 
chose, et ça c'est la refonte des modèles qui date de moult mois.

Si tu remplis des informations, par défaut c'est qu'elles sont utiles, donc 
elles vont être affichées.

Si tu as une image de déco, que tu n'utilises que pour de la déco toujours, 
c'est simple, tu ne remplis rien, ya aucun intérêt à remplir.

De manière bien plus rare, pour une même image tu peux avoir rempli les infos, 
car dans un article vouloir l'afficher avec toutes les infos, et dans un autre 
sans rien du tout. Qu'on veuille faire ces deux affichages à la fois pour une 
même image est indéniablement plus rare. Mais tu peux le faire déjà ! Car 
désormais *chacune* des infos est surchargeable lors de l'appel !

va générer une image sans rien du tout si tu avais remplis tous ces champs.

Tu pourrais éventuellement faire un ticket pour dire : "ça serait bien d'avoir 
une méthode plus directe, plus simple, pour générer une image sans aucune info 
à coup sûr".

Du genre :  ?  ?

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] problème avec cache-js

2021-03-17 Par sujet RastaPopoulos
Le 17/03/2021 à 15:39, Cerdic a écrit :
> Le JS aurait été statique, cela aurait obligé à se poser des questions et 
> faire autrement, plus finement. 

+1, il faut toujours partir du principe que le JS doit être statique (ça doit 
être une méga méga exception, qu'il soit en squelette), et donc architecturer 
le code pour utiliser des infos utilisables en JS (data dans le HTML, etc, 
notamment)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Demande d'inscription

2021-03-15 Par sujet RastaPopoulos
Le 15/03/2021 à 19:49, JLuc a écrit :
> 2) obtenir un engagement à respecter la charte pour qui veut participer plus 
> et notamment commiter

Non la charte c'est pour tout le monde ! Dès qu'on a les tickets, on peut 
commenter de partout, donc on doit suivre la charte.

Par contre quand c'est juste pour les tickets : on n'a pas à être inscrit aux 
listes emails, de discussion et des commits, pour elleux c'est juste le compte 
git.spip. Alors que celleux qui commitent, c'est des droits en plus sur 
git.spip + les listes.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Notre cycle de release

2021-03-15 Par sujet RastaPopoulos
Le 15/03/2021 à 19:00, nicod_ a écrit :
> Pour le cycle minimal / pétillant, je n'ai pas d'avis, en fait je ne sais pas 
> (encore ?) ce qui justifierait un changement de X : composer ? réécrire SPIP 
> en Rust ? ^^

Refonte de l'admin
Refonte d'API du core, par ex refonte de CVT
Intégration de Saisies au noyau… :D

=> []


-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] sociaux lister

2021-03-09 Par sujet RastaPopoulos
Le 10/03/2021 à 08:17, chanka...@choc0.net a écrit :
> ah mais non, en fait dans la config tu peux pas non plus changer l'ordre...

Mais la doc dit clairement qu'il faut l'utiliser avec le plugin Menus pour 
ordonner. Donc tu fais un menu et tu mets dans l'ordre que tu veux les 
différents liens, et ensuite t'insères ce menu où bon te semble, non ?

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Demande d'inscription

2021-03-09 Par sujet RastaPopoulos
Le 09/03/2021 à 15:24, nicod_ a écrit :
>>> - je choisis mon type d'inscription (ticket, code)
> 
> C'est à dire, il y aurait plusieurs niveaux de droits sur Gitea ?

Cf mon fil sur la proposition d'accueil des nouvelles personnes pour ce point.

Avant, demander un accès à "la zone" c'était forcément pour du dev, donc tout 
le bazar qui va avec : être aussi inscrit⋅e à la liste des commits, à la liste 
de discussion s'il faut s'engueuler sur une modif, etc.

Mais maintenant dans la forge, ya aussi juste "faire des tickets", et ya plein 
de gens juste users, qui devraient pouvoir faire des tickets (sur nos plugins, 
et bientôt sur le core aussi quand ça sera migré) sans pour autant être 
"contrib", avoir les listes en plus etc. Illes veulent juste ajouter un ticket 
et suivre leur demande.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Demande d'inscription

2021-03-08 Par sujet RastaPopoulos
Le 08/03/2021 à 18:50, Eric Lupinacci a écrit :
> Oui j'ai merdé je suis allé trop vite en créant le compte sans l'affecter.
> C'est fait ou pas ?

C'était pas ma question :)

J'ai bien dit dans mon message que du coup je l'ai fait, mais donc un par un 
pour chaque team de chaque orga. Ce qui est galère et me parait pas solide.

Mais donc ma question c'est ça : c'est quoi le vrai processus officiel ? C'est 
de tout faire un par un ? Ou bien y a une manière d'ajouter la personne à un 
seul endroit et que ça synchronise toutes les teams d'un coup ?

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Demande d'inscription

2021-03-08 Par sujet RastaPopoulos
Le 01/03/2021 à 19:23, Eric Lupinacci a écrit :
> Demande traitée et approuvée.

Et… non, pas approuvée justement, jusqu'à tout à l'heure : créer un compte 
dans git.spip ne suffit pas, la personne doit faire partie de toutes les orgas 
de contrib, à l'intérieur d'un sous-concept de team "contrib" qui est dans 
chaque orga.

Soit il manquait une action de la part d'Éric (un script ou je ne sais quoi à 
lancer ?), soit il l'a bien fait mais ça n'a pas fonctionné.

Le processus d'ajout d'une nouvelle personne continue d'être encore mystérieux, 
on dirait. Pour l'instant comme je suis admin, j'ai pu par l'interface ajouter 
Elsa à toutes les teams une par une, mais du coup c'est galère et ce n'est pas 
solide : risque de désynchro, possibilité que pas les mêmes gens dans chaque 
team de chaque orga.

Du coup quel est le vrai processus clean ? Est-ce qu'il y a une liste de 
référence où on doit ajouter la nouvelle personne ? Et alors ça s'ajoute auto 
par un script de synchro ? Est-ce qu'il y a cette synchro ? Manuelle ou auto ? 
Si oui qui peut la lancer ? Que un admin sys sur le serveur ?

Tant de questions :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] La Boussole

2021-03-06 Par sujet RastaPopoulos
Le 06/03/2021 à 10:50, Eric Lupinacci a écrit :
> 1) _Liste_
> - *spip-info* : à supprimer de la boussole

Oui. Le contenu est pas mal obsolète, la forme aussi. Même si le but de départ 
est toujours aussi important.

Le site peut toujours rester en ligne pour le moment, juste ne plus en faire 
publicité.

Le sujet de ce site, son but, c'est en réalité le sujet de ce que devrait être 
le portail central spip.net : accueillir un peu tous les profils, faire 
découvrir, et rediriger les gens vers les zones les plus pertinentes suivant 
leurs intérêts. Bref le portail officiel quoi.

En 2010 : https://contrib.spip.net/Refonte-de-spip-net

En 2017 avec tcharlss : 
https://contrib.spip.net/Presentation-Documentation-et-refonte-du-portail-spip

> - *stats.spip.net <http://stats.spip.net> <http://stats.spip.net 
> <http://stats.spip.net>>* : à ajouter à la boussole

Je suis mitigé pour ça, c'est vraiment très technique et sans blabla autour, 
j'ai plus l'impression que ça sert juste à nous-mêmes en interne pour ensuite 
en tirer un rapport plus expliqué sur le Blog, comme a pu le faire James déjà. 
Mais donner ça en pâture aux gens, c'est un peu rude non ?

Si on l'ajoute, ça me vient pas immédiatement ce qui serait pertinent comme 
groupe… à la toute fin de Découverte faute de mieux ?

> - *git.spip.net <http://git.spip.net> <http://git.spip.net 
> <http://git.spip.net>> *: à ajouter à la boussole

Clairement c'est l'ajout le plus important : c'est LE point central pour 
contribuer désormais, aussi bien pour le core que pour les plugins.

> - *SPIP zone* : ne faudrait-il pas le supprimer de la boussole ?

Que si. Il est toujours là mais c'est juste de l'archivage, là aussi ne pas en 
faire la publicité.

> 2) _les regroupements_
> On avait initié un fil il y a 2 ans sur ce sujet y compris celui de la charte.
> Je reprends les remarques de Rasta:
> /"J'ai un peu du mal avec la typologie en fait :

C'est toujours le cas, et je n'ai toujours pas d'avis arrêté là-dessus pour 
améliorer.

Encore d'autres exemples : Contrib, c'est une liste de contributions, surtout 
des docs de plugins (qui sont des contributions) et quand on s'y inscrit, on 
peut aider à écrire donc on contribue… mais on contribue à quoi ? : 
essentiellement à *documenter* (des plugins surtout) ! C'est un de nos sites 
principaux, et ça le sera encore plus quand on fusionnera le catalogue des 
plugins dedans, et on est typiquement dans le cas d'un site qui est *à la fois* 
"Documentation" et "Contributions". Donc oui ya vraiment un soucis avec le 
découpage, il me semble.

C'est encore flou une chose possible : 

- Virer "ContribuTIONS" (qui est censé lister des contributions *déjà faites*, 
donc externes au core) et avoir une liste "Contribuer" ou "Participer" qui ne 
liste que ce que les gens vont pouvoir faire pour contribuer, pour les inciter 
à… Et déplacer tout ce qui est documentation des plugins dans "Documentation" 
donc Contrib, Code des plugins…
  - Documentation
- spip.net
- Contrib
- Programmer
- Code
- Code des plugins
  - Participer
- Traduire SPIP
- Rapporter un bug : core.spip.net/issues (pointer directement sur les 
tickets, le reste ne sert plus dans ce site)
- Contribuer au code git.spip.net : trouver un titre ?

> 3) _Liens particuliers dans la bande de navigation_
> Il serait bien d'ajouter un lien vers la charte

Oui ça me parait important aussi. À droite ça me va. Par contre c'est pas du 
tout traduit pour l'instant.

> D'ailleurs je ne vois pas l'intérêt que ce logo renvoie vers spip.net 
> <http://spip.net>.

Bah c'est le portail, que le tout premier lien (et on s'attend souvent à ce 
qu'un logo principal dans un menu soit un lien) aille vers le portail, ça me 
parait très normal.

> Un truc aussi étrange c'est que cette bande ne renvoie jamais vers la 
> boussole.spip.net <http://boussole.spip.net> qui a l'avantage en une page de 
> visualiser la liste des sites et leur description.
> Peut-être que le logo spip pourrait justement lier le site boussole et pas 
> spip.net <http://spip.net>.

Mof. Plutôt en tout premier de Découverte ?

> A vous lire, pour élaborer une proposition complète.

J'ajouterais : le menu généré n'est pas accessible, à commencer par la 
navigation clavier.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Version PHP minimum SPIP 3.3

2021-03-04 Par sujet RastaPopoulos
Le 04/03/2021 à 17:54, RealET a écrit :
> Après, d'un point de vue politico-phylosophique, SPIP a toujours cherché à 
> pouvoir être utilisé dans des environnements accessibles au maximum de 
> personnes et de pays.
> De ce point de vue, la compatibilité PHP 5.6 est peut-être bienvenue.

Mais concrètement ? Pour de vrai chez chaque hébergeur connu, c'est quoi ?

Quels sont les versions de PHP proposées par chaque hébergeur un peu connu en 
France, en Europe ?

Ou au moins : as-tu une liste des hébergeurs qui ne proposent pas plus que PHP 
5.6 ? Histoire de quantifier réellement si ça représente beaucoup ou si c'est 
totalement marginal.

Même les pages persos Free gratuites proposent PHP 7.3 ! Les hébergeurs 
payants, s'ils sont bloqués à 5.6 c'est que tu te fais arnaquer et que tu 
devrais changer d'hébergeur et donner ton argent à d'autres gens.

Et si on parle des dédiés, maintenus par des prestataires, là on fait ce qu'on 
veut dessus, et donc c'est à la charge du prestataire de tenir à jour Debian et 
PHP.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Version PHP minimum SPIP 3.3

2021-03-04 Par sujet RastaPopoulos
Le 04/03/2021 à 22:56, Matthieu Marcillaud a écrit :
> Du coup, dans ma grande motivation, je viens de reporter différents commits 
> pour PHP 7.2 et 7.3 en SPIP 3.2 qui enlèvent pas mal de deprecated et 
> certains warnings.
> 
> Puis dans la foulée, j'ai reporté aussi des éléments pour la compat PHP 7.4 
> dans SPIP 3.2.

Excellent, bravo ! Si 3.2 peut marcher comme il faut en 7.3 voire 7.4 c'est 
excellent, pour les migrations ensuite

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Amélioration de l'accueil des nouvelles personnes suite à git.spip.net

2021-03-03 Par sujet RastaPopoulos
Le 03/03/2021 à 13:30, Eric Lupinacci a écrit :
> Soit, mais je ne vois pas le rapport avec l'inscription ouverte.

Bah pour demander à des humains admin d'ajouter un compte, il faut les 
contacter, donc s'inscrire à la liste spip-dev ou ce genre. Dans tous les cas : 
des complications, des barrières à surmonter avant de trouver qui quoi comment 
arriver à avoir un compte, juste pour rapporter un bug dans un ticket d'un 
projet. C'est cent fois trop par rapport à tous les autres projets libres 
ailleurs, que ce soit ceux qui sont tout simplement sur github, ou ceux qui ont 
leur propre plateforme, où il n'y a aucune complication de ce genre pour 
commencer à intégrer la communauté (j'ai regardé sur WP, Drupal, et d'autres 
pour ceux qui ont leur inscription ailleurs que sur github : tout est en libre).

Faut évidemment pas penser qu'en mettant libre on va d'un coup avoir 5000 
personnes en plus, mais c'est quand même dommage d'ajouter des barrières 
artificielles qui repoussent forcément l'accueil dans la communauté.

Par ailleurs dans la proposition, il y a aussi la distinction entre deux étapes 
: avoir un compte permettant juste de pouvoir participer aux tickets, sans 
avoir besoin d'être inscrits aux listes, et seulement pour celleux qui le 
demandent en plus, avoir vraiment accès à la contribution, donc droits 
supplémentaires + là oui inscriptions aux listes en plus.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Amélioration de l'accueil des nouvelles personnes suite à git.spip.net

2021-03-02 Par sujet RastaPopoulos
Le 02/03/2021 à 17:53, nicod_ a écrit :
> Juste un bémol : quand les inscriptions étaient ouvertes, ça spammait grave, 
> il faut donc résoudre ça d'abord.

Oui je me souviens effectivement.

Mais du coup : pourquoi ? Je veux dire : pourquoi plus que sur nos autres sites 
(et que toutes les autres forges du monde qui ont toutes des inscriptions 
ouvertes) ? Si les autres forges y arrivent, on devrait pouvoir non ?

Au pire, même si on trouve mieux plus tard, mais pour avoir un truc qui marche 
plus vite : j'ai tendance à penser que c'est mieux un captcha ou ce genre de 
crotte, que pas d'inscription à cause des spams et donc rien du tout et des 
complications encore plus rebutantes pour les gens comme actuellement.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


[spip-dev] Amélioration de l'accueil des nouvelles personnes suite à git.spip.net

2021-03-02 Par sujet RastaPopoulos

Glop, 
l'arrivée de git.spip.net change assez profondément la manière dont on peut 
contribuer.

On est plusieurs à penser que l'accueil est trop compliqué, surtout qu'il y a 
maintenant plusieurs niveaux de contribution *dans une même plateforme*, ce qui 
n'était pas du tout le cas avant.

Avant :
- SVN, sans véritable forge user-friendly (juste pour de la lecture/recherche)
- aucun ticket de plugins
- le support se faisant uniquement par Contrib, dont les forums sont ouverts, y 
compris aux anonymes, donc facile de faire un retour
- pour y avoir accès, il fallait accepter la charte ET être inscrit à des 
listes, car il faut que l'email soit ok pour la liste des commits + il fallait 
pouvoir être contacté s'il y avait une engueulade, un truc à débattre à propos 
de commits

Maintenant :
- git.spip n'est pas juste une interface de lecture, quand on y a un compte 
avec les bons droits, ça donne le droit de contribuer, d'écrire (que ce soit 
code, tickets, ou wiki d'un projet)
- il y a maintenant des tickets par plugin, et faire des tickets *uniquement* 
est une manière de contribuer, même quand on n'y connait rien du tout au code 
et qu'on ne commitera jamais rien de sa vie
- avoir accès aux orgas "de contribution", pour l'instant c'est toujours les 
mêmes conditions : charte + listes SAUF QUE
  1) désormais il y a des tickets par plugins, dont la liste spip-dev est un 
peu moins obligatoire pour s'engueuler et commenter les modifs
  2) des gens non devs peuvent vouloir participer uniquement à faire des 
tickets et débattre des fonctionnalités SANS jamais coder de leur vie, donc 
sans obligation aucune d'être inscrit aux listes

La proposition serait de complexifier *légèrement* mais le moins possible, les 
droits de la forge, afin de couvrir tous les cas.
Et au passage de permettre une inscription semi-ouverte, au moins pour le début 
du processus.

Voici la proposition :
- ajouter si besoin un niveau de droits "uniquement tickets / commentaires" 
sans possibilité de modifier le code (mais peut être que c'est déjà le cas par 
défaut)
- ouvrir les inscriptions libres sur la forge
- que l'inscription libre oblige à cocher une case "j'ai lu et j'accepte la 
charte" (lien vers la charte spip.net ouvert dans un autre onglet)
- que l'inscription libre ajoute les gens dans toutes les orgas de contrib 
*seulement avec des droits de tickets/commentaires*
- qu'une explication d'un ou deux paragraphes soit ajouté sur cette même page 
d'inscription pour expliquer comment ça marche : "En vous inscrivant, vous 
pourrez créer et commenter les tickets de tous les projets. Si vous désirez 
ensuite contribuer au code, abonnez-vous à la liste spip-dev (lien) et demandez 
à contribuer. Un⋅e admin augmentera vos droits sur git.spip pour vous donner 
l'accès complet."

Du coup :
- ça laisse en partie l'inscription ouverte, c'est moins fermé que maintenant
- ça fait moins de boulot aux admins, qui n'ont plus à créer de comptes, mais 
seulement augmenter les droits quand on leur demande (et ajouter à la liste 
spip commit)
- on ne donne quand même pas les droits complets auto sans contact humain, ya 
quand même un filtre où on doit se parler

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Doc technique nouveautés SPIP 3.3

2021-02-23 Par sujet RastaPopoulos
Le 24/02/2021 à 00:05, nicod_ a écrit :
> Mon avis, il faut aussi un article dédié sur spip.net qui recense toutes les 
> nouveautés sur spip.net (gestion des logos, fin du portfolio, support SVG, 
> boucles anonymes, toussa toussa), parce que c'est une version majeure.

Quand ya une version importante ya toujours un article sur spip.net avec la 
liste non ?

Genre :
https://www.spip.net/fr_article6399.html

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [paniers] Dans le pipeline panier2commande_prix, on ajoute la cle (...)

2021-02-18 Par sujet RastaPopoulos
Le 18/02/2021 à 08:45, tofulm a écrit :
> Dans le pipeline panier2commande_prix, on ajoute la cle : prix_modifie.
> On ajoute aussi un pipeline post_edition : remplir_commande_details, qui
> se declenche apres le modification de la table spip_commandes_details,
> en lui faisant passer en data la cle : prix_modifie.
> Cela peut permettre d'indiquer dans la table spip_commandes_liens si le prix 
> a été modifié.

Yo, 
dis, quand il s'agit d'ajout fonctionnel non bénin, est-ce que tu pourrais 
créer un ticket et faire une PR pour expliquer la problématique ? Parce que là 
on sait pas ce que c'est censé résoudre, on sait pas ce que ça fait, ni comment 
ça s'utilise, ce qu'on doit y mettre dedans et pourquoi… et ça se trouve on 
aurait défini une autre solution si plusieurs personnes avaient relu. Ça vaut 
pour le plugin Prix aussi. Les plugins de commerce c'est quand même sensible, 
donc on devrait toujours avoir de la relecture (c'est d'ailleurs pour ça que 
Bank est pas dans le commun).

Là par exemple : 
- c'est quoi "prix_modifie", on sait pas pourquoi cet ajout et avec quoi ça 
doit se remplir, dans quel but
- l'objet c'est commandes_detail et c'est pour un unique détail donc l'action 
devrait être "remplir_commandes_detail" et non pas "remplir_commande_details"
- tu fusionnes avec tout $prix_pipeline, ce qui fait que les champs contiennent 
aussi "prix" et "prix_ht" et non pas juste "prix_modifie", alors même que 
commandes_detail a déjà un champ "prix_unitaire_ht", et bref on sait jamais ça 
pourrait rendre confus et causer des problèmes, vu qu'on n'est pas censé avoir 
ces champs là
- tu remets ce 'prix_modifie' dans le pipeline qui concerne la commande 
entière, alors que cette valeur est remplie dans une boucle uniquement *détail 
par détail* du panier, donc en fait ça y mets juste la dernière valeur de la 
boucle, ça n'a il me semble aucun sens, aucun rapport avec la commande entière

Bref, en l'état, ça me parait pas super à commiter ça comme ça dans le plugin 
direct…

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Quelle version de php utiliser ?

2021-02-17 Par sujet RastaPopoulos
Le 17/02/2021 à 14:51, Bruno Bergot a écrit :
> Oui, tester la version 3.3 intensivement 

Et tester les plugins non encore marqués compat, pour justement dire aux devs 
si ça marche ou pas et changer la borne le cas échéant (ou au moins savoir 
qu'il faut chercher quoi faire pour être compat)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Développer une balise spécifique

2021-02-03 Par sujet RastaPopoulos
Le 04/02/2021 à 08:15, Axel a écrit :


Si tu parles de permettre d'ajouter ça dans un contenu depuis l'admin (le texte 
d'un article par ex), il s'agit de modèles. C'est tout simplement un squelette 
SPIP dans le dossier modeles/. Donc là modeles/livre.html

https://www.spip.net/fr_article3454.html

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [Avenir de Multiflex] Re: [Spip-zone-commit] Accès git

2021-02-03 Par sujet RastaPopoulos
Le 03/02/2021 à 22:02, RealET a écrit :
> Et je trouverais juste qu'il puisse venir dire explicitement ici s'il accepte 
> la *nouvelle* charte.
> Sachant que lorsque je cherche la charte spip zone, je trouve :
> https://zone.spip.net/trac/spip-zone/wiki/CharteDeFonctionnement
> 
> et charte spip git : https://contrib.spip.net/FAQ_pratique_SPIP_avec_GIT
> qui renvoie sur https://git.spip.net/CharteDeFonctionnement.html dont le 
> contenu contenu a l'air identique.

Aucun de ces trucs là n'existe plus : la "zone SVN" ça n'existe plus, et le 
deuxième lien c'est cette ancienne charte qui a été copiée dans le Git je ne 
sais pas pourquoi, puisqu'au moment de la mise en place finale de git.spip, la 
vraie charte complète de la communauté entière (et non pas de tel ou tel 
sous-site) était déjà publiée en ligne depuis un ou deux ans : 
https://www.spip.net/fr_article6431.html

C'est là la seule charte, commune, unifiée, à accepter désormais pour utiliser 
les outils communautaires.

Et le truc sur git.spip devrait être supprimé (et le wiki FAQ pas bon).

Ce qui manque surtout c'est enfin personnaliser une page "Inscription" de gitea 
pour expliquer le processus (avec les bons liens).

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [Spip-zone-commit] Accès git

2021-01-18 Par sujet RastaPopoulos
Le 18/01/2021 à 16:02, tcharlss a écrit :
> Et bien si c'était le cas, sur le principe je trouverais ça très gênant.
> Supprimer un compte en catimini sans prévenir personne ? Pas très classe, 
> j'espère que ça a pas été le cas ici.

Moi non plus je ne trouverais pas ça légitime si ça a été fait sans annoncer 
clairement.

Mais là priori il n'y a très probablement rien eu de bizarre : 
- rien n'a changé sur les listes et il peut parfaitement poster puisqu'on voit 
et répond à ses messages… donc aucun rapport sur ce point
- Camille a clairement expliqué que *pour les anciens comptes de la forge*, 
donc spécifiquement pour le code, lors du passage en Git il y a eu du nettoyage 
de certains comptes non utilisés depuis fort longtemps et que donc il faut 
juste lui re-créer un compte pour le Gitea

… si la charte est acceptée.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Demande de compte https://git.spip.net/

2021-01-06 Par sujet RastaPopoulos


> beurresarrasin.net

Ça c'est du nom de domaine qui donne envie ! :D

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Gitea et le débardeur

2021-01-05 Par sujet RastaPopoulos
Le 05/01/2021 à 17:13, Eric Lupinacci a écrit :
> 1) Le problème ne concerne pas les tags ni la génération systématique des 
> zips par le débardeur. On pourrait même étendre à l'ensemble des tags si on 
> voulait... Maintenant, ne pourrait-on pas éviter de regénérer les zips 
> existant sur Gitea ?

C'est pas déjà le cas, genre si le débardeur voit que ça existe sur gitea, il 
le récupère tel quel ?

> 2) Il faut adapter les affichages sur Plugins SPIP (et bientôt Contrib) pour 
> mettre en avant les dernières versions de chaque branche et en second rideau 
> les autres versions (ergo à définir).

+1

> 3) Un changelog serait utile à la fois dans les affichages Plugins SPIP et 
> dans SVP afin de décider de la mise à jour en connaissance de cause.
> 4) Le plus simple et portable serait de créer un fichier CHANGELOG.txt ou .md 
> à la racine des plugins qui pourrait être utilisé par Plugins SPIP ou SVP 
> sous un forme à définir.
> 5) le format du changelog pourrait s'inspirer de : 
> https://keepachangelog.com/fr/1.0.0/
> 6) l'existence du changelog est facultative.

+1, c'est un autre sujet qui là nécessite des évolutions à l'infrastructure 
(pas juste l'affichage final), mais clairement oui : il y a d'ailleurs un 
ticket déjà dessus depuis 5 ans…
https://core.spip.net/issues/3509
 
> Ca peut faire une roadmap sympa il me semble non ?
Sur les tickets, il y a des choses qu'on a liées au 3509, notamment

- https://core.spip.net/issues/4256 qui parle de distinguer (donc étiqueter en 
amont, donc infrastructure aussi) spécifiquement les màj contenant de la 
sécurité : ce n'est pas pareil que Z qui change (ça peut être sécu ou juste 
petit bug, on sait pas), et ce n'est pas pareil qu'un changelog complet, qui 
est le détail humain, mais qui ne permet pas de le savoir informatiquement, et 
donc de le mettre en avant (que ce soit sur les sites de la galaxie ou dans les 
SPIP des gens)

- https://core.spip.net/issues/3017 dont la conséquence est que SVP devrait 
être amélioré pour connaitre plus qu'une unique mise à jour existante : en 
effet à un instant T, un plugin peut avoir une version majeure sortie X+N *et* 
une version Y+N ou même juste Z+N, et l'utilisateur ne veut PAS forcément 
changer de X, mais bien changer que Y voire même ne changer que Z pour être sûr 
de ne rien casser et avoir juste les corrections. Au niveau ergonomique, le 
travail est en gros fini, mais par contre, la conception de SVP ne le permet 
pas, donc pas possible de générer plusieurs boutons de mises à jour différentes 
à la fois. (Exemple de Sézi dans la maquette, qui a 4 mises à jour possible à 
la fois)

Ce dernier point est le plus compliqué il me semble, car SVP c'est compliqué et 
qu'il y a eu un gros angle mort de conception sur ce point on dirait. Cependant 
j'ai l'impression que pour les utilisateurs finaux (qui ne suivent pas le 
code), c'est encore bien plus important qu'avoir le changelog complet : les 
gens devraient absolument pouvoir faire des mises à jour mineures, sans qu'on 
leur montre uniquement la majeure, et illes sont capables de choisir l'option 
la moins dangereuse pour elleux même sans changelog complet avec les phrases 
claires et simples (on comprend la différence entre "màj 
corrective/fonctionnelle/majeure" et donc la dangerosité ou pas à changer sans 
tout péter).

Mais faisons déjà les choses "simples", sur lesquelles on a la main plus vite.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Gitea et le débardeur

2021-01-03 Par sujet RastaPopoulos
Le 03/01/2021 à 20:26, Eric Lupinacci a écrit :
> Là je suis vraiment fatigué.

Bah si on va par là, moi je suis fatigué de rien comprendre à un problème qui 
n'est pas vraiment expliqué, ou pas assez bien expliqué.

Déso mais je comprends RÉELLEMENT PAS où est le problème. Peut-être je suis 
débile.

Ça affiche TOUS les "y" existants, dans leur dernière version "z" (ou dit à 
l'envers : le dernier "z" de chaque "y" existant). Sachant qu'un "y" c'est un 
changement important (normalement pas cassant, mais important), pas juste une 
correction de bug. Donc totalement légitime de voir chaque "y" ayant existé. 
Entre deux "y" il peut y avoir de grosses différences, de gros ajouts.

Qu'on décide ergonomiquement d'afficher la plus récente en plus énorme, et les 
autres en pitit pitit, c'est une chose, un guide pour le choix. Mais c'est 
juste de l'ergonomie (et ce n'est pas fait actuellement). Ça ne change rien 
qu'on ne supprime jamais une release (et le fait de décider de faire un tag = 
c'est qu'on veut publier), et que ça doit rester dispo à l'avenir.

Et c'est bien ça la norme dans tous les projets PHP bien carrés, sur composer, 
sur github, et donc sur packagist ensuite.

https://github.com/symfony/routing
=> 488 releases ! : 100% des tags et donc y compris tous les Z !

https://packagist.org/packages/symfony/routing
=> central = dernière version puis sur le côté droit un bloc avec toutes les 
précédentes versions : 100% des tags aussi (normal vu que ça vient de la même 
source que le github à priori)

J'irais même jusqu'à dire que chez nous on n'en affiche *pas assez* même ! Et 
que donc oui il faudrait tous les Z justement, comme les autres projets 
Composer. Mais ensuite c'est à l'ergonomie d'être adaptée et bien pensée pour 
mettre en avant ce qui est le plus pertinent en gros en premier, et en plus 
petit/replié ce qui est passé.

Et que donc pour moi le problème est inverse : 
1) Il manque les Z, il devrait tout y avoir, pas moins.
2) C'est l'ergonomie (donc juste du squelette SPIP, pas l'empaqueteur) qui 
devrait être revue pour vraiment fortement en avant les derniers X/Y les plus 
pertinents et en petit voire replié les archives du passé, une vraie 
hiérarchisation pas tout au même niveau.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Gitea et le débardeur

2021-01-03 Par sujet RastaPopoulos
Le 03/01/2021 à 14:45, Eric Lupinacci a écrit :
> Je suis toujours embêté par notre méthode de génération des zips basés sur 
> les composants x et y d'une version x.y.z.

Avant de réfléchir à quoi faire pour que ce soit mieux, la question à préciser 
d'abord c'est : c'est quoi vraiment le problème ?

Pour la génération des zips précisément, ça ne se base sur sur "x" et "y" 
particulièrement, ça se base sur : dès qu'il y a un tag. Un nouveau tag = un 
zip, non ?

> On se retrouve avec des versions 3.11.1 et 3.12.1 par exemple visibles sur 
> Plugins SPIP, accessibles indépendamment alors que dans ce cas, 3.12.1 est à 
> utiliser préférentiellement.

Bé oui, toutes les versions considérées comme "à rendre publique" sont là, et 
c'est la plus récente en premier, donc je ne vois toujours pas où est le 
problème. 3.12.1 est bien affiché prioritairement à 3.11.X, donc c'est bien ça 
qu'on voit en premier. Et il n'y a pas de raison à ce que les versions d'avant 
disparaisse, peut-être qu'un bug existe en 3.12.1 et qu'il FAUT pouvoir revenir 
(y compris ceux qui ne sont pas en git !) à la version précédente. Qu'après au 
niveau ergonomie c'est à nous d'afficher de la manière qu'on veut, pas 
forcément tout au même niveau (la version la plus haute de chaque Y en plus 
gros, etc), ça c'est un autre problème : ça n'empêche en rien que tout ce qui a 
un tag est considéré comme "pertinent à rendre public", donc avec un ZIP en 
rapport.

> On en vient à éviter de faire un y+1 pour ne pas avoir ce type de désagrément.

Qui fait ça ? Pourquoi ? Je n'ai jamais eu l'idée de faire ça, et je ne saisis 
absolument pas l'intérêt.

> Et plus on va avancer, plus cela sera pénible.

Vraiment je n'arrive pour le moment pas à comprendre ce qui est spécialement 
pénible, ni pour qui.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Les PR sont coincées !

2021-01-02 Par sujet RastaPopoulos
Le 02/01/2021 à 12:22, Maïeul Rouquette a écrit :
> il y a encore des soucis de notifs, par exemple sur yaml où j'ai poussé tout 
> à l'heure :

Et ce n'est pas que pour les commits, il n'y a plus aucune notif du tout, même 
pour les commentaires ou nouveaux tickets.

Que ce soit par email (pour la liste de commits) ou sur IRC. Et même sur 
l'accueil.

Gitea ne lance plus aucun de ses hooks ?

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Plugin Massicot et gestion des autorisations

2020-12-31 Par sujet RastaPopoulos
Le 31/12/2020 à 11:23, glopg...@riseup.net a écrit :
> Aurais-je oublié une étape ?

Normalement tu n'as rien à faire toi, non.

Camille aurait-il oublié de t'ajouter à l'équipe "Contrib" après la création du 
compte ?

(
Au passage, ya vraiment des incohérences du "nombre de membres" entre les 
différentes orgas "de contrib", qui pourtant devraient toutes avoir le même 
nombre exactement.
spip-contrib-extensions 2 équipes   460 membres
spip-contrib-graphismes 2 équipes   467 membres
spip-contrib-outils 2 équipes   468 membres
spip-contrib-squelettes 2 équipes   467 membres
spip-contrib-themes 2 équipes   467 membres

Et pareil pour le core : spip 33 membres VS galaxie 35 membres
)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Plugin Massicot et gestion des autorisations

2020-12-31 Par sujet RastaPopoulos
Le 31/12/2020 à 10:32, glopg...@riseup.net a écrit :
> Bonjour,
> 
> Wow, quelle réactivité ! C'est super, merci beaucoup !
> 
> Et aucun problème avec la charte de fonctionnement. Bien au contraire,
> même.

Glop,

je vois que tu fork le dépôt, c'est un fonctionnement qui n'est pas encore 
expliqué très clairement (our bad) : sur Git comme sur l'ancienne zone SVN, 
tout le monde a les mêmes droits sur tous les dépôts communautaires. Il n'y a 
donc à peu près jamais à faire des forks dans son compte perso pour faire des 
modifs, puis des PR.

Il est bien mieux, à la fois plus simple pour soi *mais aussi pour les autres*, 
de faire une branche de dév directement dans le projet de départ (puisque tu as 
les droits) : cela permet à tout le monde de tester tes modifs uniquement en 
changeant de branche, sans devoir cloner un autre dépôt.

Donc tu fais : 
git branch dev/super_modif
ou
git branche deb/issue_123 (s'il y a une demande déjà créé pour ça)

Et ensuite tout le monde pourra tester tes modifs en faisant 
git checkout dev/super_modif
directement sur la même installation du plugin

Les PR peuvent être faites tout aussi facilement depuis une branche interne au 
même projet.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Plugin Massicot et gestion des autorisations

2020-12-31 Par sujet RastaPopoulos
Le 31/12/2020 à 09:49, cam.lafit a écrit :
> Bien entendu cela sous entend que tu acceptes
> https://git.spip.net/CharteDeFonctionnement.html lors de ta connexion.

Mais c'est quoi ce vieux truc à ne plus utiliser (et qui parle de SVN) ? :D

Elle est là la charte de la communauté entière à accepter, sur le site central 
portail :
https://www.spip.net/fr_article6431.html

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Écriture inclusive (!)

2020-12-17 Par sujet RastaPopoulos
Le 05/12/2020 à 00:45, te...@rezo.net a écrit :
> Version courte : arguer du handicap contre l’écriture inclusive n’est jamais 
> qu’une bassesse sexiste qui se moque bien des personnes en situation de 
> handicap.

Et du coup, un billet d'un groupe de personnes concernées par les handicaps, 
qui se positionnent contre ce genre d'argumentaire en faux-ami :

Contre la récupération du handicap par les personnes anti écriture inclusive
https://efigies-ateliers.hypotheses.org/5274

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Critères optionnel avec opérateur : doc imprécise ou bug?

2020-12-16 Par sujet RastaPopoulos
Le 16/12/2020 à 13:32, Maïeul Rouquette a écrit :
> Donc : incompréhension de la doc, ou bug ?

Les deux :p

1) La doc c'est pas assez clair et oui il faudrait être encore plus explicite 
que ça.

2) Moi je considère que c'est au moins un demi-bug, un gros gros manque, car à 
partir du moment où un critère permet de préciser *ce qu'on veut* comme 
comparaison à droite : un #ENV ou un #GET ou un #ARRAY etc, alors c'est ÇA qui 
devrait être testé si vide ou pas. En effet, ce n'est pas parce qu'il existe le 
critère {truc} qu'on va vouloir l'utiliser QU'UNE unique fois dans la boucle, 
et que donc c'est forcément #ENV{truc} qu'il faut tester. Si par exemple on a 
plusieurs filtres sur le même critère : {truc #ENV{filtre1}} {truc 
#ENV{filtre2}} : c'est bien ces deux valeurs là qu'on veut tester. Et à peu 
près tout critère peut être utilisé autant de fois qu'on veut !

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [HS] Re: Écriture inclusive (!)

2020-12-14 Par sujet RastaPopoulos
Le 14/12/2020 à 15:14, jacques a écrit :
> Quelles valeurs, sont-elles mises en avant sur le site de SPIP?

Tu réponds bien à ce qui t'arrange, Maïeul t'a donné tous les liens à 11h26 et 
en plus avec ton adresse en copie de la liste…

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [HS] Re: Écriture inclusive (!)

2020-12-14 Par sujet RastaPopoulos
Le 14/12/2020 à 15:17, Maïeul Rouquette a écrit :
> Mais pour pouvoir faire le 2) encore faut-il que le sujet ne soit pas abordés 
> en commencant par un troll de type 1), comme c'est le cas à l'origine du 
> présent thread.
> 
> Donc merci d'éviter d'inverser la charge de l'accusation.

+1

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [Spip-zone-commit] [mailsubscribers] v2.15.2 : texte explicatif pour newsletter_subscribe. (...)

2020-12-11 Par sujet RastaPopoulos
Le 11/12/2020 à 23:16, plac...@roxing.net a écrit :
> Bon si vous trouvez que la proposition n'est toujours pas bonne, je
> ferai un autre revert.

Je pense que tu devrais tout revert et copier tes propositions dans une 
branche, pour faire une PR et la discuter. Mais pas commiter dans le master 
comme ça. Depuis qu'on est passé en git, même les auteurices principales des 
plugins font ça dans leurs propres plugins, quand c'est pas de la correction de 
bug, cf dans formidable, prix, saisies, gis, et plein d'autres. On fait une 
branche (interne au plugin, on a tous les droits), et on en parle dans une PR.

git checkout master
git branch dev/ajout_trucmuche
git checkout dev/ajout_trucmuche
=> modifs
git pull origin dev/ajout_trucmuche
=> gitea, créer une PR à partir de la branche

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [Spip-zone-commit] [mailsubscribers] v2.15.2 : texte explicatif pour newsletter_subscribe. (...)

2020-12-11 Par sujet RastaPopoulos
Le 11/12/2020 à 20:23, Bruno Bergot a écrit :
> D'autres avis ?

+1 si on doit pouvoir ajouter un texte c'est uniquement optionnel, par défaut 
vide, et l'explication du champ doit juste être pour dire quoi configurer 
dedans. Mais aucun exemple entier comme ça de texte qui seront forcément 
totalement différent sur chaque site, suivant chaque contexte, pour ce besoin 
je vois pas de phrase qui serait générique (et par défaut c'est rien comme 
avant de toute façon).

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [Sélection éditoriales] Organiser les sélections

2020-12-09 Par sujet RastaPopoulos
Le 08/12/2020 à 19:51, c-real a écrit :
> "squelettes" (que j'ai rebaptisé le menu "mise en page"

+1 depuis le début ça devrait être ça, l'immense majorité des plugins qui 
s'insèrent dedans correspond à de la mise en page (et souvent de la mise en 
page *du site public*), et s'adressent aux admins, et non pas du tout des 
squelettes, qui s'adressent aux intégrateurices.

M'est-avis qu'il faudrait faire un ticket pour ça, ça peut être changé 
rapidement, au moins la chaine de langue.

On doit même pouvoir faire la liste des plugins qui ajoutent des choses dedans, 
et ainsi prouver facilement que 99% n'a rien à avoir avec les squelettes et ne 
s'adressent pas à des gens qui ont accès physiquement aux squelettes ni même 
qui savent à quoi ça correspond.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [Sélection éditoriales] Organiser les sélections

2020-12-09 Par sujet RastaPopoulos
Le 09/12/2020 à 10:18, jeanmarie a écrit :
> Oui, ce n'est sans doute pas la bonne piste, je me dis que celle de Laurent 
> (un plugin permettant de retrouver des "éléments éditables" via le menu 
> squelette) est plus pertinente : au lieu de chercher à ranger les sélections 
> éditoriales pour mieux s'y retrouver, il paraitrait plus logique de retrouver 
> ces sélections spécifiques via le menu Squelette.
> 
> Ça serait une façon intéressante "d’étendre" l'interface de SPIP pour 
> retrouver ce qui est lié au squelette (et donc technique), un peu à l'image 
> des noisettes du noiZetier mais sans la notion de construction du squelette. 
> Bref, j'y jetterais bien un œil à ce plugin (bis ;) ).

Je n'ai pas compris ce que tu veux dire dans cette partie, et pour l'instant de 
ce que j'avais compris de la description de Laurent, c'était peu ou prou la 
même chose que Sélections éditoriales : comme on le voit dans sa capture 
d'écran, "Accueil - Articles secondaires" bééé… c'est une Sélection quoi (et 
dedans les contenus choisis en question), je ne vois aucune différence majeure, 
en l'état de ma compréhension pour l'instant. :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [Sélection éditoriales] Organiser les sélections

2020-12-09 Par sujet RastaPopoulos
Le 08/12/2020 à 23:41, nicod_ a écrit :
> J'ai testé Sélection éditoriales déjà mais y'a des choses qui ne me vont pas, 
> en terme de fonctionnalités et d'interface.

Ça pourrait être intéressant de le détailler plutôt, voire d'en faire des 
tickets. :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [Sélection éditoriales] Organiser les sélections

2020-12-09 Par sujet RastaPopoulos
Le 09/12/2020 à 00:21, c-real a écrit :
> Il manque juste un mini-truc que le plugin sélection d'objet permet : la 
> possibilité d'associer un logo à un objet sélectionné pour pouvoir l'utiliser 
> dans le cadre spécifique de la sélection éditoriale.
> 
> Par exemple, pour un carrousel dont les slides pointent sur des articles 
> selectionnés :
> 1./ Par défaut, le visuel du carrousel utilisé est celui de l'article.
> 2./ Mais si j'associe un visuel à l'item dans la sélection éditoriale, c'est 
> celle-ci qui est prise en compte.

Bé si, c'est justement une fonctionnalité de base du plugin qui est là depuis 
le tout premier upload du plugin, et qui était l'une des raisons même de sa 
création (càd que dans l'utilisation d'une sélection, on veut un titre 
différent plus court, une autre image plus grande, etc, différent du truc par 
défaut qui reprend le titre et image du contenu d'origine). Sur chaque logo ya 
un lien "modifier" dessus. :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [Sélection éditoriales] Organiser les sélections

2020-12-08 Par sujet RastaPopoulos
Le 01/12/2020 à 15:38, jeanmarie a écrit :
> Pour les newsletters, les sélections ne sont pas forcément associées car 
> insérées directement dans le contenu via un modèle. Je fais ça pour laisser 
> le maximum de latitudes aux utilisateur·rices : alterner sélection et texte, 
> choisir la façon dont s'affiche la sélection (colonnes, ligne, pleine 
> largeur), etc...

Pour moi c'est là le problème, que *dans les squelettes* tu n'utilises pas les 
sélections liées, c'est une chose, mais le fait qu'elles soient utilisées dans 
le texte en insertion, bah ça veut quand même dire qu'elles sont liées et donc 
: doivent l'être.

Ça devrait même le faire automatiquement, comme pour les documents joints, ou 
les formulaires Formidable. Pour ça copier sur ces deux plugins pour faire 
pareil. Mais en attendant que ce soit fait automatiquement, ça devrait être lié 
explicitement quand même.

> Donc dans l'idée, j'aurais bien fait un "groupe" newsletter et un autre 
> plutôt "outils" ou "technique" pour s'y retrouver. Ça éviterait, dans 1 an, 
> d'avoir à chercher celle qui gère le diapo dans les 50 qui ont servi aux 
> newsletters.

C'est bien ça, où ça me parait overcompliqué d'ajouter une manière de ranger, 
alors que justement les listes techniques ce sont précisément les sélections 
"indépendantes" liées à rien, qu'on appelle dans les squelettes par leur 
identifiant. Tandis que les sélections de newsletter… bah sont liées à des 
contenus d'objet=newsletter, et donc facilement séparé à part.


-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [Sélection éditoriales] Organiser les sélections

2020-12-08 Par sujet RastaPopoulos
Mais le plugin Sélections éditoriales sert précisément à cela hein… :D
(et avec le plugin Sélecteur générique activé, ça cherche aussi par titre déjà)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Écriture inclusive (!)

2020-12-05 Par sujet RastaPopoulos
Le 05/12/2020 à 13:33, Escal a écrit :
> Chère tetue,

Sérieux t'arrives à broder tous ces paragraphes de merde alors que Tetue 
parlait clairement à un homme précis, Joel, et en citant à peu près que des 
références techniques sur l'accessibilité, et toi t'arrives à faire dire tout 
et n'importe quoi à ça ?!

Non mais sérieusement, vous êtes complètement tarés, certains…

Comme le disait Touti, ce pauvre petit point médian de rien du tout, ça fait 
rabougrir les couilles on dirait, et remonter tous les mascus à la surface de 
l'eau.

C'est plus rapide de faire comme le dit Arno* : va chier.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Écriture inclusive (!)

2020-12-03 Par sujet RastaPopoulos

Purée mais cym, yannx, pascal, joel (oui tous dans le même panier), juste… soit 
barrez vous soit taisez vous si le projet politique qu'il y a *toujours* eu 
derrière SPIP ne vous convient pas :
- soit vous utilisez le logiciel parce que techniquement ça vous est utile 
(comme un site du FN peut utiliser SPIP s'il veut, voyez moi aussi je peux 
faire du Godwin),
- soit vous allez voir ailleurs, mais sans troller votre dominance sur le 
projet politique un tant soit peu émancipateur qu'il y a toujours eu derrière 
(si tant est qu'on puisse très très légèrement améliorer les choses, mais on 
fait sur quoi on a la main dessus, en l'occurrence là dans SPIP et nos plugins)

Certains sujets sont à débattre, d'autres sont au fondement même de la charte 
de la communauté et non, on ne débattra pas là-dessus à priori et il n'y a pas 
à comprendre la position adverse : on la connait plutôt bien, et devinez quoi : 
on n'est pas d'accord *politiquement* avec ! Et donc ya aucun consensus à 
chercher là dessus. SPIP ce n'est pas "que de l'amour", c'est de la tendresse 
entre gens qui acceptent la charte commune et qui portent des valeurs 
similaires. SPIP c'est pas Jésus, et non ya pas forcément d'amour pour tout le 
monde (et encore même Jésus il peut mettre dehors les marchands du temple).

Que par contre on débatte sur *les modalités* de l'écriture inclusive, ça oui, 
sur la manière manière de le faire, la plus lisible tout en étant la moins 
lourde, c'est légitime. Et on l'a déjà fait et on continuera sûrement (l'état 
du débat étant = équilibre à trouver à chaque contexte et non pas en règle 
unique, au maximum des mots épicènes, puis du doublonnage avec deux termes, et 
en dernier recours des points médians lorsque c'est un contexte qui doit 
vraiment rester court sans possibilité de doublonner masculin et féminin).

Mais tout ce thread n'a aucun rapport avec ça ! Et donc ce n'est pas ici dans 
ce thread qu'on débattra de ces modalités, vu que ce ne sont que des invectives 
réacs et anti-féministes.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Intl

2020-12-02 Par sujet RastaPopoulos
Le 02/12/2020 à 23:44, Maïeul Rouquette a écrit :
> bah oui mais du coup ca concerne la partie backgrend. Mais pour la saisie de 
> nombre côté public, un coup de JS ca peut être utile.

Oui oui, la lib c'est pour l'affichage, donc pour les vues, pour ce qui 
concerne les saisies (justement parce que le JS ne peut pas s'occuper de la 
vue). Mais donc tout ça va forcément ensemble à priori, si t'as la saisie faut 
la vue, et pour la vue faut la lib Intl (comme évoqué dans le ticket de 
saisie_nombre avec tcharlss). D'où le fait que les saisies (qui sont forcément 
dépendantes des comportements locaux aussi) devrait à priori être tout dans le 
même plugin avec la lib d'affichage, histoire de pas demander à avoir un plugin 
pour la vue et un plugin pour la saisie.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Intl

2020-12-02 Par sujet RastaPopoulos
Le 02/12/2020 à 22:26, Maïeul Rouquette a écrit :
> Faudrait-il pas qu'on essaie de mutualiser cela.
> 
> Je suis désolé, j'ai vraiment pas trop de temps pour SPIP en ce moment. Mais 
> il faudrait qu'on en parle.

Comme on disait avec Charles l'autre jour, dans un mélange d'IRC et de ticket, 
sur le nom et le contenu du plugin :
https://git.spip.net/spip-contrib-extensions/prix/issues/2

La lib, et donc le plugin, fournit des choses tournant autour des 
"comportements régionaux" (c'est comme ça que traduit "locales" la doc de PHP 
en gros). La lib fournit les devises du monde, les locales du monde, un 
formateur de nombre, et un formateur de montant (c'est le précédent + une 
devise).
Donc on disait que le plugin devait contenir : une saisie devise, une saisie 
nombre, une saisie montant (et leur vue, basée sur la lib).


-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [Sélection éditoriales] Organiser les sélections

2020-12-01 Par sujet RastaPopoulos
Le 01/12/2020 à 14:34, jeanmarie a écrit :
> Est-ce que d'autres ont ces questions aussi ? Et d'autres idées ?

pas tant que ça, ça reste un cas rare d'en avoir beaucoup je crois (en tout cas 
d'en avoir beaucoup en autonome)

il y a déjà une séparation entre les sélections autonomes (qu'on appelle plutôt 
par leur identifiant) et les sélections liés à des contenus (que ce soit pour 
"voir plus" de choses après un article ou dans une lettre, etc)

combien tu as de sélections autonomes VS de liées ?

on pourrait déjà améliorer le tableau de bord pour pouvoir filtrer par plus de 
choses, peut-être avoir une unique liste comme les commandes et des filtres sur 
le côté (mais je sais pas si le critère permettant de filtrer les autonomes ou 
pas sais le faire en dynamique avec un param, faut peut-être améliorer), 
pouvoir filtrer par autonome ou pas, statut, quel type d'objet lié (ne voir que 
les sélections de lettre) etc

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [moncompte] On augmente la version du coup (mais faudrait passer à (...)

2020-11-28 Par sujet RastaPopoulos
Le 28/11/2020 à 07:38, Franck a écrit :
> Hello rasta 
> Il n'aurait pas fallu faire un tag en même temps, sachant que tu lui donnes 
> le statut de "test" ?
> Car là, le plug est introuvable sur plugins.spip.net et donc, les gens ne 
> peuvent en faire le téléchargement via svp...

Seulement si JE veux le distribuer :p

Il n'a jamais été distribué du tout pour l'instant, même avec la version 
d'avant. Mais oui on devrait pouvoir commencer maintenant :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Git et twgit

2020-11-13 Par sujet RastaPopoulos
Le 13/11/2020 à 14:44, Eric Lupinacci a écrit :
> Il nous faut un linguiste anglophone !

Comme je le disais, et c'est pour ça que je le disais, c'est en travail pour 
changer ça chez les anglophones eux-mêmes, dans un très très grand nombre de 
logiciels, donc c'est sans rapport à la traduction. Le mot principal pour dire… 
principal, c'est "main" ou "primary", et non pas "master" du tout.

https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Git et twgit

2020-11-13 Par sujet RastaPopoulos
Le 13/11/2020 à 08:44, Eric Lupinacci a écrit :
> En anglais ça veut dire "principal".
> Il n'y a donc aucune autre connotation.

Si si :)
ça veut dire "principal" *parce que* historique depuis master/slave et 
justement absolument dans toutes les communautés *anglophones* il y a un 
mouvement social pour supprimer totalement cette notion de master. Donc bien 
sûr que si il y a une connotation et un mouvement pour ne plus l'utiliser, de 
manière internationale.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


[spip-dev] SPIP interdit les URL avec des slashs ?

2020-11-11 Par sujet RastaPopoulos


Je m'aperçois que SPIP interdit d'ajouter des URL avec des slashs ? Pour quelle 
raison ?

Comment fait-on si on veut garder la compat, pour ne pas casser les URL 
existantes d'un site WP par ex, où les URL sont de la forme 
"2012/09/15/mon_article" ?

Et attention je ne parle pas d'avoir un jeu d'URL permanent pour reproduire ces 
URL à la blog, auquel cas on pourrait créer un "type d'URL" dédié, ce qui 
serait déjà chiant. Mais bien de pouvoir garder ces URL de compat *parmi 
d'autres* ! C'est-à-dire les avoir possiblement en URL secondaires, 
"d'archive", dans les URL de tel article, même si yen a une nouvelle plus 
récente à la mode de SPIP.

Autrement dit, le cas d'utilisation est très simple et il me semble très 
courant dès qu'on migre depuis un autre système, d'avoir dans spip_urls pour le 
même article :
objet   | id_objet | url
article | 1234 | 2012/09/15/ancienne_adresse
article | 1234 | mon-article

Juste pour que les anciennes marchent toujours, et redirigent vers les 
nouvelles (si yen a une nouvelle).

Donc pourquoi les slashs sont prohibés ? Comment kon fait ? :(

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Reposter sur twitter facebook et Instagram ? [HS]

2020-11-11 Par sujet RastaPopoulos
Le 11/11/2020 à 14:21, nicod_ a écrit :
> Pour syndiquer des contenus issus de ces silos fermés (Facebook Twitter etc.) 
> RSS Bridge développé par Seb Sauvage est bien pratique :
> https://github.com/RSS-Bridge/rss-bridge

Merci, très intéressant !

Ça pourrait permettre au moins de faire un plugin SPIP sans maintenir la 
machinerie compliquée nous-mêmes, car c'est un projet bien maintenu 
apparemment. Donc qui va marcher même quand les API changent tout le temps chez 
ces réseaux.

Donc ça permettrait de faire un plugin SPIP au moins pour la lecture : pouvoir 
aspirer des contenus d'ailleurs dans un SPIP, faire des "social wall", ou 
aspirer des calendriers d'événements notamment Facebook (de nos jours, plein de 
salles de concert, ou assoc, ne mettent leur calendrier que là, et donc c'est 
compliqué quand on veut suivre 50 calendriers à la fois sans être forcément sur 
facebook).

Bon évidement ça ne résout pas l'inverse : SPIP vers réseaux extérieurs.

Le mieux serait que la lecture ET l'écriture soit dans une lib maintenue, et 
non pas juste la lecture. Ce qui permettrait de faire plusieurs plugins SPIP 
basés dessus dans les deux sens.

Pour moi depuis le début ce qu'il faudrait c'est que pour chaque réseau on 
implémente seulement des points d'API, des manières de se connecter, mais pas 
tout l'interface complète, qui devrait être dans un plugin commun.

Genre :
- un plugin coquille vide "bridge" qui a des fonctions génériques et qui 
demande à implémenter *pour chaque service externe* diverses fonctions 
prédéfinies :
  - une pour dire comment se connecter avec un compte de ce service
  - une pour récupérer des contenus de ce service
  - une pour publier des contenus chez ce service
  - etc suivant les besoins
  - et qui quand il y a au moins un service trouvé et configuré, ajoute des 
interfaces pour publier
- un plugin Twitter qui intègre une lib maintenue et qui ne fait qu'implémenter 
les fonctions de Bridge
- un plugin Facebook qui intègre une lib maintenue et qui ne fait…
- un plugin Instagram…
- etc

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] court-circuiter accès restreint

2020-10-16 Par sujet RastaPopoulos
J'ai testé sur un site où j'ai des contenus restreints et ça marche 
parfaitement sans rien activer de plus MAIS en envoyant vraiment l'auth HTTP 
dans la requête (avec une extension FF de requête comme Rester, ou avec curl 
-u). On dirait que le nav, en tout cas Firefox, n'envoie pas les bonnes infos 
en mettant //login:pass@domaine dans l'URL. Pourtant il me semblait bien que 
si, ayant déjà accédé à des trucs HTTP ou FTP depuis Firefox en mettant les 
identifiants là.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] court-circuiter accès restreint

2020-10-16 Par sujet RastaPopoulos
Le 16/10/2020 à 10:32, Sylvain Nogues a écrit :
> J'avoue que je n'ai pas bien pigé le lien entre le plugin et
> l'authentification "basic" d'apache, j'ai cru que c'étaient deux choses
>  indépendantes.
>  Y aurait-il de la doc quelque part là-dessus ?

je ne comprends pas de quoi tu parles. Ça n'a rien à voir. Accès restreint il 
n'a rien à voir avec l'authentification du tout, il a à voir avec les 
autorisations (authentification et autorisations ça n'a rien à voir donc). 
L'authentification c'est dire au logiciel "je suis telle personne, tel compte 
utilisateur". Les autorisations c'est "telle personne à accès à telles choses". 
Accès restreint il fait juste le liens entre des comptes utilisateurs et des 
zones (des rubriques) à accéder, peu importe comment on s'est authentifier 
(comment on a dit à SPIP qu'on était bien telle personne).

Les deux choses sont à tester totalement séparément. D'abord tu dois réussir à 
te connecter à SPIP directement depuis l'auth HTTP donc avec le login et le 
pass déjà envoyés dans la requête, et que SPIP authentifie bien le compte et le 
connecte (même si ya pas d'accès restreint, mais ça vaut pour l'admin aussi ou 
autre besoin). Et ensuite d'un autre côté, il faut qu'accès restreint donne 
bien accès à tel compte pour tels contenus. Mais c'est totalement séparé.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] court-circuiter accès restreint

2020-10-16 Par sujet RastaPopoulos
Le 16/10/2020 à 00:32, Sylvain Nogues a écrit :
> J'avais bien testé cela, mais ça ne passe pas l'accès restreint.
> Je suis bien en https. Faut-il crypter le mot de passe passé dans l'url ?

Non c'est le mot de passe d'où le fait que ça doit être en HTTPS pour pas 
circuler en clair.

> Je n'ai pas activé l'auth basic http; juste le plugin accès restreint.

Ah je disais peut-être de la bêtise : il faut peut-être aussi activer un truc 
dans la conf Apache du site !

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] court-circuiter accès restreint

2020-10-15 Par sujet RastaPopoulos
Le 15/10/2020 à 23:19, Sylvain Nogues a écrit :
> login/passwd dans l'url

Comme dans toutes URL (pas juste HTTP) : avec https://login:pass@domaine/chemin

Par contre pour l'auth basic http comme ça, il faut vraiment que ton site soit 
en HTTPS du coup

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Documentation sur les temps de connexion

2020-10-15 Par sujet RastaPopoulos
Le 03/07/2020 à 18:48, RastaPopoulos a écrit :
> Quand je lis :
> https://www.spip.net/fr_article5716.html
> ça parle d'un temps de *session* de 12h, et qu'on peut le modifier.
> 
> Mais la case dans le formulaire de connexion dit *quelques jours*. On est 
> d'accord que 12h c'est pas quelques jours ? :)
>
> Donc les "quelques jours", c'est la validité d'un cookie, pas la session ? 
> Mais c'est quoi le temps de session alors ? Par rapport à mon navigateur, 
> quand je me barre, que je l'éteins, ça correspond à quoi ?
> 
> Et ces validités de cookies, ils sont automatiquement calculés suivant cette 
> session (là ça parle de 4 × la variable) ? ou bien on peut les personnaliser 
> séparément ?

Quelqu'un⋅e qui y a compris quelque chose peut-ille expliquer le détail ?

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Chaine de langue dans boucle objet

2020-10-12 Par sujet RastaPopoulos
Le 12/10/2020 à 12:47, pierre laszczak a écrit :
> Je ne saurais dire si c'est un comportement voulu.

Bé oui c'est le principe même de ce pour quoi tu décides de mettre true à cette 
variable : que ça se traduise suivant la langue choisie de cookie choisie et 
gardée en mémoire pour le visiteur, et non celle des contenus en train d'être 
lus.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Refonte Mediabox [wip]

2020-10-05 Par sujet RastaPopoulos
Le 05/10/2020 à 17:57, Cerdic a écrit :
> Petit défaut, elle ne gère pas du tout les galeries, et son developpeur 
> considère que c’est hors de son objectif, mais il me semble qu’il y a tous 
> les points d’entrée pour faire ça en personalisation - et sinon son 
> developpeur a dit qu’il était ok pour ajouter des points d’entrées pour le 
> permettre.

Est-ce qu'on ne devrait pas écrire la liste complète de ce qu'on veut avoir, 
pour comparer qui a le plus (sachant que chaque besoin ne se vaut pas, certains 
sont plus faciles à ajouter à une lib qui le manquerait, alors que d'autres 
sont indispensables à avoir de base) ?

Par ex, parmi d'autre, il me semble qu'il faudrait aussi qu'une ouverture 
(média ou page ou bloc interne) puisse afficher un titre + un descriptif 
(souvent utilisé pour titre et crédit quand c'est pour un média).

- Médias
- Galerie de médias
- Bloc interne
- Iframe
- Accessible au clavier
- Aria comme il faut
- Titre et desc
- Non basée sur des tailles en pixel, responsive
- Events variés (pré ouverture, après chargement, fermeture…)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [fontawesome5] mise à jour du plugin picto à la version fontawesome (...)

2020-09-28 Par sujet RastaPopoulos
Le 26/09/2020 à 15:48, JLuc a écrit :
> Chacune des nouvelles versions de ces plugins est un peu comme un fork du 
> précédent,
> qui ne l'invalide pas.

Comme n'importe quel plugin, ça vaut pour absolument n'importe quelle 
fonctionnalité, je maintiens. Si les Saisies de Saisies 1 te suffisent et que 
tu n'utilises que #SAISIE, tu peux très bien rester durablement sur une vieille 
version si ça t'amuses aussi.

Et inversement pour BS, FA, etc, il te manque des icônes, et tu dois passer à 
une version supérieure (tout comme tu voudrais passer à une version supérieure 
de Saisies parce que des nouvelles saisies te sont utiles).

Ya vraiment aucune différence avec les fonctionnalités de n'importe quel autre 
plugin. Le fait que ça casse (par ex les préfixes des icônes changent de FA-4 à 
FA-5) c'est un choix des mainteneurs, mais ils pouvaient très bien choisir 
aussi de garder la compat ascendante. Tout comme dans un plugin SPIP c'est 
totalement un choix, et pas du tout un fait assuré, que quand tu mets à jour ça 
ne casse presque rien. Certains plugins, suivant les devs, peuvent parfaitement 
décider de casser beaucoup de choses en changeant X.

Donc bah non, je ne vois toujours pas de différence entre ces embarquements de 
libs externes, et des plugins internes à SPIP. Ça devrait être des branches 
changeant X : semver sert très exactement à ça.

Et améliorer SVP, tout le monde est d'accord là-dessus, cf la prop d'ergo à 
implémenter.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [fontawesome5] mise à jour du plugin picto à la version fontawesome (...)

2020-09-26 Par sujet RastaPopoulos
Le 26/09/2020 à 12:35, RealET a écrit :
>> Si on a un problème ergonomique avec SVP quand il gère et prévient les gens 
>> des mises à jour : c'est ça qu'il faudrait corriger absolument, pas faire un 
>> préfixe par version majeur de plugin, non ?
> 
> Dans la mesure où SVP a un bouton "Cocher toutes les mises à jour", et un 
> comportement identique quel que soit les risques de la mise à jour, je trouve 
> que le choix de changer de préfixe est tout à fait cohérent.

Tu réponds ça en citant très exactement la phrase qui explique bien que c'est 
justement ÇA qu'il faut corriger…

Et je ne vois pas le rapport que ce soit Bootstrap, Foundation, FontAwesome, ou 
n'importe quel : ça vaut pour n'importe quel plugin. Si le plugin Agenda ou 
Formidable passe de la version X à X+1, en cassant de la compat, des boucles 
qui changent, etc, alors d'après cette argumentation ça voudrait dire qu'il 
faudrait faire un autre plugin avec un autre préfixe pour chaque. Pourtant ce 
n'est pas ce qu'on fait, et il ne faut pas faire ça.

Je crois qu'à peu près tout le monde est d'accord pour dire qu'il y a des 
problèmes importants d'ergonomie dans SVP. Il y a même un ticket explicitement 
sur ce point :
https://core.spip.net/issues/3017

Et deux autres sur l'ergo de SVP sur d'autres points (le sous-menu et le lien 
de configuration) :
https://core.spip.net/issues/3603
https://core.spip.net/issues/4429

Et j'ai travaillé une maquette ergo regroupant les solutions aux trois tickets 
à la fois, la dernière version (avec l'ajout de tcharlss) étant celle là :
https://core.spip.net/attachments/download/1179/3603.html

Cette ergonomie empêchant totalement de faire des mises à jour majeure sans le 
savoir. Tout est explicite.

Mais c'est de l'ergo… ensuite il faut faire une PR.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [fontawesome5] mise à jour du plugin picto à la version fontawesome (...)

2020-09-26 Par sujet RastaPopoulos
Le 26/09/2020 à 11:31, erational a écrit :
> comme pour les plugins boostrap, j'aimerai qu'on propose des plugins pour 
> embarquer les versions majeures de ces libraires de facon simple d'où mon 
> plugin indépendant
> 
> suis-je plus clair ?

Pour moi oui.

En revanche pour l'instant je ne comprends toujours pas l'intérêt d'avoir des 
plugins réellement différents (= autre préfixe) pour chaque version de ce qu'on 
embarque.

Le principe du versionning sémantique c'est justement pour permettre de dire 
que quand on change la version X (dans X.Y.Z) c'est un changement majeur qui 
casse la compatibilité antérieure. Donc quel intérêt de carrément changer de 
plugin pour ça, alors que les numéros de version servent précisément à ça ?

Concrètement pourquoi un plugin prefix="fontawesome5" et non pas un unique 
plugin "fontawesome" ayant des branches Git "branches/v4", "branches/v5", 
"branches/v6", etc ?

Je sais qu'un argument est que ça empêche les gens de mettre à jour 
"automatiquement" vers une version majeure différente qui casserait leur site. 
Mais on a alors ce problème pour TOUS les plugins du monde qu'on a et qui 
changeraient de version X. Pourtant on ne le fait pas pour chaque plugin du 
monde. Quand le plugin Patates passe de 2.3.4 à 3.0.1, on ne fait pas un 
prefix="patates2" et un prefix="patates3", même quand ça casse le 
fonctionnement (ce qui est souvent le cas si on décide de changer X).

Si on a un problème ergonomique avec SVP quand il gère et prévient les gens des 
mises à jour : c'est ça qu'il faudrait corriger absolument, pas faire un 
préfixe par version majeur de plugin, non ?

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] [conception] Un plugin Progressive Web App commun en coquille vide ? (1 SW 2 rule dem all)

2020-09-15 Par sujet RastaPopoulos
Le 15/09/2020 à 08:25, Cerdic a écrit :
> Mais potentiellement il faut remettre à jour la listes des urls à 
> télécharger, en particulier si tu as des ressources générées automatiquements 
> (css, js..) dont les URLs peuvent changer (si tu as fais des modifs de 
> squelette), ou si tu veux que les visiteurs téléchargent par défaut les 
> derniers articles ou…
> 
> bref ça dépend aussi comment tu veux utiliser le plugin

Ok alors pour cette liste de démarrage : y a-t-il un squelette surchargeable 
permettant de personnaliser la liste des pages (justement pour "les derniers 
articles" ou plus précisément "la même liste que ceux qu'on voit sur 
l'accueil") ?

Car la doc parle de comment générer des boutons pour des objets entiers avec 
offline/urls-{objet}.html, ça ok. Mais pour la liste automatiquement chargée à 
l'installation ?
J'ai vu que dans la config ya un champ libre pour en personnaliser en plus à la 
main, mais ça c'est du ponctuel manuel. Pour faire comme les boutons pour 
objets, des automatismes (donc avec boucles) pour lister dans l'installation 
les mêmes que sur l'accueil, ya un squelette ou un pipeline PHP possible ?

Pour le build d'installation avec spip offline:build:services (ou le rebuild 
total avec les objets aussi), ya deux possibilités, pour que ce soit moins 
complexe pour Booz, et qu'il n'y ait que à changer le numéro dans l'admin :
- sur le serveur on peut programmer un vrai cron pour l'appeler une fois par 
nuit, et donc le lendemain ça enverra les nouveaux contenus aux gens, si ça 
suffit comme période
- si on veut encore plus de réactivité, on pourrait imaginer une option 
"--if-version-changed". Dans ce cas on pourrait programmer un vrai cron *toutes 
les minutes*, mais la commande sortirait immédiatement si ça détecte que la 
version éditoriale dans la config n'a pas changé depuis le dernier build. 
Évidemment pour pouvoir faire ça, il faut que lors d'un build, ça enregistre 
dans un fichier ou en base, le numéro de la version éditoriale utilisée à ce 
moment, pour pouvoir comparer ensuite.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


  1   2   3   4   5   6   7   8   9   10   >