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

2021-05-08 Par sujet Maïeul Rouquette

Le 08.05.21 à 20:05, RastaPopoulos a écrit :

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.


idéalement faudrait une balise "mange retour ligne" (ca existe en latex!)
___
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-08 Par sujet Maïeul Rouquette

Le 07.05.21 à 16:54, Eric Lupinacci a écrit :

Hello,

Je commence à mettre à jour la compat des plugins que je maintiens mais 
je me pose pas mal de questions.
En outre, je vois passer des mises à jour sur d'autres plugins et on est 
pas très raccord sur la stratégie à adopter.
Je me dis que ça serait bien de définir quelques recommandations pour 
éviter la joyeuse kermesse à la fin...




Je suis plutot d'accord avec la logique de branchement proposé, même si 
je ne suis pas sur qu'il soit pertinent de reduire les branches 
existantes. A voir.

___
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] Mailman -> Discourse

2021-05-07 Par sujet Maïeul Rouquette

Le 07.05.21 à 18:12, Ben. a écrit :
Bonjour à toutes et à tous, ce week-end (sûrement dimanche), le contenu 
entier de la mailing liste va être transféré sur discourse ...


Merci pour ces précisions.

Deux questions

1. Je suppose du coup que le nntp va être débranché ?
2. Actuellement on peut facilement transferer une notif de commit,  pour 
en discuter.,  depuis spip-zone-commit sur la liste spip-dev. Est-ce 
qu'une solution de facilité a été prévue ?


Maïeul
___
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 Maïeul Rouquette




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.

++
Eric




j'ai un doute sur le prefix proposé, risque confusion. "cartographier" ?

___
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] [saisies] On passe le master de Saisies en spip 4 pour permettre (...)

2021-05-07 Par sujet Maïeul Rouquette
oui car pour l'heure une alpha c'est une alpha. Ce sont aux gens qui
testent de savoir ce qu'ielles risquent. Et je vais pas releaser un
truc qui va encore evoluer dans les prochains jour.

Surtout qu'on a la possibilité de forcer la compat, et que saisies v3
marche.


Le vendredi 07 mai 2021 à 11:21 +0200, spip.fra...@lien-d-amis.net a
écrit :
> Hello 
> Toi ou eric, vous n'avez pas fait de tag v4.x.x, c'est normal ?
> Le statut de la v4 est "test" donc si ma mémoire est bonne, la mise à
> jour ne sera pas proposée sur les sites l'utilisant car eux doivent
> avoir une v3.x.x en "stable"
> Franck
> 
> -Message d'origine-
> De : Maïeul Rouquette  
> Envoyé : vendredi 7 mai 2021 09:20
> À : SPIP-dev spip 
> Objet : Re: [spip-dev] [saisies] On passe le master de Saisies en
> spip 4 pour permettre (...)
> 
> Le 07.05.21 à 08:23, Eric Lupinacci a écrit :
> > spip-contrib-extensions/saisies
> > -
> > Par Eric Lupinacci, le 7 mai 2021 à 08h22min :
> > 
> > On passe le master de Saisies en  spip 4 pour permettre de tester
> > beaucoup d'autres plugins sans constante de compatibilité.
> > 
> > 
> > *Modifié*
> >  paquet.xml
> > 
> > Détails : 
> > https://git.spip.net/spip-contrib-extensions/saisies/commit/94329ed2d0
> > bc0969fa6bf3c638867e08adfcbd01
> > 
> 
> Merci Eric, mais il aurait été bien de branche aussi dans le même
> temps une branche v3, puisque, ainsi qu'expliqué hier sur IRC, on ne
> souhaite plus maintenir sur master la compatibilité pour les
> anciennes branches de SPIP.
> 
> C'est fait.
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
> 

___
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] [saisies] On passe le master de Saisies en spip 4 pour permettre (...)

2021-05-07 Par sujet Maïeul Rouquette

Le 07.05.21 à 09:33, Eric Lupinacci a écrit :

Yo,

Le ven. 7 mai 2021 à 09:19, Maïeul Rouquette <mailto:mai...@maieul.net>> a écrit :



Merci Eric, mais il aurait été bien de branche aussi dans le même temps
une branche v3, puisque, ainsi qu'expliqué hier sur IRC, on ne souhaite
plus maintenir sur master la compatibilité pour les anciennes branches
de SPIP.

C'est fait.


Oui, désolé, j'ai hésité mais comme on n'en avait pas discuté...
Par contre, tu as mis 3.3.* en borne mini, je pense pour inclure la 
3.3.0-dev qui n'a réellement jamais vu le jour.
Je pense que ça ne marchera pas car * ne devrait pas inclure le -alpha : 
à vérifier.


Après, franchement, faut-il vraiment intégrer une version 
fantôme sachant qu'elle n'apparaît pas dans la liste des branches ?


++
Eric




bah je t'ai suivi, vu que tu avais mis 4.0.* je supposais que le * 
impliquait les suffixe ;-)


___
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] [saisies] On passe le master de Saisies en spip 4 pour permettre (...)

2021-05-07 Par sujet Maïeul Rouquette

Le 07.05.21 à 08:23, Eric Lupinacci a écrit :

spip-contrib-extensions/saisies
-
Par Eric Lupinacci, le 7 mai 2021 à 08h22min :

On passe le master de Saisies en  spip 4 pour permettre de tester beaucoup 
d'autres plugins sans constante de compatibilité.


*Modifié*
 paquet.xml

Détails : 
https://git.spip.net/spip-contrib-extensions/saisies/commit/94329ed2d0bc0969fa6bf3c638867e08adfcbd01



Merci Eric, mais il aurait été bien de branche aussi dans le même temps 
une branche v3, puisque, ainsi qu'expliqué hier sur IRC, on ne souhaite 
plus maintenir sur master la compatibilité pour les anciennes branches 
de SPIP.


C'est fait.
___
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] [bellespuces] valide SPIP 4.0

2021-05-06 Par sujet Maïeul Rouquette
Le 06.05.21 à 20:27, chanka...@choc0.net a 
écrit :

hello,
je sais pas, je me range à l'avis général...




--

chan





perso je vire les plugin.xml au fur et à mesure.

___
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] [saisies] Indiquer le format attendu pour l’email

2021-05-06 Par sujet Maïeul Rouquette
Le jeudi 06 mai 2021 à 14:01 +0200, nicod_ a écrit :
> Le 06/05/2021 à 12:01, Maïeul Rouquette a écrit :
> > trois remarques par rapport à ce commit :
> > - pourquoi est-ce que seuls les lecteurs ecran et autre auraient
> > le 
> > droit à cette explication ?
> 
> J'ai appliqué le même markup que pour les dates.
> 
ah ! peut être aussi à reflechir pour les dates du coup
> > - ne vaudrait-il pas mieux plutot dire qu'il s'agit là de
> > l'explication 
> > par défaut, qui pourrait être surchargé au cas par cas (par exemple
> > si 
> > on domaine spécifiquement un email de type u...@lenomduneboite.truc
> > , ou 
> > si on est en suisse est qu'on veut n...@fournisseur.ch :-P)
> 
> On peut modifier la chaine de langue : n...@fournisseur.net
> 
oui, mais cela suppose d'avoir une présentation identique sur tous les
formulaires d'un site. Mais effectivement si on modifie la chaine de
langue par défaut, au moins on aura pas un francocentrisme:)
> > - est-ce que un placeholder ne serait pas également pertinent
> > (voire ne 
> > suffirait pas)
> 
> Non, les placeholders sont des pièges en terme d'UX et
> d'accessibilité.
ok, laissons pour l'instant de côté cette question
> 

___
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 Maïeul Rouquette

Le 06.05.21 à 11:18, Jean-Christophe Villeneuve a écrit :

Ah cool, en effet ça va bien m'aider ce plugin dev !

JC



sinon il y aussi le plugin "saisies" qui permet de juste déclarer le 
sens semantique de des saisies qu'on veut avoir et laisser le plugin se 
charger du marrkup :p

___
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] [saisies] Indiquer le format attendu pour l’email

2021-05-06 Par sujet Maïeul Rouquette

Le 05.05.21 à 19:54, nicod_ a écrit :

spip-contrib-extensions/saisies
-
Par nicod_, le 5 mai 2021 à 19h53min :

Indiquer le format attendu pour l’email


*Modifié*
 lang/saisies_fr.php
 saisies/email.html

Détails : 
https://git.spip.net/spip-contrib-extensions/saisies/commit/0ecff8e95a468fdd25a1a29b8649c6b72146e43c

___
spip-zone-com...@rezo.net - 
https://listes.rezo.net/mailman/listinfo/spip-zone-commit


Salut Nicod,

trois remarques par rapport à ce commit :
- pourquoi est-ce que seuls les lecteurs ecran et autre auraient le 
droit à cette explication ?
- ne vaudrait-il pas mieux plutot dire qu'il s'agit là de l'explication 
par défaut, qui pourrait être surchargé au cas par cas (par exemple si 
on domaine spécifiquement un email de type u...@lenomduneboite.truc, ou 
si on est en suisse est qu'on veut n...@fournisseur.ch :-P)
- est-ce que un placeholder ne serait pas également pertinent (voire ne 
suffirait pas)

___
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 Maïeul Rouquette

Le 06.05.21 à 11:48, RastaPopoulos a écrit :

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.

moi j'ai envie de dire : quitte à rompre des choses, simplifions et 
virons les incohérences du core :)


Idéalement la case à cocher c'est mieux (même si pas tjr possible), 
reste à voir quoi faire du côté des chaines de langue.

___
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] Fight for your right to party

2021-04-30 Par sujet Maïeul Rouquette

Le 30.04.21 à 00:51, nicod_ a écrit :

Bon,

Macron a dit qu'on aurait le droit de refaire une SPIP Party à partir du 
mois de juin.


Qui c'est qu'est chaud ?


moi

mai faudra qu'on fasse trps gaffe, car a mon avis ca risque de repartir 
severe ...

___
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 Maïeul Rouquette

Le 29.04.21 à 21:04, nicod_ a écrit :

Le 29/04/2021 à 20:06, Manu a écrit :
Oui, n'empêche que les squelettes articles=xx.html ou 
articles-xx.html, on peut dire ce qu'on veut, ça rend bien souvent 
service.
Et quand c'est natif, ...c'est simple à mettre en œuvre (!!!) et pour 
des débutants, c'est une technique vraiment accessible.


J'avoue que c'est le seul sur lequel j'ai un doute...
Il risque de péter des vieux squelettes, et comme tu dis c'est une 
technique utile.
Mais bon, y'a déjà des choses qui cassent, et le plugin compositions est 
quand même vraiment fait pour ça.

Ce sera précisé dans les notes de mises à jour.

j'ai tendance à dire que oui c'est pratique pour du dev rapide... mais 
ca coince vite les gens sur des choses pas idéales.


je connais des associations qui aimeraient rendre generique leur 
squelettes mais qui sont coinciés pour avoir pris ce biais d'écrire en 
dur un numéro de rubrique...


___
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 Maïeul Rouquette

Le 29.04.21 à 17:07, Matthieu Marcillaud a écrit :

Bonjour,

Nous sommes donc partis pour versionner SPIP 4.0 à la place de SPIP 3.3 
la prochaine version.


Nous sommes quelques un·es à proposer qu'on retire des plugins-dist 
certains plugins (*ils seront toujours disponibles via la gestion des 
plugins* pour les réactiver — ça ne veut pas dire qu'ils ne seront plus 
maintenus par la communauté)




Pour faire cours
- oui pour ceux "pas d'objections", mais il faudra faire un gros 
travaille sur la doc

- à debattre

a. Pour l'aide, je ne sais pas, je ne l'utilise pas, mais si j'ai bien 
compris le problème principal se situe dans la manière de maintenir 
cette aide ?
b. Pour le compagnon, je dirais à garder, mais est-ce qu'on ne pourrait 
pas avoir quelque chose qui detecte la première connexion à l'espace 
privé, et nous demande "Connaissez vous spip" > si oui desactive le 
compagnon

C. pour les wheels suite aux remarques d'Eric
a. OK pour passage en JSON avec les ajustements de cy_altern
	b. Reflechissions à plus long terme sur la syntaxe et les outils, mais 
le but c'est de sortir une 4.0, pas de refaire SPIP (par exemple 
Markdown, oui pq pas, mais il a aussi des limite !)
	c. Surtout si on sort les wheels maintenant, j'ai peur de choses qu'on 
aurait pas pensé qui existe que dans les wheels mais pas dans le core de 
SPIP

___
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-26 Par sujet Maïeul Rouquette




Par erational, le 26 avril 2021 à 20h29min :

[ui] un jeu complet pour les auteurs avec les couleurs chartes. l'auteur 
poubelle est desaturée pour le voir moins. la peau est grise charte ... à 
priori pas de soucis éthique




Pas de souci ethique en effet, mais par contre les statut sont 
distingués uniquement par des couleurs, pas top en terme d'accessibilité 
(même si la plupart du temps l'icone est accompagné d'un texte).


Idéalement il faudrait un insigne, mais quasi tous les insignes de 
pouvoir posent problème éthique. Je sèche.

___
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] [ui] suivi : proposition de changement de metaphore après (...)

2021-04-24 Par sujet Maïeul Rouquette

Le 24.04.21 à 15:50, erational a écrit :



Le 24/04/2021 à 13:08, Maïeul Rouquette a écrit :

Le 24.04.21 à 12:45, erational a écrit :

spip/spip
-
Par erational, le 24 avril 2021 à 12h44min :

[ui] suivi: proposition de changement de metaphore après discussion 
avec mon fils qui voyait du wifi, voir un mirador (sic) au lieu de 
broadcast .on part donc sur une icone de notification pour le suivi 
des nouveautés.



*Modifié*
 prive/themes/spip/images/suivi-xx.svg

Détails : 
https://git.spip.net/spip/spip/commit/0bf7237dac871480558ebc393db5ba221b7a75bb 





Techniquement l'ancienne icone c'est le symbole de la norme RSS.

salut

cette nouvelle icône sert pour aller à la page suivi_edito "suivi de la 
publication"

ex. https://contrib.spip.net/ecrire/?exec=suivi_edito

l'icône RSS est déjà utilisée pour aller sur la page de synchro "suivre 
la vie du site"

ex. https://contrib.spip.net/ecrire/?exec=synchro



je constatais juste le sens, je ne dit pas qu'il était bien appliqué :)

deux questions d'ailleurs:
- la page suivi édito sert-elle à qqchose ?
on dirait quasiment la page d'accueil.
d'ailleurs pourquoi y lister les révisions alors que les révisions ont 
leur page dédiée ?

ex. https://contrib.spip.net/ecrire/?exec=revisions


ah oui

- la page synchro
.. faut il encore y lister le widget javascript ? il y a encnore 
vraiment des gens qui utilisent ca ?

je me demande si c'est pas un ajour récent :P
.. sur le label "suivre la vie du site" n'est pas très cohérent avec les 
autres items du menu

"suivi de la vie du site" serait plus logique







___
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] [ui] suivi : proposition de changement de metaphore après (...)

2021-04-24 Par sujet Maïeul Rouquette

Le 24.04.21 à 12:45, erational a écrit :

spip/spip
-
Par erational, le 24 avril 2021 à 12h44min :

[ui] suivi: proposition de changement de metaphore après discussion avec mon 
fils qui voyait du wifi, voir un mirador (sic) au lieu de broadcast . on part 
donc sur une icone de notification pour le suivi des nouveautés.


*Modifié*
 prive/themes/spip/images/suivi-xx.svg

Détails : 
https://git.spip.net/spip/spip/commit/0bf7237dac871480558ebc393db5ba221b7a75bb



Techniquement l'ancienne icone c'est le symbole de la norme RSS.
___
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 Maïeul Rouquette

Le 23.04.21 à 14:42, CSI a écrit :

Bonjour,


Le 23/04/2021 à 12:47, Maïeul Rouquette a écrit :

Le 23.04.21 à 11:55, CSI a écrit :

Bonjour,


C'est juste la syntaxe de la récup d'une ou des valeurs du tableau 
qui coince, un truc doit nous échapper ... si quelqu'un a une piste, 
merci d'avance !


--�
Pierre
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, mais bon, on a contourné en n'utilisant pas de tableaux, un 
peu moins élégant :-) content néanmoins de voir que ma recherche était 
suffisamment sérieuse et que ma conclusion était la bonne, j'avais peur 
d'avoir raté quelque chose d'évident.


le plugins saisies fournie une fonction capable de gérer cela : 
saisies_request()

ok on va regarder.
Merci pour toutes ces infos.

--
Pierre


d'une manière globale je t'inviterai à regarder le plugin saisies si tu 
commence des nouveaux formulaires, ca permet de gerer pas mal de choses 
pratique et de declarer sa structure de formulaire de manière simple

___
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 Maïeul Rouquette

Le 23.04.21 à 11:55, CSI a écrit :

Bonjour,


C'est juste la syntaxe de la récup d'une ou des valeurs du tableau qui 
coince, un truc doit nous échapper ... si quelqu'un a une piste, merci 
d'avance !


--
Pierre
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...


le plugins saisies fournie une fonction capable de gérer cela : 
saisies_request()


___
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] [ajuster_intertitres] Ajout du lien vers la discussion de la PR vu que ma (...)

2021-04-22 Par sujet Maïeul Rouquette

Le 22.04.21 à 16:04, jeanmarie a écrit :

spip-contrib-extensions/ajuster_intertitres
-
Par jeanmarie, le 22 avril 2021 à 16h03min :

Ajout du lien vers la discussion de la PR vu que ma tentative de lien 
automatique a foiré.


*Modifié*
 README.md

Détails : 
https://git.spip.net/spip-contrib-extensions/ajuster_intertitres/commit/218b18148ff73ae33bc8d399b46c1ccaf26b0362


Merci Jean-Marie.

Honnetement je n'aurais pas le temps de m'occuper des petits points qui 
restent à faire, surtout que les questions d'echappement ca n'a pas de sens


___
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] 5 commits

2021-04-21 Par sujet Maïeul Rouquette

Le 21.04.21 à 21:19, Arnaud Martin a écrit :



Ah ben zut, je pige pas un mot de ce que tu dis là. Je suis désolé, mais je 
pige que dalle à Git dès qu’on fait des branches et des machins.

Déjà que je pige pas la différence entre «Fetch» et «Pull» (Fil m’a expliqué, 
j’ai rien gobé), alors l’histoire de «dry-run», tu te doutes que c’est du 
chinois.

ARNO*







Je reprend : visiblement tu as fais quelque part une merde en local, en 
fusionnant une branche distante de dev dans ton master (je sais pas 
comment !)


Ce n'est pas très grave si tu fais juste cela en local. Mais si tu push, 
ca devient problématique, puisque cela pourri l'historique des autres.


Si tu utilise l'option --dry-run sur ton git push, alors git ne va pas 
pousser tout de suite, mais juste faire une sorte de test, et te dire 
les resultats que cela donnerait. Comme ca tu aurais vu que t'a envoyé 
un commit foireux, et aurait pu corriger.


Maïeul
___
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] 5 commits

2021-04-21 Par sujet Maïeul Rouquette




Par ARNO*, le 21 avril 2021 à 20h27min :

Merge remote-tracking branch 'origin/dev/css_boites_alertes'



Détails : 
https://git.spip.net/spip/spip/commit/c06dc430c227a61f42d0eabd7bd0954a0db8a681

___
spip-com...@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/





Je sais pas ce que tu a fichu Arno, mais tu a envoyé sur master une 
branch de dev de tcharlss pas finalisé.


Peux tu faire de --dry-run avant de pusher, ca éviterait ce genre 
d'ennui (ou ca limiterait !)


En tout cas je sas pas comment les gens envisagent de corriger du coup
___
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] Tablesorter nécessite memoization?

2021-04-20 Par sujet Maïeul Rouquette

Le 20.04.21 à 17:17, jeanmarie a écrit :

Le 20/04/2021 à 16:59, Maïeul Rouquette a écrit :

Le 20.04.21 à 16:52, Maïeul Rouquette a écrit :

Hum, pourquoi gitea me dit que c'est dans dev/cache alors que c'est 
aussi dans master.


C'est la stable oui.



Et donc maintenant je me rappelle
1. Oui cela aurait du être un commit à part
2. Mais oui j'ai choisi d'utiliser memoization car
a. Si une personne dispose d'une methode de cache memoire, ca va 
ameliorer singulièrement les perfs

b. Si pas de methode de cache memoire, ca change rien

Donc il s'agit de pousser les gens à utiliser memoization, car parfois 
ils ignorent son existence.


Après si cela pose vraiment un problème insolvable, on peut y reflechir.


Ben disons que si je peux éviter d'installer un plugin qui ne me sert à 
rien (parce que mon hébergement ne propose de méthode de cache mémoire), 
j'aime autant oui :)


C'est peut être plutôt une info à mettre en avant dans la doc ?


mouais, c'est passé un peu par hasard, au grès d'un commit foireux, et 
de toute facon comme je reecrit tout sur la v3 (qui cassera certains 
choses), autant l'enlever oui.


Je m'en charge
___
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] Tablesorter nécessite memoization?

2021-04-20 Par sujet Maïeul Rouquette

Le 20.04.21 à 16:40, jeanmarie a écrit :

Salut,

c'est normal que Tablesorter nécessite memoization?
https://git.spip.net/spip-contrib-extensions/formidable_tablesorter/commit/1aaa1d58b9d1451e1116e540228809ab10346502 



                 jeanmarie


Bon alors
1. C'est formidable tablesorter, pas tablesorter
2. C'est une branche de dev et je te deconseille fortement de 
l'installer, vu qu'elle est totalement en dev


Mais pour répondre à ta question
3. Pas impossible qu'à terme cela nécessite oui, mais pas encore sûr.
4. Et c'est vrai que cela n'aurait pas du passer dans ce commit

___
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 Maïeul Rouquette

Le 17.04.21 à 18:40, RastaPopoulos a écrit :

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 :)



je rejoint Rastapopoulos  :)

et merci pour l'actualisation
___
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] Cache, POST et co

2021-04-16 Par sujet Maïeul Rouquette
Le vendredi 16 avril 2021 à 09:23 +0200, Cerdic a écrit :
> Pas de solution si ce n’est de réfléchir à revoir ton api et le
> format de tes URLs pour les simplifier et pouvoir rester en GET.
> 
> C’est pas juste SPIP hein, c’est une convention liée à HTTP même :
> GET c’est pour collecter des données
> POST c’est pour envoyer une modification de données
> 
> A partir du moment où tu prends des libertés avec ça, il y a des
> soucis...
> 
> 
oui, je me doutais que j'allais avoir ca comme réponse. Evidement le
problème c'est que je suis engagé avec une librairie prévu au départ,
je ne sais pas pourquoi, pour POST.

Je vais voir à trouver exactement ce qui rallonge l'url, et si je peux
encoder cela autrement.

___
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] Cache, POST et co

2021-04-15 Par sujet Maïeul Rouquette

Le 15/04/2021 à 20:54, tofulm a écrit :
Pour un fonctionnement un peu identique, j'ai opté par faire une requete 
ajax sur un squelette qui renvoie un json. Comme cela, le squelette est 
mis en cache.



Bah moi aussi c'est une requete AJAX. Simplement cela l'empeche pas 
d'être en POST et pas en GET. Si je faisais en GET, j'aurais des 
problèmes d'URL trop longue. Si je fais en POST, j'ai le problème de non 
mise en cache (c'est ce que j'expliquais dans mon message au début !)

___
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] Cache, POST et co

2021-04-15 Par sujet Maïeul Rouquette

Le 15/04/2021 à 15:31, pierre laszczak a écrit :

Hello,

Je pense qu'il faut éviter le cache sur les POSTS

Quelle est la solution la plus propre pour éviter ce problème ?

- Optimiser les filtres et s'appuyer le plus possible sur sql..


Malheureusement si je fais cela, cela veut dire que je renonce à 
m'appuyer sur la présentation des saisies tels que dféinies dans 
saisies-vues


- Tu peux également essayer de découper ta liste en faisant un inclure 
d'item pour que chaque item ai son propre cache contrairement à la liste.
La chute des performance est souvent liée a une fonction récursive dans 
chaque item.




Heu, je ne vois pas ce que cela changerait, puisque de toute facon à 
partir du moment où il y a un POST, et ben on ne prend rien du tout en 
cache cf


https://git.spip.net/spip/spip/src/branch/master/ecrire/public/cacher.php#L349


De plus en fait chaque item à deja son propre cache : précisement le 
cache SPIP calculé à partir du squelette :)

___
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 Maïeul Rouquette

Le 15/04/2021 à 15:09, Bruno Bergot a écrit :

Hop,




Alors restons en là. C'était ne suggestion :)
___
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] Google FLoC

2021-04-15 Par sujet Maïeul Rouquette

Le 15/04/2021 à 14:14, nicod_ a écrit :

Hello,

vous en avez peut être entendu parler, Federated Learning of Cohorts 
(FLoC) est une nouvelle embrouille de Google pour soit disant éviter les 
cookies tiers mais pister encore plus l'activité des utilisateurs de 
Chrome.


Il y aurait une parade en ajoutant un header HTTP ou une directive dans 
le .htaccess :

https://plausible.io/blog/google-floc

Que diriez vous d'ajouter ça en standard, dans le htaccess.txt ?


Je suis assez pour

___
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] Question sur #CACHE

2021-04-15 Par sujet Maïeul Rouquette

Bonjour,

https://git.spip.net/SPIP/spip/src/branch/master/ecrire/public/balises.php#L1786

Est-ce qu'il n'y aurait pas une erreur dans le PHPDoc

"Le second (par défaut `statique`)"

Or la mise à `statique` ne se fait automatiquement que si l'on a 
`cache-client` (l. 1844)


Maïeul

___
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] Cache, POST et co

2021-04-15 Par sujet Maïeul Rouquette

Bonjour,

j'ai une question concernant la gestion du cache.

## Contexte

recherche d'amélioration des perfs de formidable table sorter

## Explication du processus

Formidable tablesorter envoie une requete AJAX pour récupérer un fichier 
JSON contenant les données à afficher. Cette requete est un peu longue, 
car elle contient des infos sur les filtres, tri, etc. Par conséquent 
impossible de l'envoyer en GET, mais uniquement en POST, bien que cela 
n'influence nullement le contenu de la base, mais uniquement le résultat 
du fichier json.


Ce fichier JSON est généré via différentes fonctions, qui, ultimement, 
appellent `calculer_voir_reponse`, une fonction de formidable.


Cette dernière se base sur les squelettes saisies-vues./*.html pour 
montrer les résultats pour afficher la valeur correctement formaét, 
champ par champ et réponse par réponse.


## Problème

Comme j'envoie ma requete en POST (car paramètres potentiellement très 
long), je n'ai pas de cache (c'est prévu explicitement dans SPIP).


J'ai testé pour voir avec GET, sur un formulaire avec pas mal de 
réponse, on passe de 4 s à 100ms de temps d'attente avant que le serveur 
renvoie sa réponse.


## Question

Quelle est la solution la plups propre pour éviter ce problème ?

Merci d'avance pour vos éclairages

## Remarque

J'ai n'ai aucun souci de cache obsolète car

1. Si on modifie une réponse de formulaire via le tableau, bah il y une 
invalidation générale du cache
2. Comme dit, ma requete AJAX en elle même n'implique pas de 
modification en base



Maïeul

___
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-13 Par sujet Maïeul Rouquette

Le 13/04/2021 à 17:18, Matthieu Marcillaud a écrit :

Le 13/04/2021 à 14:34, Maïeul Rouquette a écrit :

Hop,




Plusieurs remarques. Il ne me semble pas forcément pertinent pour la 
distribution SPIP / SPIP-core (je ne parle pas des plugins ou 
librairies) de suivre semver à tout prix. 

je trouverais bien d'être cohérent, mais ca se discute

Qui plus est, il y a des plugins de retro-compatibilité sur les 
changements apportés (fullcalendar, modèles documents...), et il ne 
semble pas y avoir de choses particulièrement bloquantes.


amah les plugins de retrocompat n'étant pas du code, bah ne peuvent pas 
compter

Donc, là comme ça je dirais moyen bof.


___
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] Une 4.0 plutôt qu'une 3.3

2021-04-13 Par sujet Maïeul Rouquette

Hop,

je reposte ici une discussion qu'on a eu sur IRC.

En logique semver, il y a plus de cassage de comportement entre la 3.2 
et la 3.3 qu'entre la 2.1 et la 3.0. En effet, même si la 3.0 permettait 
d'aller plus loins dans SPIP, de mêmoire le code historique restait 
fonctionnel.


Là on à qui casse:
- la pagination
- les modèles de doc
- potentiellement de renommage de classe dans le privé

Du coup une numérotation 4.0 plutot que 3.3 cela pourrait valoir la 
peine, surtout qu'en terme fonctionnel on a pas mal de chose (que ce 
soit niveau compilo, css, etc).


A réflechir

Maïeul

___
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] [formidable] Merge remote-tracking branch 'origin/master'

2021-04-12 Par sujet Maïeul Rouquette
Le lundi 12 avril 2021 à 16:22 +0200, nicod_ a écrit :
> 
> Sorry...
> J'avais rebase=true, j'ai ajouté ff=only
> 
pas de souci, c'est aussi le fait que la conf par défaut de git est
pourrie :)

___
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] [formidable] Merge remote-tracking branch 'origin/master'

2021-04-12 Par sujet Maïeul Rouquette

Le 12/04/2021 à 15:52, nicod_ a écrit :

spip-contrib-extensions/formidable
-
Par nicod_, le 12 avril 2021 à 15h32min :

Merge remote-tracking branch 'origin/master'



Détails : 
https://git.spip.net/spip-contrib-extensions/formidable/commit/eb644b3a984be7143c2edae2cb14a218b687c31a



Salut Nicod,

pourrais tu mettre dans ton git config global les lignes suivantes

[pull]
ff = only
rebase = true


ca éviterai d'avoit ce genre de message de merge qui n'a en l'occurence 
pas d'interet (si ce n'est de révlé que tu n'es pas toujours à jour sur 
tes versions locales de plugins !)

___
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 Maïeul Rouquette

Le 12/04/2021 à 10:12, RastaPopoulos a écrit :

spip-contrib-extensions/produits
-
Par RastaPopoulos, le 12 avril 2021 à 10h11min :

Un yaml pour inserer modeles mais il faudrait savoir produire le paramètre 
masquer qui est une liste à virgule, à partir d'un tableau php, je ne sais pas 
encore comment ça marche si on peut avoir des pre insertion pour transformer 
des valeurs



https://git.spip.net/spip-contrib-extensions/inserer_modeles/commit/fc78176
ce serait pas ca la solution au pb ?
___
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] Saisie téléversement fichiers

2021-04-06 Par sujet Maïeul Rouquette

Le 06/04/2021 à 12:35, CSI a écrit :

Bonjour,

On utilise une combinaison de La Fabrique + CVT Upload + saisie fichiers 
pour permettre l'upload de fichiers images liés à des objets ... bref 
tout ça marche bien. On se pose la question de la méthode qu'il faudrait 
utiliser pour permettre aux personnes qui ajoutent un ou des fichiers de 
joindre un libellé, une description, bref d'essayer de remplir les 
champs liés à un document, à minima un champ, idéalement tous les champs 
possibles (titre, crédit, description, ...)
On a vu qu'il était possible de "titrer" ou pas le document à partir du 
nom du fichier ...


Si quelqu'un a une piste, merci d'avance !

--
Pierre



CVt upload ne s'occupe que de l'envoi du fichier proprement dit, et ne 
fera que cela. Le traitement (que ce soit pour déplacer un fichier dans 
la mediathèque, ou autre) c'est du ressort du plugin.


Cela étant je suis étonné de votre question : si vous arrivez à mettre 
votre document dans la mediathèque, alors vous devriez être capable 
d'appeler #FORMULAIRE_EDITER_DOCUMENT, non ? A moins que vous ne 
souhaitier que les gens remplissent les infos dès le départ, et dans ce 
cas bah


a. Créer les champs pour rempluir les infos
b. Lorsque dans votre fonction traiter vous faite le transfert vers la 
mediathèque, faire vous même le remplissage des champs de l'objet 
document (via objet_modifier)

___
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 Saisies - fieldset - icone - taille non gérée

2021-04-05 Par sujet Maïeul Rouquette

Le 05/04/2021 à 22:09, Vincent Callies a écrit :
Ce n'est pas dans la documentation mais il y a quelques échanges 
contradictoires sur ce sujet, et après avoir testé j'ai vu que cela 
fonctionnait pour des png.




a oui, mon grep avait foiré. Bon he regarderai à l'occasion

___
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 Saisies - fieldset - icone - taille non gérée

2021-04-05 Par sujet Maïeul Rouquette

Le 05/04/2021 à 10:10, Vincent Callies a écrit :

Bonjour,

Il me semble qu'il y a une amélioration à apporter à Saisies.
Dans le Fieldset, lorsque que l'on défini une icone SVG, la saisie 
affiche une image à sa taille maximum


SPIP 3.3.0-dev
Saisies pour formulaires 3.51.6

Test sur un formulaire de configuration

$saisies = array(
array( // le fieldset
'saisie' => 'fieldset',
'options' => array(
'nom' => 'le_pensebete',
'label' => _T('pensebete:cfg_privee'),
'icone' => 'cadenas-16.png'
), (...)

Vous reproduisez ?

Thrax

hum, je me demande si ce serait pas plutot au core de gerer cela, vu que 
c'est lui qui remplace ton cadenas-16.png en cadenas-xx.svg


___
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] Des nouvelles du plugin Saisies, et de sa documentation

2021-03-30 Par sujet Maïeul Rouquette

Salut à toutes et tous,

si vous suivez l'activité sur git.spip.net, vous n'avez pas manqué de 
voir pas mal d'évolution du côté de saisies, ainsi que des commits 
sobrement intitulés "Saisies : datas->data".


Il m'a paru important de faire le point avec vous sur la question.

1. Concernant l'option 'datas' et l'option 'li_class' des saisies
	- Ces deux options sont considérées comme obsolètes, et ne devraient 
plus être utilisées: préferez 'data' et 'conteneur_class' 
(respectivement plus correctes grammaticalement et plus conforme à la 
structure des formulaires)
	- Pour autant, étant donné la quantité de code dans la nature qui les 
utilisent, la compatibilité ascendante est et sera maintenue
	- Par ailleurs interface champs extras et formidable continueront 
d'utiliser en interne "datas", toujours pour des raisons de 
compatibilité ascendante


2. Concernant les fonctionnalités du plugins saisies
	- Une doc a été publiée sur comment déclarer ses propres saisies : 
https://contrib.spip.net/Creer-ses-propres-saisies, en particulier, 
j'attire votre attention sur la notion "d'héritage de saisies". Cela 
permet de déclarer des saisies "presque comme une autre saisie, mais pas 
tout à fait pareil" (par exemple une saisie "bouton radio" avec des 
choix fixes)
	- Surtout, la documentation principale du plugin a été mise à jour, 
elle explique notamment plus clairement comment profiter des mécanisme 
du plugin pour avoir des vérifications automatiques des saisies 
https://contrib.spip.net/Saisies. Je vous invite à lire cette 
documentation, **même si vous avez l'habitude d'utiliser saisies pour 
créer vos formulaires depuis de longues années**. Cela vous facilitera 
sans doute la vie pour vos futurs formulaires !
	- Enfin les articles relatifs aux "afficher_si" (affichage 
conditionnel), ont été actualisé.


Amicalement, avec un grand merci à JLuc et Rastapopoulos pour la 
relecture de doc.


Maïeul
___
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] erreurs spip

2021-03-23 Par sujet Maïeul Rouquette

Le 23/03/2021 à 19:07, team spipfactoy a écrit :

Pour info

la mise a jour des plugins en tache cron a fait planté la mutualisation, 
je suis obligé de revenir en arriere




visiblementt ta tache cron supporte pas les push/pull force, même sur 
une branche autre que master, mais il faudrait des logs plus précis.


Vu que bon, si c'est juste un git il est capable normalement de s'en 
sortir.


___
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] [grigri] Saisies : datas->data

2021-03-21 Par sujet Maïeul Rouquette

Le 21/03/2021 à 20:08, Maïeul Rouquette a écrit :

spip-contrib-extensions/grigri
-
Par Maïeul Rouquette, le 21 mars 2021 à 20h07min :

Saisies : datas->data


*Modifié*
 formulaires/configurer_grigri.html
 paquet.xml

Détails : 
https://git.spip.net/spip-contrib-extensions/grigri/commit/cb6ccac123fd2c82487bd92747cb1a86316a7600


Salut Cyril,

il est probable que la version 4.0.0 de saisies ne proposera plus la 
compatibilité avec l'ancienne option 'datas', il vaut mieux 'data'.


Je suis en train de corriger sur git.spip.net tout ce que je vois. Mais 
il y en a un paquet.


Du coup si jamais tu as le temps de corriger les tiens, c'est cool 
(sachant que data marche depuis la v 2.7 de saisies)


Maïeul

___
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 3.3 - Pb CSS formulaires

2021-03-21 Par sujet Maïeul Rouquette


> Effectivement, l'affichage est pété, mais on pourrait passer ça en 
> fieldsets non ?
> 

sans doute, mais ca peterait sans doute sur 3.2.

Après on a le projet de faire une branche compatible 3.3 uniquement. Ce
pourrait être l'occasion de l'entamer (en faisant régulièrement, pour
l'instant, des merge dedans depuis master).



___
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 3.3 - Pb CSS formulaires

2021-03-21 Par sujet Maïeul Rouquette

Le 21/03/2021 à 19:32, nicod_ a écrit :



Ben si, c'est dans la charte :
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L140 



non, on ne parle pas de la même chose. Ici je parle bien de la 
possibilité avec saisies de subdiviser un bloc de checkbox en sous bloc


Cad la syntaxe

*Groupe1
cle1|Valeur1
cle2|Valeur2
*Groupe2
cle3|Valeur3
cle4|Valeur4



D'ailleurs, pourquoi les autres checkboxc ont encore un div et pas un 
fieldset ?




parce que cedric a pas encore fait le report je crois. Il attendait 
d'avoir un avis sur le nouveau markup.

___
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 3.3 - Pb CSS formulaires

2021-03-21 Par sujet Maïeul Rouquette

Le 21/03/2021 à 11:21, Eric Lupinacci a écrit :

Hello,

Un commit plus ou moins récent doit provoquer une régression dans la 
visualisation des groupes de checkbox dans les formulaires du privé.
Ils ne sont plus alignés avec les checkbox mais sont décalés 
complètement sur la gauche avec le label de la saisie.


Voir un exemple avec le lien : https://imgur.com/a/AtSKvRQ 



Je ne sais pas comment corriger, donc si quelqu'un a une idée.

++
Eric

ah mais attends, j'avais pas capté à la première vue de la capture 
d'écran : les groupes de checkbox, pour le coup, c'est vraiment propre à 
saisies. Ca ne fait pas partie de la norme des formulaires SPIP (même 
si... après tout cela pourrait !)


Du coup il faudrait sans doute voir à en modifier le markup pour SPIP 
3.3. Sans doute faudrait-il faire comme pour les radios, encapsulé dans 
un fieldset.


___
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-19 Par sujet Maïeul Rouquette
Le vendredi 19 mars 2021 à 18:04 +0100, nicod_ a écrit :
> Le 19/03/2021 à 16:24, Maïeul Rouquette a écrit :
> > Et donc la version 1.4.2 du plugin inserer_modeles corrige ce bug
> > tout 
> > en incorporant la raison d'être du commit qui l'a inséré.
> > 
> > Merci à Cedric pour le diag et la solution.
> 
> Je vais faire la mise à jour passque là, 4.4 Go dans cache-js, ça
> fait 
> un peu beaucoup ! :)
> 
oui je suis désolé :) pourtant j'avais demandé une relecture avant
d'intégrer ce commit... j'avais du tout compris comment fonctionnaire
la barre d'outils

___
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-19 Par sujet Maïeul Rouquette

Le 17/03/2021 à 16:27, Jean Christophe Villeneuve a écrit :
En tout cas je confirme qu'une fois le plugin "Insérer modeles" 
désactivé, je n'ai plus de nouveau fichiers créés dans cache-js depuis 
presqu'une heure maintenant.


Merci pour le debug et bon code pour les corrections.

JC




Et donc la version 1.4.2 du plugin inserer_modeles corrige ce bug tout 
en incorporant la raison d'être du commit qui l'a inséré.


Merci à Cedric pour le diag et la solution.
___
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-18 Par sujet Maïeul Rouquette
Le jeudi 18 mars 2021 à 09:38 +0100, Cerdic a écrit :
> Si ça marche comme ça tant mieux, mais amha ça doit pas marcher
> partout car le hidden avec le id_xx clé primaire de l’objet édité
> c’est pas du tout un truc standard ni nécessaire. Il est présent sur
> les objets historiques pour des raisons historiques, mais il a aucune
> utilité (même si je vois que Fabrique le génère aussi…)
> 
ah ! j'ignorais (mais je n'était pas pour autant satisfait du fait de
cherche le hidden, cf. mon message de commit)
> 
> Voire même le plugin peut inserer côté PHP en hidden l’URL de
> inserer_modeles à utiliser sur le formulaire en fonction des clés
> primaires dispos, et ça simplifie encore plus le JS qui sera encore
> plus stable
> 
> --
> Cédric
> 
Qu'entend tu par stable ? Là le JS ne varie plus en fonction de l'url
d'appel. Il varie en revanche si on ajoute ou enlève des modèles, mais
je vois mal comment faire autrement.

En revanche si par stable tu veux dire "predictible" dans son
comportement effectivement la solution de l'url en hidden est la plus
propre.

Merci je vais faire cela et te tien au jus.

___
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 Maïeul Rouquette

Le 17/03/2021 à 16:18, Cerdic a écrit :

non non non, le problème ne vient pas de porte-plume.
Il permet de modifier le JS pour insérer des boutons et utiliser des 
infos de config pour ce faire, et c’est le pourquoi du JS en squelette 
modifiable via pipeline.


oui d'accord, mais moi je pensais que le porte plume générait une 
structure en data-truc et qu'ensuite on avait un code js fixe. Mais 
effectivement maintenant que j'ai vu concrètement, cela parait assez 
logique la manière dont cela marche


Mais bon là à partir du moment où on insère dedans du contenu qui change 
à chaque URL comment est-ce qu’on peut supposer que ça marche ?
Et je redis, ton commit n’a fait que généraliser ce qu’il y avait avant, 
en l’empirant certes, mais le problème était déjà là.



j'ai reverifier dans le code : non, avant le js était stable

Quoi qu'il en soit j'ai fait une branche ici qui

1) permet d'avoir le but initial du commit, à savoir passer le 
id_objet_du_formulaire à la modalbox quelque soit l'objet en question

2) sans pour autant generer un js par id_objet_du_formulaire

https://git.spip.net/spip-contrib-extensions/inserer_modeles/compare/master...tout_objet

Marcimat et Rastapopoulos m'ont deja donné leur avis, et j'ai corrigé 
suivant leur idée. Mais une troisième relecture serait précieuse.



___
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 Maïeul Rouquette

Le 17/03/2021 à 15:39, Cerdic a écrit :

Ah ben tu m’étonnes...

le plugin inserer_modeles modifie donc le JS du porte-plume en lui 
insérant dedans du JS *avec* une URL qui reprends peu ou prou tous les 
args de la page en cours.
Autant dire que c’est une hérésie totale : chaque URL de l’espace privé 
génère une version de JS pour le porte plume, qui génère donc une 
version de JS compressée pour l’espace privé.


De ce que je vois c’était déjà pas beau avant mais ce commit a fini de 
clouer le cercueil 
https://git.spip.net/spip-contrib-extensions/inserer_modeles/commit/98f968594986746ec2eb26bd354e67f63f3266ea 





Arf, oui. Je ne pensais pas du tout que le le js du porte plume était 
dynamique. Sinon je n'aurais pas codé comme cela.


Je reverte ce commit, et j'essaie de voir comment l'écrire plus 
proprement pour répondre au besoin en full JS.


Cela étant le problème est donc aussi du côté de porte plume qui generer 
un js différent selon ce que les gens lui ont fourni dans ses pipelines.

___
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 Maïeul Rouquette

Le 17/03/2021 à 15:30, Jean Christophe Villeneuve a écrit :

Et j'ai recherché le forum 6039 et il date d'avril 2016 ...


JC

mouais, mais ca peut importe. On dirait qu'il y un js par page generé ou 
tu appeler inserer_modele (donc sans doute par page où il y a 
unformulaire de réponse aux forums).


C'est un bug quelque part, sans doute dans inserer_modeles.

J'essaie de voir cela après ma sieste
___
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 Maïeul Rouquette

Le 17/03/2021 à 15:05, Jean Christophe Villeneuve a écrit :

Question de béotien : c'est quoi les fichiers "avec un hash" ?

Oui, le porte-plume est appelé côté public et oui ça le fait surtout 
avec lui (1682 fichiers sur les 1715)


JC




Un hash c'est une sorte de résumé informatique d'un texte. SOuvent une 
suite de caractère melangt lettre et chiffe


ici 01c79be019f1d0eb15acb6376e4f02ba.js bah typiquement 
01c79be019f1d0eb15acb6376e4f02ba c'est un hash (qui condense en gros le 
nom des fichiers JS compacté)


___
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 Maïeul Rouquette

Le 17/03/2021 à 14:00, Jean-Christophe Villeneuve a écrit :
Ok mais comparer quoi exactement car j'ai environ 1700 fichiers 
actuellement dans /cache-js pour un total de 50Mo alors que je l'ai vidé 
hier vers 16h.


Quelques exemples :

des dizaines de
jsdyn-javascript_porte_plume_start_js-x.js
et de
jsdyn-javascript_porte_plume_start_js-x.js.last
mais qui ne font que 26 ko

d'autres du type
01c79be019f1d0eb15acb6376e4f02ba.js (plus de 800ko, voire 1.3 Mo)
et
01c79be019f1d0eb15acb6376e4f02ba.js.gz (environ 220ko ou 310ko )

plus d'autres encore


JC



ah ! Ca le fait qu'avec le porteplume ? ou bien d'autres ? (laisse 
tomber pour l'instant ceux avec un hash).  Le porte plume est appelé 
côté public ?


Tu peux comparer entre 2 versions avec le même nom par exemple.
___
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-16 Par sujet Maïeul Rouquette

Le 16/03/2021 à 20:16, Jean-Christophe Villeneuve a écrit :

Le squelette utilisé est le plugin Escal.

JC



quels sont les différences entre les différents js generés ? ca 
permettrait de voir si l'env joue un role

___
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] Erreur Newsletter

2021-03-12 Par sujet Maïeul Rouquette

Le 12/03/2021 à 23:48, Stephane Santon a écrit :

Bonsoir,

Le 12/03/2021 à 23:43, Maïeul Rouquette a écrit :

ou bien tu a le bug de l'opcache d'ovh

essie deja dans Maintenance Technique de réparer les tables, ca 
tentera aussi de créer les tables manquante...

Ah ben oui, après "Réparer la base de données" ça fonctionne...
MERCI ! :-)

Je suppose qu'il n'y a rien d'autre à faire, il faut le prendre comme ça ?
Y aura-t-il d'autres effets de bord ??

Merci

pas à ma connaissance. C'est un bug qui est relevé dans le suivi des 
bugs SPIP, mais pas évident à résoudre de ce que j'ai compris.


Après... je ne l'ai jamais experimenté moi même...
___
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] Erreur Newsletter

2021-03-12 Par sujet Maïeul Rouquette

Le 12/03/2021 à 23:36, Stephane Santon a écrit :
Ah ben d'ailleurs à l'appel de Edition |Infolettres, la table 
newsletters n'a même pas été créée, donc pb d'install...

Je soupçonne un bug lié au préfixe des tables...


ou bien tu a le bug de l'opcache d'ovh

essie deja dans Maintenance Technique de réparer les tables, ca tentera 
aussi de créer les tables manquante...

___
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] Besoin de test sur afficher_si

2021-03-11 Par sujet Maïeul Rouquette

Le 11/03/2021 à 10:29, Philippe Boussin a écrit :

Bonjour Maïeul,

J'utilise Saisies avec Formidable sur un spip 3.2.9 et je rencontre un 
bug depuis la mise à jour du plugin Saisies en version 3.49.1 !
La css de jquery_ui n'est plus ajoutée au head quand on a une saisie 
date, apparemment depuis ce commit dans Saisies: 
https://git.spip.net/spip-contrib-extensions/saisies/commit/55d8ca706b567daf7720d5c35d0c85d27da42366 
 
.


Je pense que le problème se situe dans saisies_pipelines.php à la ligne 
99 au niveau du !$tester_saisies !?!


Philippe B.




Arf oui, on a du se tromper à un moment. J'ai voulu debuguer un truc et 
j'ai rajouté un autre bug.


Bref, la v3.50.2 corrige le problème.
___
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 Maïeul Rouquette



Ce serait top que ce formulaire gère toutes ces inscriptions, certaines 
étant optionnelles.


ALors oui, si c'est pour avoir une seule interface ce serait top. Je 
comprend mieux l'idée :)

___
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 Maïeul Rouquette


> Ce serait possible sur Gitea bien sûr, mais c'est développé en Go.
> S'il y a des volontaires... c'est open source :p
> 

Oui alors il y avait un sous entendu: sans avoir à écrire nous même la
partie. Mais j'avoue ne pas trop comprendre comment est structuré la
doc de gitea, et du coup je sais pas si cela existe ou pas :)

___
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 Maïeul Rouquette

Le 09/03/2021 à 13:48, nicod_ a écrit :

Le 08/03/2021 à 19:34, Eric Lupinacci a écrit :
D'ailleurs on pourrait mettre en place un processus (formulaire) à 
partir d'un autre site comme Contrib en utilisant l'API REST de Gitea.
Ce serait plus pérenne et peut-être que ça nous permettrait de 
personnaliser comme on veut.


Ce serait pas mal ça oui.
Avec signature de la charte, et confirmation par mail avant de créer le 
compte (antispam).




je trouverais cela bizarre de faire par un autre site, mais si on ne 
peut pas techniquement le faire depuis gitea, oui...

___
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] session_get() avec un temps de retard

2021-03-08 Par sujet Maïeul Rouquette
Salut Cedric,

oui les sessions sont stockées dans un fichier php, dans tmp/sessions.
Il y a moyen de faire facilement autrement ? (C'est un domaine que je
connais pour ainsi dire pas du tout). 

Je met la personne en question en copie, elle pourra en dire plus sur
sa config.

Maïeul
Le lundi 08 mars 2021 à 09:21 +0100, Cerdic a écrit :
> Je suppose que c’est encore un coup d’opcode cache configuré de
> manière très agressive sur les mutus OVH, les sessions étant stockées
> dans un fichier .php ?
> 
> --
> Cédric
> 

___
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] session_get() avec un temps de retard

2021-03-07 Par sujet Maïeul Rouquette

Holla,

une personne signalait un bug dans les formulaires de construction de 
formulaire, type formidable ou interface graphique de champ extra.


J'ai eu accès à un site de dev.

Il s'avère que le contenu renvoyé par session_get() ne correspondait pas 
à ce qu'on trouvait dans le fichier de session. Il y avait toujours "un 
temps de retard".


Je lui ai signalé, en soupconnant un problème de config serveur.
La personne vient de me dire par courriel

> Pour info, je viens d'essayer d'utiliser le moteur php-cgi d'OVH 
(sommes sur un mutu perf 3) et cela semble corriger le problème.

Nous étions avant en moteur PHP, ce qui active PHP-FPM (fastCGI).
Problème, le site sera moins performant, surtout en cas de trafic important.

Est-ce que cela dit quelque chose à quelqu'un ?

Maïeul

___
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] Catégories vos saisies

2021-03-07 Par sujet Maïeul Rouquette

Salut,

et voilà, après moult débat, le version 3.48.0 du plugin saisies 
catégorise enfin les saisies.


Il est donc temps d'affecter, si tel est votre souhait, des catégories 
aux saisies des plugins que vous maintenez (je me suis permis de le 
faire pour les saisies du plugin agenda et du plugin CVT-Upload).


Voici comment faire (note : cela est documenté dans l'article, non 
encore publié pour cause d'il faut finir un plugin qui sert d'exemple, 
suivant : https://contrib.spip.net/ecrire/?exec=article_article=5272).


##  D'abord, la liste des catégories



|Clé informatique|Libellé humain|Exemple de saisie concernée|
|libre|Champ libre|input
|choix|Choix restreint|radio|
|structure|Structure|fieldset|
|objet|Contenu éditorial|selecteur_article|
|defaut|Divers|hidden|

## Ensuite l'affectation
La saisie email possède les entrées suivantes dans son 
.yaml :



categorie:
  type: 'libre'
  rang: 10


En revanche la saisie  input possède les entrées suivantes 
dans son .yaml :




categorie:
  type: 'libre'


La saisie input de range 0 (par défaut) 
apparaît avant la saisie email au sein de la catégorie 
libre.


## Créer ses propres catégories

Le pipeline saisies_lister_categories permet d'ajouter (ou 
le cas échéant, de modifier ou supprimer) une ou plusieurs catégories de 
saisie.


Par exemple l'association Planète Sciences ajouter une catégorie pour 
les saisies propres à ses activités, avant toutes les autres catégories



/**
 * Ajout d'une catégorie de saisies plasci
 * @param array $flux
 * @return $flux modifié
**/
function plasci_saisies_lister_categories($flux) {
$plasci = array(
'plasci' => array(
'nom' => _T('plasci:plasci')
)
);
$flux = array_merge($plasci, $flux);//Mettre plasci en premier
return $flux;
}


Nous avons ajouté une catégorie dont la clé est plasci et 
dont le nom humain est _T('plasci:plasci'). Pour l'instant, 
les catégories n'ont comme seule propriété que leur nom, mais cela 
pourrait changer à l'avenir.


À noter qu'une sécurité est appliquée, afin de s'assurer que la 
catégorie defaut se trouve systématiquement à la fin.



## Réaffecter des catégories

Pour vos besoins perso, pas pour les plugins communautaires !

Il est parfois utile de modifier la liste des saisies proposés, soit 
pour réaffecter des catégories, soit pour supprimer certaines saisies. 
Pour ce faire, on peut utiliser le pipeline 
saisies_lister_disponibles.


Par exemple, pour alléger son interface, Planète Sciences affecte la 
saisie evenements du plugin agenda à la catégorie 
plasci, et supprime toutes les saisies de catégorie 
objet.



/**
 * Met la saisie evenements dans la catégorie plasci
 * Supprime toute les saisies objets
 * @param array $flux
 * @return $flux
**/
function plasci_saisies_lister_disponibles($flux) {
foreach ($flux as $saisie => &$description) {
if ($saisie == 'evenements') {
$description['categorie']['type'] = 'plasci';
$description['categorie']['rang'] = -10;
		} elseif (isset($description['categorie']['type']) and 
$description['categorie']['type'] == 'objet') {

unset($flux[$saisie]);
}
}
return $flux;
}


## PS

Si vous utilisez l'un ou l'autre des 2 pipelines ci-dessus dans un 
pipeline communautaire, je suis preneur, pour éviter de donner du code 
de Planète Sciences dans l'article de doc.


Maïeul


___
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 Maïeul Rouquette





1) _Liste_
- *spip-info* : à supprimer de la boussole
Si on le supprimer de la boussole il faudrait supprimer le site non? 
Y-a-il encore des gens qu'en occupe ?
- *stats.spip.net  >* : à ajouter à la boussole

oui pq pas
- *git.spip.net  > *: à ajouter à la boussole

clairement oui

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


clairement oui

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:




oui je suis d'accord avec Rasta, mais là j'ai pas d'idée. Peut être par 
profil "Documentation" vs "Code et co" (à trouver le bon terme), mais 
même cela me satisfait pas trop

3) _Liens particuliers dans la bande de navigation_
Il serait bien d'ajouter un lien vers la charte par exemple avec un item
Charte à droite de la bande ou alors en cliquant sur le logo à gauche.

oui + 1 pour un lien clair (et multilingue) vers la charte
D'ailleurs je ne vois pas l'intérêt que ce logo renvoie vers spip.net 
.

parce uqe c'est le site general de spip ?
Pour ce qui est de la charte, il faudrait que l'affichage soit cohérent 
avec la langue utilisée.


Un truc aussi étrange c'est que cette bande ne renvoie jamais vers la 
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 .



bof, je mettrais plutot une jolie boussolle tout à droite

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

++
Eric




___
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 Maïeul Rouquette

Le 04/03/2021 à 22:56, Matthieu Marcillaud a écrit :

Le 04/03/2021 à 19:12, CSI a écrit :

Bonjour,


[...]


Donc perso si je suis tout à fait d'accord pour quitter PHP 5.6, je 
préfèrerai que la nouvelle limite basse soit 7.0 ou alors que 3.2 soit 
préalablement rendu compatible avec 7.3 (j'en ai qui tournent sur 7.3
Ce n'est pas idiot d'améliorer le support de PHP 7.3 pour SPIP 3.2, et 
de mettre 7.3 mini pour SPIP 3.3… Comme ça, ça permet la Debian 10 des 
deux côtés.


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.




C'est super ! Merci beaucoup

Peut être aussi 
https://git.spip.net/spip/spip/commit/e888c6843a4b849cb2b42c550d4696264d5c6de0 
à reporté (cf https://git.spip.net/spip/spip/pulls/72)

___
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 Maïeul Rouquette

Le 04/03/2021 à 17:15, Matthieu Marcillaud a écrit :

Hello,

Il y a maintenant longtemps, on avait monté la version minimum de PHP 
requise pour SPIP 3.3 à PHP 5.6 parce que (de mémoire) quelques 
distributions Debian pouvaient peut être être encore dessus.


On est quelques un·es à se dire que bon, le temps est passé encore 
(comme d'hab) et que mettre (au moins) PHP 7.1 minimum apporterait un 
certain réconfort (notamment ça permet de typer les arguments et retours 
de fonctions avec goût — 
https://mlocati.github.io/articles/php-type-hinting.html). PHP 7.1 est 
sorti en fin 2016 (et n'est plus maintenu par ailleurs non plus).


Et ça éviterait de se maintenir une maintenance php 5.6 pour 10 ans peut 
être :)


Les versions PHP maintenues sont 7.3+ à ce jour.

Chez Debian, les versions PHP par défaut : https://wiki.debian.org/PHP

Jessie 8 — 5.6.40 (plus maintenu)
Stretch 9 — 7.0 (maintenu jusque 2022)
Buster 10 — 7.3

Des avis avisés ?

MM.



Je plussoie de cesser la compatibilité PHP < 7.1. Voir même si on voyait 
des fonctionnalité que compatible 7.2 **indispensables**, de demander 
7.2 (mais je ne connais pas assez le core pour me prononcer !)

___
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] Besoin de test sur afficher_si

2021-03-03 Par sujet Maïeul Rouquette

Le 03/03/2021 à 13:05, Maïeul Rouquette a écrit :



Cela fait 10-12 jours que je plugin est en test sur un site. A part un 
bug, je n'ai pas eu de retour negatif.





Oups, on me fait remarquer que j'ai oublié de préciser que le bug a bien 
sûr été corrigé depuis :p

___
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 Maïeul Rouquette


> Soit, mais je ne vois pas le rapport avec l'inscription ouverte.
> 

effectivement c'est indépendant.

___
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] Besoin de test sur afficher_si

2021-03-03 Par sujet Maïeul Rouquette

Salut à tous et toutes,

suites à diverses remarques, j'ai réécrit la partie javascript des 
afficher_si du plugin saisies. L'idée étant de faciliter l'ajout de 
tests depuis de nouveau types de saisies (auparavent il fallait passer 
par un pipeline !).


Cela fait 10-12 jours que je plugin est en test sur un site. A part un 
bug, je n'ai pas eu de retour negatif.


Y-a-il des bonnes ames pour tester la branche dev/issues51 ? La syntaxe 
ne change pas, seule l'implémentation sous-jacent change.


Merci

Maïeul

___
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 Maïeul Rouquette




Oui ça pourrait être une façon.
Mais en quoi c'est rebutant aujourd'hui ?
On a des retours ?
Parce qu'en général on réagit assez vite pour l'ouverture du compte et 
il n'y a pas des tonnes de demandes.


En tout cas, sans protection en tout je ne suis pas vraiment favorable à 
une inscription ouverte.


++
Eric




Bah en gros
1. C'est pas documenté (mais bon ca on pourrait résoudre)
2. Quand je contribue à un projet libre juste pour ouvrir des tickets 
(parce que je connais pas le language derrière, parce que j'ai pas envie 
de m'impliquer en codant), j'ai pas forcément envie de me taper tous les 
commits et les discussions de tout le monde sur les avancés : je veux 
juste ouvrir un ticket.



___
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 Maïeul Rouquette

Le 02/03/2021 à 12:52, RastaPopoulos a écrit :


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.



Que dire à part que j'approuve totalement cette idée de processus.
___
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] Compatible spip 3.3 borne maximale pour bootstrap

2021-03-02 Par sujet Maïeul Rouquette
my bad ! je ne l'avais pas vu :)

Le mardi 02 mars 2021 à 10:24 +0100, Rainer Müller a écrit :
> La branche je l'avais fait pour le pull request, elle peut ètre
> éliminé 
> après coup
> 
> 

___
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] Compatible spip 3.3 borne maximale pour bootstrap

2021-03-02 Par sujet Maïeul Rouquette

Le 02/03/2021 à 08:00, Rainer Müller a écrit :
Oui, exactement. J'ai plusieurs sites en bootstrap 2 et je commence 
gentiment à les migrer sur spip 3.3




Si je comprend bien, ta branche concerne la compatibilité de la version 
bootstrap2 (c'est à dire le plugin dans sa version 0.y.z) avec spip 3.3. 
Dans ce cas là, il me semble qu'il n'y pas lieu de faire une branche 
spéciale spip 3.3 (sauf si par ailleurs tu dois changer des chsoes), 
mais plutôt de mettre à jour la branche 0, qui est la branche compatible 
bootstap 2.


Autrement dit : le problème n'est pas d'avoir une branche pour la 
version 0 compatible bootstap 2, mais que cette branche ait un nom qui 
ne soit pas trompeur.

___
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-24 Par sujet Maïeul Rouquette

Le 24/02/2021 à 08:54, RastaPopoulos a écrit :

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

oui, la seulle question qui se pose pour moi c'est : où est-ce qu'on la 
rédiger ? sur spip.net ? sur l'un des 2 pads ouverts ?

___
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] [inserer_modeles] Correction pour SPIP 3.3 : Il faut passer le type : ajax (...)

2021-02-23 Par sujet Maïeul Rouquette

Le 23/02/2021 à 18:10, Matthieu Marcillaud a écrit :

spip-contrib-extensions/inserer_modeles
-
Par Matthieu Marcillaud, le 23 février 2021 à 18h07min :

Correction pour SPIP 3.3 : Il faut passer le type: ajax aux options de la 
mediabox pour ne pas que ça utilise une iframe (qui n'aura alors aucun style)


*Modifié*
 inserer_modeles_pipelines.php
 paquet.xml
 prive/style_prive_plugin_inserer_modeles.html

Détails : 
https://git.spip.net/spip-contrib-extensions/inserer_modeles/commit/9eba5fd9ea20ce1d959733fa23ae55c011c29289



Comme je disais sur IRC : je me demande si cette rupture de compat entre 
les 2 versions de mediabox ne devrait pas plutot être résolu dans le 
plugin-dist/mediabox

___
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 Maïeul Rouquette

Le 23/02/2021 à 18:47, JLuc a écrit :

Le 23/02/2021 à 17:07, Maïeul Rouquette a écrit :
 > Le 23/02/2021 à 16:41, Matthieu Marcillaud a écrit :
 >> Le 23/02/2021 à 15:45, JLuc a écrit :
 >>> J'ai dressé une liste des features ou évolution restant à 
documenter pour SPIP 3.3 en partant également des commits
 >>> les plus récents, depuis décembre en fait : 
http://spip.pastebin.fr/85755

 >>> À poursuivre donc.
 >> Merci. Il y a un article sur spip.net aussi à compléter au fur et à 
mesure.
 >> Il y a au moins à ajouter les boucles anonymes et les parties , 
et certainement plein d'autres choses.

 >> MM.

 > et moi j'avais continuer à compléter le pad.
 > Du coup... je suis perdu. On met où et quoi ?
Par rapport à quoi es tu perdu ?


par rapport aux endroits où on note pour les humain·e·s les nouveautés

Le pad

https://semestriel.framapad.org/p/spip33beta
___
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 Maïeul Rouquette

Le 23/02/2021 à 16:41, Matthieu Marcillaud a écrit :

Le 23/02/2021 à 15:45, JLuc a écrit :

J'ai dressé une liste des features ou évolution restant à documenter 
pour SPIP 3.3 en partant également des commits les plus récents, 
depuis décembre en fait : http://spip.pastebin.fr/85755

À poursuivre donc.


Merci. Il y a un article sur spip.net aussi à compléter au fur et à mesure.

Il y a au moins à ajouter les boucles anonymes et les parties , et 
certainement plein d'autres choses.


MM.


et moi j'avais continuer à complter le pad.

Du coup... je suis perdu. On met où et quoi ?
___
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] Suite à #4560 on applique l'attribut role sur les retour (...)

2021-02-19 Par sujet Maïeul Rouquette

Le 18/02/2021 à 14:26, Maïeul Rouquette a écrit :

Le 18/02/2021 à 13:34, nicod_ a écrit :

Le 17/02/2021 à 14:21, Cerdic a écrit :

spip/spip
-
Par Cerdic, le 17 février 2021 à 14h20min :

Suite à #4560 on applique l'attribut role sur les retour ok/erreur de 
tous les formulaires


Détails : 
https://git.spip.net/spip/spip/commit/f7b2ca003425c33b1c9a086833e332f1c1a17a39 



Je note ça pour mémoire : il faudrait mettre à jour Formidable et la 
Fabrique aussi.




pour Formidable c'est fait ici 
https://git.spip.net/spip-contrib-extensions/formidable/commit/9f3886354117623dc09efffb77c887d9c01c5ebc 



la question que je ne sais pas : est-ce qu'il faut aussi les roles sur 
les erreurs individuelles de saisies ?




la réponse est oui. et la seconde réponse est : spip s'en chargera tout seul

___
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] Suite à #4560 on applique l'attribut role sur les retour (...)

2021-02-18 Par sujet Maïeul Rouquette

Le 18/02/2021 à 13:34, nicod_ a écrit :

Le 17/02/2021 à 14:21, Cerdic a écrit :

spip/spip
-
Par Cerdic, le 17 février 2021 à 14h20min :

Suite à #4560 on applique l'attribut role sur les retour ok/erreur de 
tous les formulaires


Détails : 
https://git.spip.net/spip/spip/commit/f7b2ca003425c33b1c9a086833e332f1c1a17a39 



Je note ça pour mémoire : il faudrait mettre à jour Formidable et la 
Fabrique aussi.




pour Formidable c'est fait ici 
https://git.spip.net/spip-contrib-extensions/formidable/commit/9f3886354117623dc09efffb77c887d9c01c5ebc


la question que je ne sais pas : est-ce qu'il faut aussi les roles sur 
les erreurs individuelles de saisies ?



___
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 3.3 + SPIP bonux = erreur 500

2021-02-17 Par sujet Maïeul Rouquette

Le 17/02/2021 à 18:51, jeanmarie a écrit :

Le 17/02/2021 à 18:36, Maïeul Rouquette a écrit :

Le 17/02/2021 à 18:22, jeanmarie a écrit :

En faisant la mise à jour en local, j'ai une erreur :

*Fatal error*: Cannot redeclare critere_fusion_supprimer_dist() 
(previously declared in 
C:\www\radio-u\plugins\auto\spip_bonux\v3.5.5\public\spip_bonux_criteres.php:179) 
in *C:\www\radio-u\ecrire\public\criteres.php* on line *618*

ca a été corrigé entre temps :)


J'ai le souci avec Bonux à jour également : *Fatal error*: Cannot 
redeclare critere_fusion_supprimer_dist() (previously declared in 
C:\www\radio-u\plugins\auto\spip_bonux\v3.7.0\public\spip_bonux_criteres.php:180) 
in *C:\www\radio-u\ecrire\public\criteres.php* on line *618*



J'ai parlé trop vite : la correction a été proposée, mais pas encore 
validée.


https://git.spip.net/spip/spip/pulls/116

tu n'a qu'à l'appliquer manuellement ou bbien attendra la nouvelle 
version (rappel spip 3.3 => dev)

___
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 3.3 + SPIP bonux = erreur 500

2021-02-17 Par sujet Maïeul Rouquette

Le 17/02/2021 à 18:22, jeanmarie a écrit :

En faisant la mise à jour en local, j'ai une erreur :

*Fatal error*: Cannot redeclare critere_fusion_supprimer_dist() 
(previously declared in 
C:\www\radio-u\plugins\auto\spip_bonux\v3.5.5\public\spip_bonux_criteres.php:179) 
in *C:\www\radio-u\ecrire\public\criteres.php* on line *618*


J'aurais dû commencer par là :)*
*

*
*

Le 17/02/2021 à 18:13, jeanmarie a écrit :


ca a été corrigé entre temps :)

___
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] 2 commits

2021-02-16 Par sujet Maïeul Rouquette

Le 16/02/2021 à 19:24, Cerdic a écrit :
Non j’avais pas vu et c’est ballot parce que spout a l’air beaucoup 
mieux (maintenue et plus moderne) que le vieux bout de lib que j’ai 
trouvé… :(


--
Cédric
Le 16 févr. 2021 à 16:56 +0100, RealET , a écrit :


je l'utilise en tant que lib dans formidable tablesorter, et c'est 
appréciable de pouvoir generer en un coup de cuillère à pot plusieurs 
sorti (ODT, XLS, CSV) tout en profitant des fonctionnalités de chacune 
d'entre elles (genre : la mise en forme du tableur ...)

___
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] [modeles_media] compatible 3.3, bien que la problématique auquel répond (...)

2021-02-12 Par sujet Maïeul Rouquette

Le 12/02/2021 à 20:03, nicod_ a écrit :

Le 12/02/2021 à 12:31, Maïeul Rouquette a écrit :

spip-contrib-extensions/modeles_media
-
Par Maïeul Rouquette, le 12 février 2021 à 12h29min :

compatible 3.3, bien que la problématique auquel répond ce plugin n'a 
plus lieu d'être, mais cela permet de contineur à l'utiliser sans 
devoir tout changer



*Modifié*
 paquet.xml

Détails : 
https://git.spip.net/spip-contrib-extensions/modeles_media/commit/69df94c6ab2f266de1462fbecd11235f402c325e 






Pourquoi "la problématique auquel répond ce plugin n'a plus lieu d'être" ?
On peut faire tout ce qu'il fait en natif maintenant ?

il me semble non ? en tout cas on n'a plus le souci de la forme qui 
varie de manière aléatoire selon la taille de l'image, le portolio et 
l'âge du capitaine :-)


possible que d'autres features du plugin manquent (par exemple le choix 
en contexte du titre), mais j'ai simplifié à outrance dans le message.





___
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] [dist] Fix https://core.spip.net/issues/3431 : utiliser (...)

2021-02-09 Par sujet Maïeul Rouquette

Le 09/02/2021 à 20:16, nicod_ a écrit :

Le 09/02/2021 à 20:01, Bruno Bergot a écrit :

Filtre svg_redimensionner non défini ^^

Ce filtre n'est pas dispo dans le public ?


Effectivement, pas connecté ça casse.

En même temps, ce serait pas mal de bénéficier par défaut de toutes les 
fonctions de inc/svg.php dans le public non ?


On pourrait l'inclure dans inc/filtre_image_mini ?

Cedric, un avis ?


+1 :)

___
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 Maïeul Rouquette




Bref,
1) il a déjà accepté la charte
2) il a perdu son compte
3) son compte a été réactivé
4) est-il bien nécessaire de lui demander de ré-accepter cette charte ?
5) et en quoi serait-ce juste dans ces conditions de fermer son compte ?
6) en particulier, est-ce que ça ne serait pas en contradiction avec 2 
points centraux de la charte : "promouvoir et défendre la liberté 
d'expression de tous sur Internet" et "le respect de l'identité de 
chacun" ?





Je ne répondrais pas sur l'aspect historique, ce qu'à fait Rasta, mais 
sur certains de tes points



4) oui, dans la mesure où certains de ses écrits récents allaient en 
contradiction avec
5-6) a ce moment là si on ne peut pas sanctionner parce qu'il faut 
accepter tout le monde, alors à quoi sert une charte ?

___
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-02 Par sujet Maïeul Rouquette

Le 03/02/2021 à 00:12, nicod_ a écrit :

Le 22/01/2021 à 14:21, nicod_ a écrit :

Bon, pas de réponse, pas d'approbation de la charte, ça n'est pas encore 
arrivé je crois.

On fait quoi dans ce cas, on supprime le compte en question ?
Je pense que ce serait légitime.


cela me le semblerait aussi
___
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] [inserer_modeles ↪ dev_baloo] 2 commits

2021-02-02 Par sujet Maïeul Rouquette

Le 02/02/2021 à 13:52, nicod_ a écrit :

Salut Maïeul,

est ce que tu as testé côté public, avec les crayons ?




salut nicod, non, pas pensé. Mais tu fait bien de signaler (même si je 
t'avais expressément bipé sur la PR !). Ca provoquait bien un bug. Là 
c'est résolu avec mon dernier commit.


___
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 Maïeul Rouquette

Le 18/01/2021 à 16:09, RastaPopoulos a écrit :

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.

Je plussoie. Quoi que l'on pense du comportement de Joël (et je pense 
que j'étais en première ligne pour montrer que je le trouvais totalement 
inadapté) aucune décision unilatérale à ce sujet (aka sans commission) 
serait contraire à la charte.


Mais cela tombe bien, cela n'a pas été le cas.

Cela étant, La piqûre de rappel de Cédric était sans doute nécessaire 
sur le fond, même si la forme a pu semer le trouble le trouble.


La charte de SPIP rappel des valeurs historiques de SPIP qui n'ont été 
formalisées que récemment dans cette charte. La modalité d'emploi de la 
charte, et notamment de la manière de gérer les violations de la charte, 
reste encore à mesurer à l'épreuve des faits. J'espère que le cas Joël 
ne nous y obligera pas.

___
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-01-18 Par sujet Maïeul Rouquette

Le 18/01/2021 à 15:44, BERTRAND Joël a écrit :

nicod_ a écrit :

Le 18/01/2021 à 09:53, Cerdic a écrit :

Hello Joël,


Bonjour à tous,

Tous les mots de la réponse ont été scrupuleusement pesés. Elle n'est
pas là pour polémiquer, vous ne m'en voudrez donc pas de ne pas répondre
à des messages non constructifs.


je vais faire mon lourdingue, mais au vu des discussions récentes que
tu as initié ça me parait pas superflu...


+1, merci pour la piqure de rappel.


D'une part, je ne fais aucun "bizness" dans mon coin sur le sujet,
j'utilise Spip pour des projets associatifs qui ne m'ont jamais
rapportés un centime et je fais cela depuis plus d'une quinzaine
d'années sur mon temps libre (à côté du développement d'autres logiciels
libres). D'autre part, je considère mon coup de gueule légitime, ne vous
en déplaise, vu le temps passé à trouver pourquoi cela ne fonctionnait
plus du tout chez une association d'aide de mal-voyants qui a subi un
gros problème de fonctionnement durant quinze jours, occasionnant pour
elle des pertes financières. Mais visiblement, ce n'est pas grave et ça
ne vaut surtout pas un coup de gueule. 
Encore une fois le problème n'est que tu signale un problème. Le 
problème est la manière dont

1) tu l'a signalé
2) tu a lié cela à l'écriture inclusive alors qu'il ne s'agit que d'une 
modalité de celle-ci (je ne reviendrais pas sur le sujet : les liens à 
ce sujet t'ont été envoyé par le passé...)


Tu aurais écrit un message de type "Bonjour, sur le site de 
l'association XXX que je gère, le passage à tel version du plugin 
formidable a inclus l'apparition de points médians. Ceci a des 
conséquences néfastes pour l'accessibilité qui sont . Serait-il 
possible d'envisager une autre manière de procéder à l'écriture 
inclusive ?", cela serait beaucoup mieux passé.


C'est en tout cas moins grave que

la nécessité absolue d'avoir des petits points qui se baladent partout
dans le texte et qui mettent à mal certaines interfaces. Qu'un projet
puisse être politique, je le conçois, mais lorsque la politique met à
mal la fiabilité d'un outil, ça me gêne un peu aux entournures.

Si vous prenez cela pour un crachat dans la soupe, je n'y puis rien,
c'est tout sauf cela. J'ai mis les pieds dans le plat parce que je ne
suis pas le seul à avoir ces problèmes et qu'avant tout, Spip doit être
fonctionnel, stable (pour les versions stables) et fiable. Et on ne doit
pas avoir, au fil de la mise à jour d'un plugin, un comportement
erratique. La simplicité, pour moi, aurait été de ne rien dire, de
constater les défaut et de passer à autre chose puisqu'il existe
aujourd'hui des outils libres faisant à peu près ce que j'ai codé avec
un Spip 1.9 il y a très longtemps pour cette association et que j'ai mis
régulièrement à jour depuis. Ce que je pense d'ailleurs faire pour être
tout à fait honnête, parce que je ne maîtrise pas les mises à jours des
plugins par des utilisateurs et j'ai bien d'autres choses à faire que
d'attendre que la site en question explose encore en vol à la suite de
la conversion en écriture inclusive d'un autre plugin.


tu ne nous a toujours pas dit (soit dit en passant) en quoi concrètement 
cela avait fait explosé le site. Et tu confond encore une fois 
l'écriture inclusive et le point médian, qui est une des formes.


par ailleurs je te signale que suite à tes réactions, qui n'étaient 
pourtant pas exprimé de manière qui donnait envie de se pencher sur le 
problème, nous avons modifié formidable et saisies pour supprimer le 
point médian. Que nous avons demandé ton avis (ainsi que ceux d'autres 
personnes) afin de trouver une écriture qui soit inclusive (en terme de 
genre) et accessible (au sens du handicap) et que nous ne l'avons pas eu.


Et je ne parlerais pas (mais en fait si !) de ta complainte classique en 
milieu militant (en l'occurence du logiciel libre)  du type "ca fait xxx 
ans que je m'investi, donc je n'ai de lecon à recevoir de personne", car 
à ces compte les mainteneurs des plugins formidable (moi le premier) 
pourrait te retorque la même chose...




Je ne reviendrai pas sur la discussion en question. Vus les messages de
soutien que j'ai reçus en privé, je ne suis pas vraiment tout seul à
penser ce que j'ai écrit. J'ajouterai même que cela n'a strictement rien
à voir avec "les buts et valeurs" sauf à avoir un esprit
particulièrement tordu parce que cela revient à établir une équivalence
entre le refus de l'écriture inclusive et le sexisme.

Encore une fois tu confond écriture inclusive et point médian. Que tu 
refuse pour des raisons de limitations des outils d'accessibilité le 
point médian, ok (même s'il faudrait exprimer cela d'une autre manière). 
Que tu refuse d'inclure la moitié de l'humanité dans ton écriture, 
revient effectivement a du sexisme.



Je m'étais aussi promis de ne rien dire, mais puisqu'on parle de
fermeture de comptes... Je trouve assez inadmissible de ne plus pouvoir
poster sur les listes Spip 

Re: [spip-dev] Saisies en PHP

2021-01-16 Par sujet Maïeul Rouquette

Le 16/01/2021 à 16:50, Vincent Callies a écrit :

Voici comment je fais :
https://git.spip.net/spip-contrib-extensions/list_elec/src/branch/master/formulaires/editer_list_elec.php

Avec formulaires_editer_objet_charger



ton message me fait penser qu'en fait on pourrait automatiser cela, 
comme on le fait pour les formulaires config.


cf 
https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/saisies_pipelines.php#L133


j

___
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] PR à nouveau bloqué

2021-01-08 Par sujet Maïeul Rouquette

Salut Camille,

on a a nouveau depuis hier des PR bléoqués dans un statut "vérification".

Une idée ?

Amicalement

Maïeul

___
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] Modèles, propre et notes

2021-01-07 Par sujet Maïeul Rouquette

Bonjour à tous et toutes,

j'aurais un besoin particulier. J'aimerais avoir un modèle qui me 
calcule automatiquement des notes de bas de page en fonction des 
arguments passés au modèle.


Le truc c'est que, bien sûr, les modèles sont interprètès APRÈS le reste 
des raccourcis, et donc les raccourcis dans les modèles ne marchent pas. 
Ce qui évidemment est le bon comportement pour 99,% des modèles.


Est-ce que d'aucun·e ont été confronté à un problème similaire? Des pistes ?

Sinon j'envisageais de faire un plugin modele_pre_propre qui traiterait 
avant propres certains modèles (définis via pipeline).


Z'en pensez quoi?

Maïeul

___
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 Maïeul Rouquette

Le 05/01/2021 à 17:13, Eric Lupinacci a écrit :

Hello,

Si je résume un peu ce qui a été dit.

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 ?
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).
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.

Ca peut faire une roadmap sympa il me semble non ?


++
Eric



j'agrèe sur tout les point, sauf sur 1 où je ne comprend pas 
"Maintenant, ne pourrait-on pas éviter de regénérer les zips existant 
sur Gitea". Je pensais, naivement qu'on les recuperait tel quel et qu'on 
se contentait de les lire...


Je me demande aussi s'il ne faudrait pas proposer à terme 2 flux, l'un 
ne contenant que le dernier x et y, l'autre contenant tout, comme 
actuellement. parce que deja que le flux actuel fait 10 Mo, si on 
augmente encore le nombre de tags, ca va faire bcp.

___
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-04 Par sujet Maïeul Rouquette

Le 04/01/2021 à 14:02, Eric Lupinacci a écrit :

Re,

Le lun. 4 janv. 2021 à 13:16, nicod_ > a écrit :



On pourrait utiliser le log de commit du tag et l'afficher dans SVP ?


Le log de commit est un pis-aller mais il ne correspond pas pour moi à 
un changelog compréhensible pour tous.


je pense que nicod parlais du log de commit de TAG différent du log standard
il est possible en effet d'associer des messages à un tag, même si en 
pratique nous ne le faisons pas souvent (mais on devrait, de même qu'on 
devrait signer nos tags avec PGP).
Après, il y a une façon simple de faire un changelog c'est un fichier... 
changelog (d'ailleurs y a une option dans Gitlab pour en ajouter un au 
repo).
Il suffirait qu'il ait une structure standard pour servir partout où on 
en aurait besoin comme le paquet.xml d'ailleurs.

Sans être obligatoire néanmoins.

peut être une solution plus simple en effet (mais faut voir si il existe 
un standard)

++
Eric





___
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 Maïeul Rouquette

Le 03/01/2021 à 20:15, RastaPopoulos a écrit :

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 ?



il faut distinguer conceptuellement
- le zippage par tags (qui est fait automatiquement par gitea)
- le listage dans plugins/contrib
- la distribution via svp

la question étant de savoir si les 3 doivents ou pas être strictement 
les mêmes

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.





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.



mouais, alors dans ce genre de cas, la distribution via gitea suffit non 
? pas besoin de charger cela en plus dans svp ?


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.



___
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 Maïeul Rouquette
Le dimanche 03 janvier 2021 à 16:00 +0100, Eric Lupinacci a écrit :
> Yop,
> 
> 
> Je ne comprends pas le clicodrome (deux clics et une saisie).
> Si c'est comme je pense une notion Gitea et pas git oui il faut
> passer par l'UI Gitea.
> Mais Camille doit pouvoir te répondre mieux que moi.

bah c'est juste qu'au bout d'un moment, rajoutons une procédure
supplémentaire ca fini par demotiver. Mais bon si comme tu dis priorité
aux tags... go go
>  
> > 2. Est-ce que cela ne serait juste pas plus simple de se dire
> > qu'on 
> > publie tous les tags, mais qu'on ne distribue que les plus récent
> Oui ça serait mieux mais alors pourquoi on ne le fait pas ?
> 
Ah ca je sais pas. Moi je suis pour !

> Après c'est pas mal aussi la notion de version Gitea car on peut
> saisir du texte pour expliquer.
> Je me suis rendu compte qu'on a aucun moyen simple de faire un
> changelog "plus disert" et plus compréhensible que les commits.
> Quand je fais ça sur Contrib je me retrouve à mettre une liste bof
> bof dans l'article principal alors qu'il serait plus logique d'avoir
> un changelog explicatif dans un article à part.
> En gros, on n'est pas prévenu des évolutions et si il faut prévenir
> d'un changement important on ne sait pas où le faire.
> 

Oui ca pourrait être effectivement pour moi la seule bonne raison :
avoir un système de changelog qui pourrait ensuite servir aussi lors de
la mise à jour via SVP et co. 
> ++
> Eric
> 

___
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 Maïeul Rouquette

Le 03/01/2021 à 14:45, Eric Lupinacci a écrit :

Hello,

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.
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.
On en vient à éviter de faire un y+1 pour ne pas avoir ce type de 
désagrément.

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

Le fait de créer un tag git pour publier une version via le débardeur 
n'est pas à remettre en cause, ça me parait la bonne approche. En effet, 
on doit faire une action volontaire pour publier une version.
Mais le problème actuel c'est que "publier" équivaut à "distribuer" 
(zip, SVP et Plugins SPIP).
Or à mon avis il faudrait aussi avoir une possibilité de décider si une 
version publiée doit être distribuée.


Il existe sous Gitea une notion de version qui s'appuie sur les tags.
La version semble être un objet composé d'un titre, d'une description, 
d'un état et d'un tag.
Il est possible d'éditer cette version à tout moment et de la supprimer 
simplement en un clic.

Voir ici : https://git.spip.net/spip-contrib-extensions/rainette/releases
Il est impératif de mettre un titre à la version créée sinon elle n'est 
pas modifiable par la suite (voir 3.11.2 par exemple), sauf à la recréer 
avec le même tag.


De mon point de vue, cette notion de version correspond bien au besoin 
de distribution si on y liste que les versions à distribuer.
Si le débardeur lisait cette liste plutôt que les tags il pourrait ne 
produire que cette liste en zip.
Et si on supprime une version comme la v3.11.2 par exemple, cela ne 
modifie pas le tag qui reste utilisable via git si besoin mais ça retire 
la distribution du zip.


On pourrait peut-être évoluer vers cette logique petit à petit en 
modifiant le débardeur pour qu'il utilise d'abord les versions Gitea si 
disponibles et sinon les tags.

Qu'en pensez-vous ?


++
Eric


Si je comprend la distinction entre les deux notions, j'aurais deux 
remarques
1. Est-ce possible de d'éditer les releases gitea facilement en ligne de 
commande sans passer par du clicodrome
2. Est-ce que cela ne serait juste pas plus simple de se dire qu'on 
publie tous les tags, mais qu'on ne distribue que les plus récent, à 
savoir pour chaque x, celui ayant le plus haut y, et pour chaque y, 
celui ayant le plus grand z? Typiquement ce qu'on a retenu comme 
affichage sur contrib.spip.net, et que le débardeur devrait se contenter


L'avantage de la solution 2 est qu'elle est simple et uniforme.
___
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] Outils de tests

2021-01-03 Par sujet Maïeul Rouquette
Oui, commme bcp de chose dans SPIP faudrait tout refaire.
Mais en attendant :)

perso je mettre cela dans spip-contrib-outils
Le dimanche 03 janvier 2021 à 07:26 +0100, Franck a écrit :
> Non non, tu ne te trompes pas, j'avais fait la demande il y a un
> moment de ça, le problème était de savoir si c'était fait exprès ou
> pas à l'époque et après enquête  , le résultat était qu'il y avait
> oubli et que l'interrogation qui restait était de savoir l'endroit du
> rangement "spip-contrib-outils ", "spip" ?
> Je ne sais plus si c'est eric ou azerttyu qui devait le faire quand
> il aurait 5 minutes.
> A savoir que marcimat disait qu'il faudrait complètement refaire les
> tests unitaires avec PHPUnit https://phpunit.de/ mais bon, sur ce
> point, comme je pense que cela représente beaucoup de boulot
> Franck
> 
> 
> 
> -Message d'origine-
> De : Maïeul Rouquette  
> Envoyé : samedi 2 janvier 2021 22:48
> À : spip-dev@rezo.net
> Objet : [spip-dev] Outils de tests
> 
> Salut tout le monde,
> 
> 
> j'ai l'impression que l'outil de test qui était ici
> 
> svn co svn://zone.spip.org/spip-zone/_core_/tests
> 
> n'a pas été migré sur la forge git.
> 
> Me trompe-je ?
> 
> Maïeul
> 
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
> 

___
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   >