Re: [spip-dev] [Spip-zone-commit] [testbuilder] Un peu de nettoyage, passage en v1 pour SPIP 4+, et (...)

2021-05-07 Par sujet Cerdic
Ah oui merci, corrigé !

--
Cédric
Le 7 mai 2021 à 11:34 +0200, Eric Lupinacci , a écrit :
> Petite remarque, tu n'as plus de branche compatible 3.2.
>
> ++
> Eric
>
>
> > Le ven. 7 mai 2021 à 10:57, Cerdic  a écrit :
> > > spip-contrib-extensions/testbuilder
> > > -
> > > Par Cerdic, le 7 mai 2021 à 10h56min :
> > >
> > > Un peu de nettoyage, passage en v1 pour SPIP 4+, et icone
> > >
> > >
> > > *Ajouté*
> > >     prive/themes/spip/images/tb-file-xx.svg
> > >     prive/themes/spip/images/tb-folder-xx.svg
> > >     prive/themes/spip/images/tb-xx.svg
> > >     tb.svg
> > > *Supprimé*
> > >     images/tb-128.png
> > >     images/tb-16.png
> > >     images/tb-24.png
> > >     images/tb-256.png
> > >     images/tb-32.png
> > >     images/tb-48.png
> > >     images/tb-64.png
> > >     images/tb-file-16.png
> > >     images/tb-folder-16.png
> > >     plugin.xml
> > >     prive/themes/spip/images/tb-16.png
> > > *Modifié*
> > >     paquet.xml
> > >     prive/exec/testbuilder.html
> > >     prive/style_prive_plugin_tb.html
> > >
> > > Détails : 
> > > https://git.spip.net/spip-contrib-extensions/testbuilder/commit/b76fcb866e1335e981b995f3eb6ea39ace5ab7a9
> > >
> > > ___
> > > spip-zone-com...@rezo.net - 
> > > https://listes.rezo.net/mailman/listinfo/spip-zone-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 4 - retour d'usage

2021-05-06 Par sujet Cerdic
Sorry, sorry, je sais que tu as fais pour le mieux avec les infos que tu avais, 
pardon de la formulation.

Et effectivement ta proposition de choix.choix_inline>.sous-choix (ou 
.choix-item ?) semble bien aussi pour gérer les cas où l’on veut mettre les 
choix en ligne dans un bloc .choix

--
Cédric
Le 6 mai 2021 à 12:36 +0200, tcharlss , a écrit :
> Le 06/05/2021 à 11:56, Cerdic a écrit :
> > Ah oui et en effet ils n’étaient pas stylé spécifiquement auparavant,
> > utilisant un très moche  pour gérer l'espacement
> >
> > Clairement ce « [ ] Oui [ ] Non » est un très mauvais pattern en terme
> > d’accessibilité, et gagnerait à être remplacé par une case à cocher
> > explicite
> >
> > Mais sinon on peut en effet proposer un markup spécifique, soit un
> > .choix-multiples qui du coup aurait le stylage proposé par Tcharlss,
> > soit des .choix-inline regroupés dans un .groupe-choix ?
> > Ou même simplement des .choix regroupés dans un .groupe-choix-flex ou
> > quelque chose du genre ? (qui serait un flex row avec wrap auto)
>
> +10 pour supprimer les oui/non au profit de simples case à cocher
>
> Sinon pour les choix multiples, il y a aussi Media qui met largeur +
> hauteur dans un même .choix par exemple.
>
> Pour la nomenclature, je sais pas. Si le conteneur extérieur peut rester
> un .choix de base, ça simplifierait pour les styles.
>
> div.choix.choix_inline
>   span.sous-choix
>     label
>     input
>   span.sous-choix
>    label
>    input
>
> Par exemple ?
>
> Et enfin bon, puisque ça a été subtilement suggéré je me sens obligé de
> répondre : je me garde bien d'ajouter des choses à la charte tout seul
> dans mon coin sans en parler avant, ou d'inventer des cas d'utilisation.
> Les styles répondent aux choses qui étaient clairement définies dans la
> charte (celle de 3.2), et pour les cas moins clairs comme les .choix et
> bien oui, des fois il faut inférer une partie des règles en fonction de
> ce qu'on a devant les yeux, les formulaires de la dist en l'occurence.
> On peut se tromper mais merci de ne pas immédiatement me prêter des
> intentions que j'ai jamais eues.
>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2021-05-06 Par sujet Cerdic
Salut Erational,

est-ce qu’on pourrait convenir de ne pas changer les compatibilités d’une 
branche sans en parler au mainteneur principal, ni de faire des tags à gogo ?

Là rien ne va :
1/ le plugin change de compat majeure en perdant sa compat 3.0 et 3.1 dans une 
simple release mineure
2/ le slogan et le logo du plugin changent
3/ et tout ça et joyeusement taggé et envoyé dans les zips chez tout le monde, 
va rattraper le bouzin

D’autre part, un bonux compat SPIP 4, dont le logo et le slogan change mérite 
une branche v4, car il y a des choses qui vont dégager car intégrée dans le 
core par exemple

Bref, c’est super cool pour l’icone, mais merci de pas y aller au bazooka sur 
les releases, ça fait 2 fois dans la semaine que je dois rattraper des releases 
foireuses
La règle c’est pas « pouf je fais un commit, je versionne le paquet je fais un 
tag » parce que c’est bien pénible et tout commit ne mérite pas un nouveau tag 
(en tout cas pour les plugins que je maintiens)

--
Cédric
Le 6 mai 2021 à 14:15 +0200, erational , a écrit :
>
> Oui ca marche aussi en SPIP 3.2
>
> J'ai donc adopté la nouvelle convention
> https://git.spip.net/spip-contrib-extensions/spip-bonux/commit/f7cae6a8d955989eb99d4aa8ebff56101e93bcea
>
>
>
> Le 06/05/2021 à 13:53, RastaPopoulos a écrit :
> > Le 06/05/2021 à 13:45, Eric Lupinacci a écrit :
> > > Oui, parce que sémantiquement ce n'est pas la même.
> > Ok moi ça me va, et c'est pas gênant vu qu'on parle de logo qui font 3ko 
> > quoi…
> >
> > Et vu que ça marche déjà aussi en 3.2, il faudrait donc noter que désormais 
> > la recommandation c'est tout simplement : "une image du nom du préfixe à la 
> > racine", ni plus ni moins.
> >
> > Plugin Patates => patates.svg à la racine
> >
> > Simple et de bon goût.
> >
>
> --
> _
> https://www.erational.org
>
> ___
> 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] spip 4 - retour d'usage

2021-05-06 Par sujet Cerdic
Ah oui et en effet ils n’étaient pas stylé spécifiquement auparavant, utilisant 
un très moche  pour gérer l'espacement

Clairement ce « [ ] Oui [ ] Non » est un très mauvais pattern en terme 
d’accessibilité, et gagnerait à être remplacé par une case à cocher explicite

Mais sinon on peut en effet proposer un markup spécifique, soit un 
.choix-multiples qui du coup aurait le stylage proposé par Tcharlss, soit des 
.choix-inline regroupés dans un .groupe-choix ?
Ou même simplement des .choix regroupés dans un .groupe-choix-flex ou quelque 
chose du genre ? (qui serait un flex row avec wrap auto)

--
Cédric
Le 6 mai 2021 à 11:48 +0200, 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.
>
> --
> RastaPopoulos
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
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 Cerdic
Je comprends pas l’argument sur les choix oui/non collé : il y a pas de cas 
officiels et supportés avec un radio oui et un radio non dans un même .choix

Cf la charte 3.2
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L113
le choix « oui » est dans un .choix, le choix « non » est dans un autre .choix,

Et ici c’est une case à cocher « Oui » dans un .choix avec un hidden « non » 
pour avoir la valeur non si on coche pas
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L130
il y a donc un seul choix dans le .choix et c’est la seule chose à styler

Les gens qui mettent éventuellement pleins de trucs dans un .choix, y compris 
plusieurs choix (radio, case), doivent alors gérer d’ajouter du css pour gérer 
leurs marge ou leurs alignement ou que sais-je

Sur la mediabox, par exemple j’ai rusé en faisant un .choix pour regrouper et 
dedans plusieurs sous .choix sur lesquels j’enleve la bordure
https://git.spip.net/spip/mediabox/src/branch/master/inc/mediabox.php#L84


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)

--
Cédric
Le 6 mai 2021 à 11:06 +0200, tcharlss , a écrit :
> En résumé :
>
> * Je vais retirer la règle trop stricte. On se contente de l'habillage
> extérieur (la bordure) sans présumer de ce qu'il y a dedans
> * Les .choix des forms de config en oui/non vont être à nouveau collés,
> pour ces cas-là peut-être faudrait-il en effet introduire un
> .groupe-choix ou autre (uniquement pour mettre une marge entre 2 paires
> inputs+label successives)
> * Escal prend d'énormes libertés avec la charte :)
>
> Le 06/05/2021 à 10:26, RastaPopoulos a écrit :
> >
> > Yop c'est dans le plugin "Dev" (fourni par l'équipe noyau, dans l'orga /spip
> >
> > Quand tu l'installes tu as alors accès à des pages de charte de l'admin.
> >
> > Mais sinon sur le site spip.net il y a une page sur la normalisation des 
> > formulaires. Cependant elle n'est pas très à jour… :)
> >
> ___
> 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] spip 4 - retour d'usage

2021-05-05 Par sujet Cerdic
Hello,

Ça me parait quand même louche de styler le 2n+1 et le 3n+3 child dans .choix :(

Je suppose que tu as voulu traiter le cas où on a juste un .choix et dedans une 
succession de input+label, mais c’est normalement pas un cas à traiter et ça me 
semble invasif et pas très robuste...

Quid du ou des input hidden dans un .choix qui viennent perturber le compteur 
comme ici
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L132 ?

Je vois que c’est parce que vous avec voulu permettre le cas de « On met tous 
les choix dans un seul .choix » comme ici
https://git.spip.net/spip/dev/src/branch/dev/refacto_form_charter/formulaires/charter.html#L101
mais ça me parait pas pertinent ni robuste

Ce conteneur .choix a été introduit pour permettre justement d’identifier une 
unité semantique de choix, et qu’on puisse y mettre si besoin un markup un peu 
souple comme une explication, une image, ou que sais-je qui serais nécessaire 
dans des cas particuliers.

En présumant que le .choix est rempli de succession de label+input et 
uniquement ça on bloque à nouveau toute souplesse de balisage...

Il faut rester sur la convention .choix = 1 choix, en général composé d’un 
input+label, mais pas forcément uniquement.

Alternativement, si besoin pour certains cas de mise en forme, il faut 
introduire un .groupe-choix l’encadrant ?
Jusqu’ici ça n’avait pas été indispensable, mais pourquoi pas...

--
Cédric
Le 5 mai 2021 à 21:34 +0200, tcharlss , a écrit :
> On peut voir le squelette du formulaire et une capture de ce que ça donnait 
> avant ?
> Et est-ce qu'il y a des CSS personnalisées ?
> Ces règles s'appuient sur les cas connus et documentés de la charte des 
> formulaires.
> Le 05/05/2021 à 21:07, Jean-Christophe Villeneuve a écrit :
> > J'ai un souci d'affichage dans le privé
> >
> > http://escal.ac-lyon.fr/spip4test/squelettes/Selection.png
> >
> > J'ai un doute sur ces 2 règles css
> >
> > .formulaire_spip .choix > :nth-child(2n+1) {
> >     margin-right: calc(var(--spip-form-padding-input-x) * 3/4);
> > }
> >
> > et
> >
> > .formulaire_spip .choix > :nth-child(3n+3), .formulaire_spip span.choix + 
> > span.choix {
> >     margin-left: var(--spip-form-spacing-x);
> > }
> >
> >
> >
> > ___
> > 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
___
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] [COG] Mystère : mon git clone du master avait récupéré un (...)

2021-05-04 Par sujet Cerdic
paquet.xml et zip ne sont pas des gestionnaires de version !
On va donc pas s’amuser à doublonner tout ce qu’on fait "pour que les zips 
soient à jour si jamais quelqu’un doit contribuer d’après un zip"

Si tu veux contribuer, tu pars de la version git, pas de la version zip, c’est 
la norme

--
Cédric
Le 4 mai 2021 à 09:59 +0200, RealET , a écrit :
>
> ⇒ toute intervention sur paquet.xml devrait faire un up de z et un tag
> pour générer le bon zip
___
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 =?utf-8?Q?=E2=80=94_?=proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Cerdic
Dans tous les cas perdons pas de vu le kiss : on va pas se lancer dans une 
refonte complète du plugin aide *pour cette release* : même si on est tous 
d’accord qu’il faudrait le faire dans l’absolu, ne tombons pas dans le piège du 
« ah mais on fait juste ça en plus et puis… » dans 4 ans on est encore à 
essayer de faire la release.

Donc soit on laisse le plugin aide faute de mieux, soit on le vire complètement 
et on a un truc simple et rapide pour juste les raccourcis SPIP, mais bon bref 
vous voyez l’idée.

La release sera jamais parfaite, on aura jamais fini, donc tenons nous au 
calendrier prévu, et ce qui est pas fait là le sera dans la prochaine (ou dans 
10 ans si c’est pas si grave…)

--
Cédric
Le 30 avr. 2021 à 20:46 +0200, Bruno Bergot , a écrit :
> Hop,
>
> Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :
>
> > Oui, j'aimerais bien en .md… mais on n'a pas librairie dans le core pour
> > traduire le .md ensuite en html… donc… soit on a ajoute une… soit on le
> > fait pas comme ça ! Et l'avantage du .spip, c'est que tu appliques
> > propre() et tu peux montrer en direct des exemples (pour les tableaux
> > notamment).
> >
>
> Ha ben je répondais justement à une remarque d'arno en privé il ya
> quelques minutes sur ce point :
>
> Oui, avec le plugin MD on peut baliser le type de syntaxe dans un texte
> qui en utilise plusieurs, cf :
>
> https://git.spip.net/spip-contrib-extensions/markdown
>
> Après on peut aussi versionner un txt qui utilise la syntaxe SPIP, mais
> c'est hachement moins pratique pour le partager, l'éditer en ligne ou
> dans un éditeur, bref, la syntaxe SPIP a "un peu" moins d'outil à dispo
> que MD ;)
>
> ++
> b_b
> ___
> 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] [Spip-zone-commit] [newsletters] Permettre la recherche (titre, chapo, texte)

2021-04-30 Par sujet Cerdic
Hello,

est-ce que tu pourrais regarder le réglage de ton éditeur concernant 
l’indentation et les retour-ligne ?
Là visiblement tout le fichier est passé en CR-LF au lieu de LF, et les 3lignes 
que tu as ajouté ont une indentation foireuse.

Résultat le diff est totalement illisible
https://git.spip.net/spip-contrib-extensions/newsletters/commit/eee22be705ccd95094d52e2af84bbfba034c5dda

et les 3 lignes sont sont au mauvais endroit, et ce sera encore illisible la 
prochaine fois que quelqu’un éditer avec les LF.

--
Cédric
Le 30 avr. 2021 à 03:52 +0200, patrice4 , a écrit :
> spip-contrib-extensions/newsletters
> -
> Par patrice4, le 30 avril 2021 à 03h51min :
>
> Permettre la recherche (titre, chapo, texte)
>
>
> *Modifié*
> base/newsletters.php
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/newsletters/commit/eee22be705ccd95094d52e2af84bbfba034c5dda
>
> ___
> spip-zone-com...@rezo.net - 
> https://listes.rezo.net/mailman/listinfo/spip-zone-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] Ne pas échapper le js inséré par un modèle dans l'admin de SPIP

2021-04-28 Par sujet Cerdic
data-src ou bien le fait que le src contient une image en base64 ?

--
Cédric
Le 26 avr. 2021 à 19:00 +0200, RealET , a écrit :
> Cerdic a écrit le 26/04/2021 à 13:58 :
> > Le js n’est par défaut pas échappé dans les modèles, cf le modèle gis
> > qui en contient plein
> > https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/modeles/carte_gis.html
> > <https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/modeles/carte_gis.html>
> >
> > MAIS
> >
> > les images ou lien avec des urls un peu louches ou des attributs onxxx
> > sont en effet échappées car ce sont des moyens possibles pour
> faire du
> > XSS et pour un rédacteur invité sur un site de voler la session de
> > l’admin qui relie son article.
> En l’occurrence, c'est des data-src qui provoquent le problème.
>
>
> >
> > La detection produit certainement des faux positifs, mais on ne sait pas
> > faire mieux.
> Oui, c'est en rapport avec
> https://core.spip.net/issues/4706
>
> >
> > A charge pour les plugins de faire des modèles avec du html propre
> sans
> > ambiguité et d’éviter ce genre de situation.
>
> data-src sur une image, c'est devenu un standard, non ?
>
>
> --
> RealET
>
>
> ___
> 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] [Spip-zone-commit] [z-core] up de z

2021-04-27 Par sujet Cerdic
Hello,

bon, déjà j’aurai bien aimé qu’on me laisse le temps de relire et valider la 
PR, de la rebaser parce que j’aime pas les merge.

Mais la, c’est quoi cette gestion de branche ?

On change le doctype, changement majeur, et on fait un incrément de z, et a 
côté de ça on fait une branche « spip-3.2 » alors même qu’on a dit que ce genre 
de branche liée à une version de SPIP était une mauvaise pratique ?

Bref, là ça va pas du tout.

J’ai supprimé le tag en urgence avant que ça provoque des mises à jour à tour 
de bras.
Merci de ne plus toucher avant que je remette tout le plugin d’equerre demain.

--
Cédric
Le 27 avr. 2021 à 21:27 +0200, cy_altern , a écrit :
> spip-contrib-extensions/z-core
> -
> Par cy_altern, le 27 avril 2021 à 21h26min :
>
> up de z
>
>
> *Modifié*
> paquet.xml
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/z-core/commit/0738003aa0e19e01bce6f00f51e0f52fe010e861
>
> ___
> spip-zone-com...@rezo.net - 
> https://listes.rezo.net/mailman/listinfo/spip-zone-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] Ne pas échapper le js inséré par un modèle dans l'admin de SPIP

2021-04-26 Par sujet Cerdic
Le js n’est par défaut pas échappé dans les modèles, cf le modèle gis qui en 
contient plein
https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/modeles/carte_gis.html

MAIS

les images ou lien avec des urls un peu louches ou des attributs onxxx sont en 
effet échappées car ce sont des moyens possibles pour faire du XSS et pour un 
rédacteur invité sur un site de voler la session de l’admin qui relie son 
article.

La detection produit certainement des faux positifs, mais on ne sait pas faire 
mieux.

A charge pour les plugins de faire des modèles avec du html propre sans 
ambiguité et d’éviter ce genre de situation.

--
Cédric
Le 26 avr. 2021 à 13:07 +0200, RealET , a écrit :
> Bonjour,
>
> En 3.2 (ou 3.3), est-ce qu'un plugin peut déclarer son JS sûr pour que
> le js de ses modèles ne soit pas échappé dans l'admin de SPIP (cf
> https://contrib.spip.net/Nivo-Slider-3747#comment508245-508242) ?
>
> Merci d'avance
>
> --
> RealET
>
>
> ___
> 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] [spip] 5 commits

2021-04-22 Par sujet Cerdic
Arno, pourrais-tu taper la commande dans ton terminal pour que tes pull soient 
toujours en rebase et éviter de nous faire des merge sans arrêt sur le master 
quand quelqu’un a commit en parallèle de toi ?

git config --global pull.rebase true

J’en profite pour répondre à ta question :

git fetch : git va chercher les commits qui sont sur le serveur et les récupère 
en local, dans son arbre, MAIS il ne les checkout pas. En gros tu restes sur le 
même commit en local, mais simplement git sait maintenant qu’il y a des commits 
en plus sur le serveur si c’est le cas

git pull : c’est un git fetch + le checkout dans ton répertoire des commits qui 
arrivent depuis le serveur.

Et c’est là que le problème se pose : si toi tu as travaillé entre temps, ton 
dossier local contient des commits qui ne sont pas sur le serveur, et le 
serveur contient des commits qui ne sont pas sur ton disque.
Pour ça 2 solutions :

• soit git fait un merge (c’est le réglage par défaut que tu as actuellement), 
et ça génère sans arrêt plein de commits de merge un peu ennuyeux
• soit git fait un rebase : il va enlever tes commits locaux, remettre les 
commits qui arrivent depuis le serveur, et rejouer tes commits par dessus. 99% 
du temps ça se passe bien, mais parfois il peut y avoir un conflit sur une 
modif faites des 2 côtés. Dans ce cas suivre les indications de git : editer le 
fichier, résoudre le conflit manuellement, faire un `git add` dessus, puis un 
`git rebase --continue`



--
Cédric
Le 21 avr. 2021 à 21:19 +0200, 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*
>
>
>
>
>
> > Le 21 avr. 2021 à 21:04, Maïeul Rouquette  a écrit :
> >
> >
> > > 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
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [spip-commit] [spip] Présentation des sous-rubriques (vignettes + grosses)

2021-04-22 Par sujet Cerdic
Il aurait fallu remettre le master d’equerre suite au merge foiré d’Arno ou 
alors assumer que bon c’est parti comme ça et finir le merge proprement si 
besoin et finir sur le master.

Mais là en effet c’est le brin total avec un demi chantier qui a été mis sur le 
master, arno qui continue à commit par dessus, et en même temps la branche de 
dev qui continue à évoluer….

--
Cédric
Le 21 avr. 2021 à 23:59 +0200, tcharlss , a écrit :
> Hello Arno,
>
> Est-ce qu'il vaudrait pas mieux attendre que l'histoire du merge non
> voulu soit réglé avant de continuer à travailler sur ces fichiers ?
> Par exemple là sur box_skins.css.html, tu poursuis à partir d'une
> version non finalisée, qui continue à évoluer en parallèle sur la
> branche de dev.
> Je sais pas trop ce que ça va donner pour la vraie fusion après, mais ça
> va certainement pas faciliter.
>
>
> Le 21/04/2021 à 23:35, ARNO* a écrit :
> > spip/spip
> > -
> > Par ARNO*, le 21 avril 2021 à 23h33min :
> >
> > Présentation des sous-rubriques (vignettes + grosses)
> >
> >
> > *Modifié*
> > ecrire/inc/presenter_enfants.php
> > prive/themes/spip/box_skins.css.html
> >
> > Détails : 
> > https://git.spip.net/spip/spip/commit/1847b1dc4f53480b52e7419f4b668563f790f364
> >
> > ___
> > spip-com...@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-commit
> > dev: http://trac.rezo.net/trac/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
___
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-21 Par sujet Cerdic
J’ajoute à la liste :

• la mediabox qui a changé de librairie sous-jacente (on passe de colorbox à 
lity), ce qui casse les éventuelles personnalisations de CSS ou de JS pour 
faire des comportements spécifiques
• le date-picker qui change aussi et qui casse potentiellement aussi un peu les 
utilisations avancées


--
Cédric
Le 21 avr. 2021 à 11:15 +0200, Cerdic , a écrit :
> Moi non plus je veux pas jouer les grognons de service mais :
>
> • cette nouvelle version requiert un saut de PHP et laisse tomber PHP 5x, ce 
> qui n’est pas mineur
> • introduit un certain nombre de nouvelles syntaxes sur les balises et les 
> boucles (boucles anonymes, en-tête et pieds de boucles, boucles dans les 
> balises) qui font que les squelettes de cette version ne seront pas 
> utilisables sur une plus ancienne version
> • introduit des ruptures de compatibilité sur le rendu des sites : modeles 
> document, pagination
> • enlève jQuery UI
> • et accessoirement introduit le support complet de SVG y compris dans les 
> filtres images, ce qui n’est pas rien
>
> On ne veut pas que les utilisateurs upgradent juste leur site à la légère et 
> découvrent que plus rien ne marche parce qu’ils ont un vieux PHP<7.3 ou que 
> tout leur site est visuellement cassé (et le travail pour remettre en ordre 
> n’est pas forcément léger selon les cas)
>
> Donc la question n’est pas de savoir ce qu’on aurait voulu mettre dans une 
> 4.0, mais de savoir si les ruptures de compatibilité et les nouvelles 
> fonctionnalités sont suffisantes pour justifier un saut de numérotation et il 
> me semble que oui.
>
> --
> Cédric
> Le 15 avr. 2021 à 15:09 +0200, Bruno Bergot , a écrit :
> > Hop,
> >
> > Le 15/04/2021 à 14:58, RastaPopoulos a écrit :
> > >
> > > Annexement pour moi une 4.0 serait :
> > > - soit pour Composer
> > > - soit pour une réelle refonte ergo de l'admin, pas juste les styles 
> > > graphiques améliorés
> > >
> >
> > Je suis d'accord, je ne voulais pas jouer le grognon de service à propos
> > de cette 4.0, mais j'ai du le laisser transparaître dans ma formulation :)
> >
> > Je pense aussi ça la 3.3 actuelle ne mérite pas un saut de X, cf ce que
> > disait marcimat au sujet de notre "politique" de numérotation jusqu'à
> > maintenant.
> ___
> 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] Une 4.0 plutôt qu'une 3.3

2021-04-21 Par sujet Cerdic
Moi non plus je veux pas jouer les grognons de service mais :

• cette nouvelle version requiert un saut de PHP et laisse tomber PHP 5x, ce 
qui n’est pas mineur
• introduit un certain nombre de nouvelles syntaxes sur les balises et les 
boucles (boucles anonymes, en-tête et pieds de boucles, boucles dans les 
balises) qui font que les squelettes de cette version ne seront pas utilisables 
sur une plus ancienne version
• introduit des ruptures de compatibilité sur le rendu des sites : modeles 
document, pagination
• enlève jQuery UI
• et accessoirement introduit le support complet de SVG y compris dans les 
filtres images, ce qui n’est pas rien

On ne veut pas que les utilisateurs upgradent juste leur site à la légère et 
découvrent que plus rien ne marche parce qu’ils ont un vieux PHP<7.3 ou que 
tout leur site est visuellement cassé (et le travail pour remettre en ordre 
n’est pas forcément léger selon les cas)

Donc la question n’est pas de savoir ce qu’on aurait voulu mettre dans une 4.0, 
mais de savoir si les ruptures de compatibilité et les nouvelles 
fonctionnalités sont suffisantes pour justifier un saut de numérotation et il 
me semble que oui.

--
Cédric
Le 15 avr. 2021 à 15:09 +0200, Bruno Bergot , a écrit :
> Hop,
>
> Le 15/04/2021 à 14:58, RastaPopoulos a écrit :
> >
> > Annexement pour moi une 4.0 serait :
> > - soit pour Composer
> > - soit pour une réelle refonte ergo de l'admin, pas juste les styles 
> > graphiques améliorés
> >
>
> Je suis d'accord, je ne voulais pas jouer le grognon de service à propos
> de cette 4.0, mais j'ai du le laisser transparaître dans ma formulation :)
>
> Je pense aussi ça la 3.3 actuelle ne mérite pas un saut de X, cf ce que
> disait marcimat au sujet de notre "politique" de numérotation jusqu'à
> maintenant.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2021-04-21 Par sujet Cerdic
En regardant de plus près, je pense que la solution serait de mettre dans le 
core un filtre |image_recadre_avec_fallback (ou meilleur nom à trouver) qui

• vérifierait qu’on a bien gd2 actif
• qu’on a bien le plugin filtres_images activé (car |image_recadre n’est pas 
dans le core et on essaye de gérer proprement les dépendances pour que le core 
ne casse pas si on retire des plugins-dist)

Si les 2 conditions sont remplies, le filtre ferait appel au vrai filtre 
|image_recadre,
et sinon produirait un fallback à base de image_passe_partout + un peu de 
html/css pour produire un contenu visuel dans les dimensions attendues 
(peut-être avec un conteneur en overflow:hidden ou avec un clip-path en style 
inline ou un peu des deux, bonne méthode à trouver)

On pourrait ainsi se reposer sur ce pseudo filtre dans l’espace privé (à 
condition de ne pas enchainer un autre filtre derrière, car si le filtre 
produit le fallback le résultat risque d’être imprévisible)

--
Cédric
Le 21 avr. 2021 à 00:28 +0200, a...@rezo.net , a 
écrit :
>
> Ah zut…
>
> Pas de souci s’il faut revert.
>
> Mais je fais encore une tentative… Qu’est-ce que vous pensez de ceci:
> [(#CONFIG{image_process}|=={gd2}|?{
> [(#LOGO_ARTICLE_NORMAL|image_recadre{1:1,-,focus}|image_reduire{70,70})],
> [(#LOGO_ARTICLE_NORMAL|image_passe_partout{70,70})]
> })]
>
>
> J’apprécie beaucoup la nouvelle présentation avec les vignettes bien zoomées, 
> c’est vraiment agréable. Mais si je peux activer le recadrage intelligent 
> dessus, c’est un vrai gros plus pour moi, puisque ça permet de visualiser une 
> première fois qu’on a bien réglé le centre d’intérêt des images (quand on l’a 
> fait). Alors que sinon, à l’inverse, le recadrage centré automatique (donc 
> «défaillant» dans beaucoup de cas), alors qu’on a pris soin de régler le 
> centre d’intérêt des images justement pour éviter les mauvais recadrage, ça 
> introduit une impression de «bug».
>
> ARNO*
>
>
>
> > Le 20 avr. 2021 à 13:27, nicod_  a écrit :
> >
> > Le 20/04/2021 à 12:28, ARNO* a écrit :
> > > spip/spip | 2 commits
> > > -
> > > Par ARNO*, le 20 avril 2021 à 12h21min :
> > > Si on recadre images, alors privilégier "focus" (sinon têtes coupées)
> > > *Modifié*
> > > prive/objets/liste/articles.html
> > > Détails : 
> > > https://git.spip.net/spip/spip/commit/525ab523c5f0e1e6c549e87dd8797a20bf7fc1ea
> >
> > Attention, image_recadre et/ou image_reduire ne sont pas forcément 
> > disponibles si on n'a pas encore activé la config GD2 ou autre...
> >
> > --
> > nicod_
>
> ___
> 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] [spip] 2 commits

2021-04-20 Par sujet Cerdic
Ce n’est pas une question d’activation de la config GD2 ou autre uniquement :

image_reduire est implémentée pour supporter 5 méthodes différentes (celles que 
l’on configure dans le privé) avec un fallback css.
On peut donc l’utiliser en toute confiance sans soucis.

Toutes les autres transformations d’image autres qu’une mise à l’échelle par 
contre, sont implémentées uniquement au moyen de GD2. Il faut donc que celle-ci 
soit disponible, ce qui n’est pas forcément le cas.

--
Cédric
Le 20 avr. 2021 à 13:44 +0200, RastaPopoulos , a écrit :
> Le 20/04/2021 à 13:27, nicod_ a écrit :
> > Attention, image_recadre et/ou image_reduire ne sont pas forcément 
> > disponibles si on n'a pas encore activé la config GD2 ou autre...
>
> Oui c'est voulu depuis des années qu'il n'y a pas image_recadre ou ce genre 
> de gros filtres dans l'admin, il n'y a que la réduction qui peut se faire 
> (car fallback quand pas de lib serveur).
> Il faut donc revert ça à priori.
>
> L'autre jour je demandais : ya pas moyen de savoir si on a une lib configurée 
> ou pas, et faire l'un ou l'autre ? Même avec un filtre dédié eventuellement 
> (surchargeable du coup).
>
> Genre #LOGO|image_transformation_prive
>
> et un filtre_image_transformation_prive() avec dedans un test si ya pas de 
> lib, une réduction simple, et si ya une lib, un image_recadre avec focus, par 
> défaut
>
> et en plus de ça, ça serait surchargeable si pour tel site on veut un truc 
> perso
>
> --
> RastaPopoulos
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
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 Cerdic
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...

--
Cédric
Le 15 avr. 2021 à 21:13 +0200, Maïeul Rouquette , a écrit :
> 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
___
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-16 Par sujet Cerdic
Non entre une beta et une release finale il y a pas de différence fonctionnelle 
(il devrait pas y en avoir).

Et donc je pense que le mieux c’est :

• sortir une beta au 1er mai et la numéroter 4.0 au vu des ruptures de compat 
et du saut de version PHP requis
• créer la branche 4.0 partout (core et plugins dist) pour ne plus y envoyer de 
nouvelles features mais uniquement du bugfix


--
Cédric
Le 15 avr. 2021 à 19:11 +0200, Jacques B , a écrit :
> Le 15/04/2021 à 15:58, JLuc a écrit :
> > Le 15/04/2021 à 15:09, Bruno Bergot a écrit :
> > > suite au sprint et à l'idée de potentiellement releaser en avril/mai,on 
> > > aurait du créer tout de suite une branche 3.3 pour justement préparer la 
> > > release sans freiner les expérimentations dans master. Mais bon, on fera 
> > > mieux dans notre prochain cycle :)
> >
> > On est encore qu'au quart de avril-mai.
> > Il est encore temps de la créer cette branche 3.3 !
> >
> Et est-ce qu'il ne serait pas possible de :
>
> • sortir une 3.3 beta au premier mai comme déjà "prévu"
> • La renommer 4.0 si les évolutions sont assez mûres au moment de la release 
> finale ? (pour cet automne ou décembre si je me rappelle ce qui était dit)
>
> Parce que quand même il y a pas mal de grosses évolutions ! Et si on sort une 
> 5.0 l'année d'après avec composer, tant mieux.
> Jacques
> ___
> 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] Problème WHERE

2021-04-14 Par sujet Cerdic
C’est normalement corrigé par
https://git.spip.net/spip/spip/commit/e0e29f27d9d883811f5713bbe5eefa5f9aeb3c22

Il faut peut etre que tu recalcule pour te débarasser de code compilé faux 
lorsque tu as essayé de debug ?

--
Cédric
Le 14 avr. 2021 à 17:39 +0200, tofulm , a écrit :
> ce problème de sql_quote c'est ici que cela plante :
> https://git.spip.net/spip/spip/src/branch/master/ecrire/public/composer.php#L941
> ce qui est etonnant, c'est une fonction sql_select qui est appelé et qui fait 
> planté sql_quote.
>
>
> Le 14/04/2021 à 16:37, tofulm a écrit :
> > Oui effectivement, on peut enlever les quote autour de $type.
> > par contre,  il y a un log dans mysql.log:
> > ecrire/base/connect_sql.php:L169:spip_sql_erreur()::Pub:ERREUR: Erreur 1305 
> > de mysql: FUNCTION spip33_sngpckda.sql_quote does not exist
> >
> >
> > Le 14/04/2021 à 16:05, Cerdic a écrit :
> > > Ah bien vu, je pense que tu l’as quasiment.
> > > Dans le second cas c’est probablement  array("=" , 
> > > "$obj",sql_quote($type))
> > >
> > > --
> > > Cédric
> > >
> > --
> > tofulm
> --
> tofulm
___
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 WHERE

2021-04-14 Par sujet Cerdic
Ah bien vu, je pense que tu l’as quasiment.
Dans le second cas c’est probablement  array("=" , "$obj",sql_quote($type))

--
Cédric
Le 14 avr. 2021 à 15:47 +0200, tofulm , a écrit :
> J'ai trouvé
>
> C'est depuis ce commit
>
> https://git.spip.net/spip/spip/commit/81b3f6dd22d699986ca2d5a068959ec0011b4253
>
> et l'ajout de :
>
> $boucle->where["JOIN-L$n"] = array("'='","'$obj'","sql_quote('$type')");
>
> si on remplace cette ligne par :
>
> $boucle->where["JOIN-L$n"] = $echap ?
> array("'='","'$obj'","sql_quote('$type')") :
> array("=","$obj","sql_quote('$type')");
>
> Cela fonctionne sauf que maintenant :
>
> ecrire/base/connect_sql.php:L170:spip_sql_erreur()::Pub:ERREUR: Erreur
> 1305 de mysql: FUNCTION spip33_sngpckda.sql_quote does not exist
>
>
>
> --
> tofulm
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2021-04-14 Par sujet Cerdic
Hello,

j’ajouterai en sus : c’est super que ce sujet re-passionne à nouveau du monde 
au moment où ça bouge comme on peut parce qu’on a plus d’autre choix :)

Pour rappel, on avait eu le même débat il y a 10ans, quand j’avais mis le jeu 
fatcow, qui n’emballait pas tout le monde, et fil avait d’ailleurs ouvert un 
ticket
https://core.spip.net/issues/2580

Comme on a 10 ans de recul, on voit que finalement le jeu fatcow a suffisament 
bien fait le job pour que personne ne se sente suffisament de motivation pour 
prendre à bras le corps ce ticket.
Et probablement aussi qu’il y a une question d’habitude, et qu’on est toujours 
un peu chafouin quand « ça change ».

Cela dit donc, ce serait super qu’il y ait un vrai boulot de fond, et quand ce 
sera dispo on pourra l’intégrer.
En attendant on fait comme on peut, du mieux qu’on peut, et hauts les cœurs !

--
Cédric
Le 13 avr. 2021 à 21:50 +0200, Mathieu Drouet , a écrit :
> Bonjour à tous
>
> Je me réveille sur le sujet des icônes . On peut envisager tranquillement un 
> travail collectif sur un design system léger prenant en compte les icônes , 
> les composants et les styles . Je veux bien aider.
>
> On peut s’inspirer de plusieurs projets open source ( gnome ou Carbon d’ibm )
>
> Bonne journée
>
> > Le 13 avr. 2021 à 17:50, erational  a écrit :
> >
> >
> >
> > Le 13/04/2021 à 17:06, Cerdic a écrit :
> > > Hello,
> > >
> > > je réponds un peu à la louche mais en gros :
> > >
> > > • c’était vraiment plus possible de continuer avec les icones png toutes 
> > > moches et floues dès qu’on avait un écran un peu correct
> > > • dans un monde idéal il aurait fallu faire un vrai boulot de fond de 
> > > graphiste, définir une charte etc
> > > • ou redéfinir une nouvelle direction en se passant d’icones complexes 
> > > svg et en utilisant partout des icones symboliques monochrome type 
> > > fontawesome mais libre (cf le ticket sur le sujet)
> > > • du coup j’ai commencé à remplacer toutes les png par des svg, à la 
> > > hussarde en faisant pour le mieux, et en me disant que les vraiment pas 
> > > réussies motiveront quelqu’un d’autre pour les corriger
> > > • en pratique je prend beaucoup d’inspiration sur flaticon, mais je 
> > > réutilise rarement les icones telles quelles : je les retravaille, 
> > > redécoupe, repositionne, change les couleur selon les cas
> > > • les quelques cas réutilisés tels quels sont en majorité de l’auteur 
> > > https://www.flaticon.com/authors/freepik
> > >
> > > Et pour les bonnes pratiques, je nettoie aussi toujours le code via 
> > > https://jakearchibald.github.io/svgomg/ et les livre en width/height 64px 
> > > en général (mais je refais pas toujours le viewPort)
> > >
> > > Après si on se donne un temps infini on peut sans doute faire mieux, mais 
> > > l’objectif est d’avoir un truc acceptable pour la prochaine release, et 
> > > de là il sera toujours possible aux volontaires de faire un travail de 
> > > fond sur le sujet pour une release suivante
> >
> > +1
> >
> > Faisons un truc correct pour la release.
> > J'essaie de corriger les trucs les plus évidents aussi.
> >
> > Ensuite une fois que le jeu entier des icônes sera disponible,
> > Cela sera plus facile de tout refondre de façon unie et/ou de passer une 
> > commande à une graphiste.
> >
> >
> > >
> > > --
> > > Cédric
> > > Le 13 avr. 2021 à 16:55 +0200, Matthieu Marcillaud , a 
> > > écrit :
> > > > Le 13/04/2021 à 15:49, tcharlss a écrit :
> > > > > Je pense que la majorité des nouvelles proviennent de
> > > > > https://www.flaticon.com/
> > > >
> > > > Personnellement je n'accroche pas trop les petites icones svg qui sont
> > > > mises (mais qui restent dans l'esprit d'avant, quoi que plus saturées) :
> > > >
> > > > - elles ont pour certaines beaucoup de détails (et affichées en 16px,
> > > > bah il reste un truc assez brouillon)
> > > > - elles ont des couleurs très différentes et certaines très visibles par
> > > > rapport aux autres
> > > >
> > > > J'aurais préféré (grand vœux pieux) un jeu monochrome, soit en filaire,
> > > > soit filaire et aplats (comme les grandes icones du bandeau), en
> > > > d'utilisant currentColor sur les styles pour pouvoir colorer l'icone de
> > > > différentes manières (notamment en blanc ou noir ou couleur du thème).
> > > >
> > > > Mais bon, 

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

2021-04-13 Par sujet Cerdic
Hello,

je réponds un peu à la louche mais en gros :

• c’était vraiment plus possible de continuer avec les icones png toutes moches 
et floues dès qu’on avait un écran un peu correct
• dans un monde idéal il aurait fallu faire un vrai boulot de fond de 
graphiste, définir une charte etc
• ou redéfinir une nouvelle direction en se passant d’icones complexes svg et 
en utilisant partout des icones symboliques monochrome type fontawesome mais 
libre (cf le ticket sur le sujet)
• du coup j’ai commencé à remplacer toutes les png par des svg, à la hussarde 
en faisant pour le mieux, et en me disant que les vraiment pas réussies 
motiveront quelqu’un d’autre pour les corriger
• en pratique je prend beaucoup d’inspiration sur flaticon, mais je réutilise 
rarement les icones telles quelles : je les retravaille, redécoupe, 
repositionne, change les couleur selon les cas
• les quelques cas réutilisés tels quels sont en majorité de l’auteur 
https://www.flaticon.com/authors/freepik

Et pour les bonnes pratiques, je nettoie aussi toujours le code via 
https://jakearchibald.github.io/svgomg/ et les livre en width/height 64px en 
général (mais je refais pas toujours le viewPort)

Après si on se donne un temps infini on peut sans doute faire mieux, mais 
l’objectif est d’avoir un truc acceptable pour la prochaine release, et de là 
il sera toujours possible aux volontaires de faire un travail de fond sur le 
sujet pour une release suivante

--
Cédric
Le 13 avr. 2021 à 16:55 +0200, Matthieu Marcillaud , a écrit 
:
> Le 13/04/2021 à 15:49, tcharlss a écrit :
> > Je pense que la majorité des nouvelles proviennent de
> > https://www.flaticon.com/
>
> Personnellement je n'accroche pas trop les petites icones svg qui sont
> mises (mais qui restent dans l'esprit d'avant, quoi que plus saturées) :
>
> - elles ont pour certaines beaucoup de détails (et affichées en 16px,
> bah il reste un truc assez brouillon)
> - elles ont des couleurs très différentes et certaines très visibles par
> rapport aux autres
>
> J'aurais préféré (grand vœux pieux) un jeu monochrome, soit en filaire,
> soit filaire et aplats (comme les grandes icones du bandeau), en
> d'utilisant currentColor sur les styles pour pouvoir colorer l'icone de
> différentes manières (notamment en blanc ou noir ou couleur du thème).
>
> Mais bon, plus facile à dire qu'à faire ; ça serait un travail copieux
> pour l'ensemble des icones, et ça rejoint du coup aussi le ticket sur
> les #ICONE
>
> MM.
>
>
> ___
> 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] Réparer archives.xml

2021-04-02 Par sujet Cerdic
Voilà normalement on est bon de nouveau !
Merci

--
Cédric
Le 1 avr. 2021 à 14:12 +0200, erational , a écrit :
> Coucou
>
> Serait-il possible de réparer le fichier archives.xml ?
>
> Il faudrait compléter les attributs du xml pour avoir la forme:
> 
>
> c'est expliqué en détails sur:
> https://core.spip.net/issues/4707
>
> Cela serait chouette de pouvoir signaler aux personnes non geeks
> qu'elles ont de vieux sites qu'il faut mettre à jour :)
>
>
> --
> _
> https://www.erational.org
>
> ___
> 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] Les PR sont coincées dans le tuyau

2021-03-30 Par sujet Cerdic
Pardon oui, c’est mieux avec une URL

https://git.spip.net/spip/spip/pulls/145
https://git.spip.net/spip/spip/pulls/144
https://git.spip.net/spip/spip/pulls/142
https://git.spip.net/spip/spip/pulls/140

par exemple

--
Cédric
Le 30 mars 2021 à 12:34 +0200, cam.lafit , a écrit :
> Hello
>
> Une url pour que je vois un cas pratique ?
>
> Km
>
> Le 30/03/2021 à 11:54, Cerdic a écrit :
> > Hello,
> >
> > Gitea nous dit :
> >
> > "Vérification des conflits de fusion en cours. Réessayez dans quelques
> > instants."
> >
> > Mais comme il a pas dit « Jacques à dit » ça vaut pas.
> > Enfin là ça vaut quand même mais c’est bien embêtant...
> >
> > --
> > 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
> >
> ___
> 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

[spip-dev] Les PR sont coincées dans le tuyau

2021-03-30 Par sujet Cerdic
Hello,

Gitea nous dit :

"Vérification des conflits de fusion en cours. Réessayez dans quelques 
instants."

Mais comme il a pas dit « Jacques à dit » ça vaut pas.
Enfin là ça vaut quand même mais c’est bien embêtant...

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

Re: [spip-dev] Documentation sur la nouvelle constante _CACHE_PROFONDEUR_STOCKAGE

2021-03-18 Par sujet Cerdic
Oui hein ça a pas vocation à être utilisé à tort et à travers, le réglage par 
défaut et parfait dans 99.9% des cas, mais c’est juste pour débloquer la 
situation sur certains hébergement comme évoqué dans le ticket en référence du 
commit, et tant qu’a coder un truc j’ai permis de jouer dans les 2 sens.

--
Cédric
Le 18 mars 2021 à 19:41 +0100, nicod_ , a écrit :
> Le 18/03/2021 à 17:12, peetdu a écrit :
> > Hello,
> >
> > J'ai réussi avec l'aide de b_b et des commentaires dans
> > https://git.spip.net/spip/spip/commit/6aa332397e5a3e8dd80a683e400db855d6ac2826
> > à expliquer comment utiliser cette constante. (voir
> > https://www.spip.net/fr_article6638.html?var_mode=preview)
> >
> > Mais cet article mériterait sans doute de donner des exemples de
> > problèmes que cela permet de traiter :
> >
> > - pourquoi réduire la valeur par défaut ?
> > - pourquoi l'augmenter ?
> >
> > et question subsidiaire : comment certains hébergeurs limitent t'ils la
> > max d'inodes ? Il y a t-il une valeur dans php.ini qui fait cela ?
>
> Pourquoi réduire ou augmenter je ne sais pas précisément te dire en
> fonction de la gestion du cache de SPIP, mais le nombre d'inodes c'est
> lié au système d'exploitation (Linux), pas à PHP.
> Un inode c'est un peu comme un pointeur sur un fichier "actif" (dans le
> sens utilisé).
>
> Quelques infos qui expliquent le principe, et répondent en partie :
> https://www.webhostingsecretrevealed.net/fr/blog/web-hosting-guides/web-hosting-secrets-inodes/
> https://blogpascher.com/tutoriel-wordpress/quest-ce-quun-inode-et-en-quoi-cela-affecte-t-il-votre-site-web-wordpress
>
> --
> nicod_
> ___
> 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] problème avec cache-js

2021-03-18 Par sujet Cerdic
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…)

Proposition encore plus propre :

• dans le php tu construit un tableau des id_xx (les clés primaires des objets 
déclarés) que tu injecte dans le js dynamique (il changera si on 
installe/desinstalle un plugin avec un objet editorial)
• tu fais un js statique pour le plugin inserer_modele avec  une fonction qui 
prend en argument l’urk à modifier, le form target et la liste des id à 
chercher et qui cherche les id_xx dans le form et les ajoute à l'URL

Comme ça tu évites de dupliquer le même code et tu es plus robuste car tu 
risques pas de trouver un id_parent.

Pour la question des id_xx présent ou non en hidden, il faudrait en fait que le 
plugin insère ses propres hidden dans les formulaires sur lesquels il peut être 
activé, pour être certain des informations qu’il doit récupérer (et du coup ça 
éviterait d’avoir besoin d’une fonction js complexe).

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
Le 17 mars 2021 à 19:27 +0100, Maïeul Rouquette , a écrit :
> 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
___
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 Cerdic
Attention ton revert à perdu le patch 
https://git.spip.net/spip-contrib-extensions/inserer_modeles/commit/9eba5fd9ea20ce1d959733fa23ae55c011c29289

--
Cédric
Le 17 mars 2021 à 16:14 +0100, Maïeul Rouquette , a écrit :
> 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
> > <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
___
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 Cerdic
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.

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

Et du coup je pense que @nicod était aussi touché par ce soucis avec ses 
répertoires cache qui gonflaient à tour de bras...

--
Cédric
Le 17 mars 2021 à 16:14 +0100, Maïeul Rouquette , a écrit :
> 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
> > <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
___
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 Cerdic
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

Et il y en a encore qui se demande pourquoi je crie au scandale à chaque fois 
que je vois du JS ou du CSS généré via un squelette SPIP ?

Le JS aurait été statique, cela aurait obligé à se poser des questions et faire 
autrement, plus finement.
Là c’est tellement facile que boum j’envoie n’importe quoi dans le JS sans me 
poser de question et à la fin on rammase les sites à la petite cuillère...

Il faut tout recoder en faisant la tambouille en JS, pas en PHP : le script du 
porte plume ne doit *pas* dépendre de la page ou de l’URL en cours

--
Cédric
Le 17 mars 2021 à 15:14 +0100, Jean Christophe Villeneuve 
, a écrit :
>
> j'ai comparé 2 fichiers venant du porte-plume, générés à 30 min d'intervalle.
> 1 seule différence :
>
> ,{"name":"Insérer un modèle","key":"M","className":"outil_inserer_modeles 
> separateur separateur_apres sepInsMod","beforeInsert":function() 
> {jQuery.modalboxload("http://escal.ac-lyon.fr/spip/spip.php?page=inserer_modeles=oui=2017-11-05=fr",{minHeight:
>  "90%", type: 
> "ajax"});},"dropMenu":[{"id":"inserer_modele_choix_article","name":"Une liste 
> d’articles","className":"outil_inserer_modele_choix_article","beforeInsert":function()
>  
> {jQuery.modalboxload("http://escal.ac-lyon.fr/spip/spip.php?page=inserer_modeles=oui=2017-11-05=fr_modele=choix_article",{minHeight:
>  "90%", type: "ajax"});},"display":true}
> ,{"id":"inserer_modele_album_nivoslider","name":"un album (carousel 
> Nivoslider)","className":"outil_inserer_modele_album_nivoslider","beforeInsert":function()
>  
> {jQuery.modalboxload("http://escal.ac-lyon.fr/spip/spip.php?page=inserer_modeles=oui=2017-11-05=fr_modele=album_nivoslider",{minHeight:
>  "90%", type: "ajax"});},"display":true}
> ,{"id":"inserer_modele_media","name":"un 
> document","className":"outil_inserer_modele_media","beforeInsert":function() 
> {jQuery.modalboxload("http://escal.ac-lyon.fr/spip/spip.php?page=inserer_modeles=oui=2017-11-05=fr_modele=media",{minHeight:
>  "90%", type: "ajax"});},"display":true}
> ]
>
> ,{"name":"Insérer un modèle","key":"M","className":"outil_inserer_modeles 
> separateur separateur_apres sepInsMod","beforeInsert":function() 
> {jQuery.modalboxload("http://escal.ac-lyon.fr/spip/spip.php?page=inserer_modeles=oui_article=177_forum=6039=spip.php%3Farticle177%26lang%3Dfr=fr",{minHeight:
>  "90%", type: 
> "ajax"});},"dropMenu":[{"id":"inserer_modele_choix_article","name":"Une liste 
> d’articles","className":"outil_inserer_modele_choix_article","beforeInsert":function()
>  
> {jQuery.modalboxload("http://escal.ac-lyon.fr/spip/spip.php?page=inserer_modeles=oui_article=177_forum=6039=spip.php%3Farticle177%26lang%3Dfr=fr_modele=choix_article",{minHeight:
>  "90%", type: "ajax"});},"display":true}
> ,{"id":"inserer_modele_album_nivoslider","name":"un album (carousel 
> Nivoslider)","className":"outil_inserer_modele_album_nivoslider","beforeInsert":function()
>  
> {jQuery.modalboxload("http://escal.ac-lyon.fr/spip/spip.php?page=inserer_modeles=oui_article=177_forum=6039=spip.php%3Farticle177%26lang%3Dfr=fr_modele=album_nivoslider",{minHeight:
>  "90%", type: "ajax"});},"display":true}
> ,{"id":"inserer_modele_media","name":"un 
> document","className":"outil_inserer_modele_media","beforeInsert":function() 
> {jQuery.modalboxload("http://escal.ac-lyon.fr/spip/spip.php?page=inserer_modeles=oui_article=177_forum=6039=spip.php%3Farticle177%26lang%3Dfr=fr_modele=media",{minHeight:
>  "90%", type: "ajax"});},"display":true}
> ]
>
>
> Le 17/03/2021 à 14:03, Maïeul Rouquette a écrit :
> > 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 

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

2021-03-17 Par sujet Cerdic
Avant d’user le soleil, on commencerait par dire quelle version de SPIP tu 
utilise précisemment ?
Et notamment, quelle est la version de ton plugin compresseur ?

--
Cédric
Le 17 mars 2021 à 14:03 +0100, Maïeul Rouquette , a écrit :
> 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
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Demande de relance du cron de création master.

2021-03-11 Par sujet Cerdic
Hello,

pour info le cron tourne bien MAIS un on a petit bug : le zip est daté du 
dernier commit, c’est une feature, mais du coup c’est le dernier commit de SPIP 
qui est pris en compte. Et comme il a pas changé le débardeur voit une date 
inchangée pour le zip, et donc ne le remets pas à jour.

On va réflechir à la question : faut-il modifier le débardeur - avec coûts 
techniques induits ? faut-il modifier le datage du zip généré par l’outil 
spip_archives de @marcimat ? faut-il considérer que c’est normal et vivre avec ?

Bref il suffit d’attendre pour que tout rentre dans l’ordre sinon :p

--
Cédric
Le 11 mars 2021 à 08:42 +0100, erational , a écrit :
> Hello
>
> Quelqu'un pourrait relancer le cron pour générer le master s'il vous plait ?
> https://files.spip.org/spip/dev/
>
> Le dernier  date du 09-03-2021 14:08
> (alors qu'il y a des commits hier notamment sur le sanitizer du SVG)
>
> Merci !
>
> --
> _
> https://www.erational.org
>
> ___
> 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] session_get() avec un temps de retard

2021-03-08 Par sujet Cerdic
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
Le 7 mars 2021 à 23:43 +0100, Maïeul Rouquette , a écrit :
> 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
___
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-05 Par sujet Cerdic
Je rappelle que SPIP n’est pas uniquement un produit commercial hein ;)

Il y a des utilisateurs auto-hébergés qui maintiennent eux-même leurs serveurs 
et pour lesquels passer d’une debian à une autre (ou idem si c’est une autre 
distrib) n’est pas trivial, et que historiquement c’est pour ces utilisateurs 
qu’on fait l’effort de supporter des anciennes versions de PHP.

Cela dit, on pourrait décider que la 3.2 serait une sorte de TLS qu’on 
maintiendrait plus longtemps (juste du point de vue failles de secu) pour 
supporter les versions PHP 5.x encore assez longtemps temps, et faire le saut à 
7.1 minimum pour la 3.3

--
Cédric
Le 5 mars 2021 à 08:47 +0100, RastaPopoulos , a écrit :
> Le 04/03/2021 à 17:54, RealET a écrit :
> > Après, d'un point de vue politico-phylosophique, SPIP a toujours cherché à 
> > pouvoir être utilisé dans des environnements accessibles au maximum de 
> > personnes et de pays.
> > De ce point de vue, la compatibilité PHP 5.6 est peut-être bienvenue.
>
> Mais concrètement ? Pour de vrai chez chaque hébergeur connu, c'est quoi ?
>
> Quels sont les versions de PHP proposées par chaque hébergeur un peu connu en 
> France, en Europe ?
>
> Ou au moins : as-tu une liste des hébergeurs qui ne proposent pas plus que 
> PHP 5.6 ? Histoire de quantifier réellement si ça représente beaucoup ou si 
> c'est totalement marginal.
>
> Même les pages persos Free gratuites proposent PHP 7.3 ! Les hébergeurs 
> payants, s'ils sont bloqués à 5.6 c'est que tu te fais arnaquer et que tu 
> devrais changer d'hébergeur et donner ton argent à d'autres gens.
>
> Et si on parle des dédiés, maintenus par des prestataires, là on fait ce 
> qu'on veut dessus, et donc c'est à la charge du prestataire de tenir à jour 
> Debian et PHP.
>
> --
> RastaPopoulos
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [spip-commit] [spip ↪ dev_filtre_balise_img_svg] 2 commits

2021-03-04 Par sujet Cerdic
Non ça remplace pas, mais ça complète pour gérer par exemple des petites images 
de deco ou pictos png : tu le fourni en 64px et tu l’affiches en 32px pour 
qu’il soit de bonne qualité partout.

Pour le SVG cela permet donc de contrôler la taille d’affichage indépendamment 
de la taille par défaut dans le fichier

--
Cédric
Le 4 mars 2021 à 15:10 +0100, jeanmarie , a 
écrit :
> Salut Cédric,
>
> super ces nouvelles fonctionnalités !
>
> Petite question sur la gestion de la densité de l'image avec le
> paramètre x2 (pour être sûr de bien comprendre) : ça force, quoiqu'il
> arrive, une double taille même si l'écran n'est pas HD, c'est pour avoir
> du HD par défaut quoiqu'il arrive ?
> Ça ne remplace donc pas les plugins qui gèrent ça (adaptive_image et
> image_responsive par ex) ?
>
>             jeanmarie
>
>
> Le 04/03/2021 à 12:07, Cerdic a écrit :
> > spip/spip | 2 commits
> > -
> > Par Cerdic, le 4 mars 2021 à 11h16min :
> >
> > Le filtre |balise_img est survitamine :
> > - il peut prendre en premier argumenr une balise img deja formee si besoin 
> > - ie issue d'un filtre image :
> > `[(#FICHIER|image_reduire{200,200}|balise_img{'un nuage','spip_logo'})]`
> > - il paut prendre un dernier argument size pour forcer la taille sous 
> > plusieurs formes :
> > * `x1.5`, `x2` ou `x3` permet de forcer une densite de 1.5, 2 ou 3 (le x 
> > est ici le multiplicateur de densite par rapport a la taille initiale)
> > une image de largeur 200px affichee avec un `x2` aura donc un attribut 
> > `width='100'`
> > * Un nombre seul comme `64` pour forcer une image carree avec `width='64' 
> > height='64'`
> > * Une largeur ET une hauteur sour la forme `1024x640` pour avoir un 
> > `width='1024' height='640'`
> > * Une largeur seule et une hauteur automatique sous la forme '1024x*` pour 
> > avoir donc un `width='1024'` et un height ajuste automatiquement pour 
> > respecter les proportions initiales de l'image
> >
> > Pour faciliter l'utilisation du filtre, l'argument de taille (optionnel) 
> > arrive toujours en dernier, meme si on ne precise pas de alt ou de class :
> > `[(#FICHIER|balise_img{1024x640})]`
> > `[(#FICHIER|balise_img{'un nuage',1024x640})]`
> > `[(#FICHIER|balise_img{'un nuage','spip_logo',1024x640})]`
> >
> > Mais si jamais le alt ou la class sont ambigu et peuvent etre interpretes 
> > comme une taille, il suffit d'indiquer une taille vide pour lever 
> > l'ambiguite :
> > `[(#FICHIER|balise_img{'un nuage','x2',''})]`
> >
> > Le filtre peut donc ainsi facilement etre utilise pour ajuster l'affichage 
> > d'image en x2 ou x3 pour prendre en compte les ecrans retina :
> > `[(#FICHIER|image_reduire{400,400}|balise_img{'Mon image HD',x2})]`
> >
> >
> > *Modifié*
> > ecrire/inc/filtres.php
> >
> > Détails : 
> > https://git.spip.net/spip/spip/commit/4bff8927949d6fc07c233a19467baaccea170303
> >
> > ==
> > Par Cerdic, le 4 mars 2021 à 12h03min :
> >
> > Le filtre |balise_svg prend le meme fonctionnement que le filtre 
> > |balise_img et permet de forcer la dimension de l'image avec un dernier 
> > argument size qui accepte la meme syntaxe que pour balise_img (`x2`, `512`, 
> > `1024x*`, `1024x640`)
> >
> > `[(#FICHIER|balise_svg{1024x640})]`
> > `[(#FICHIER|balise_svg{'un nuage',1024x640})]`
> > `[(#FICHIER|balise_svg{'un nuage','spip_logo',1024x640})]`
> >
> > Si le alt ou la class sont ambigu et peuvent etre interpretes comme une 
> > taille, il suffit d'indiquer une taille vide pour lever l'ambiguite
> > `[(#FICHIER|balise_svg{'un nuage','x2',''})]`
> >
> > Au passage la fonction `taille_image()` fonctionne aussi sur un SVG inline
> >
> >
> > *Modifié*
> > ecrire/inc/filtres.php
> >
> > Détails : 
> > https://git.spip.net/spip/spip/commit/89492d27eda1608acf5ea9623fb8c7fbee92b29b
> >
> > ___
> > spip-com...@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-commit
> > dev: http://trac.rezo.net/trac/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
___
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] Bug Bonux et Mailsubscribers

2021-02-24 Par sujet Cerdic
Merci Matthieu, c’est moi qui avait cassé le truc :p

--
Cédric
Le 24 févr. 2021 à 10:23 +0100, Matthieu Marcillaud , a 
écrit :
> Le 23/02/2021 à 21:35, CSI a écrit :
> > Bonjour,
> >
> > La mise à jour de Spip-Bonux de 3.5.6 à 3.7.1 casse l'import de contacts
> > dans MailSubscribers.
>
> Merci. Corrigé en version 3.7.2 de bonux normalement.
>
> MM.
> ___
> 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] Bug Bonux et Mailsubscribers

2021-02-24 Par sujet Cerdic
Sur l’un ou l’autre, mais a priori ça doit être la fonction d’import csv, 
générique, de Bonux, et il faut un fichier test qui permet de reproduire

--
Cédric
Le 23 févr. 2021 à 21:35 +0100, CSI , a écrit :
> Bonjour,
>
> La mise à jour de Spip-Bonux de 3.5.6 à 3.7.1 casse l'import de
> contacts dans MailSubscribers. Avec 3.5.6 ça marche, avec 3.7.1 au
> retour de la sélection de fichier on n'a pas de prévisualisation des
> adresses qui vont être importées et juste quelques caractères
> parasites genre {{}} puis {{}} ou un truc du genre.
>
> Je veux bien faire un ticket mais je ne sais pas ... Bonux ou
> MailSubscribers ? Spip à jour 3.2.9.
>
> --
> Pierre
> ___
> 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] [Spip-zone-commit] [adaptive_images] si pas de largeur d'image, on retourne une chaine vide (...)

2021-02-17 Par sujet Cerdic
Hello,

dans quel cas ça arrive ? Pourquoi on ne retourne pas la balise img d’origine 
dans ce cas ?
Et sinon attention, le code de la lib vient de là 
https://github.com/nursit/AdaptiveImages
donc on risque de perdre la modif à la prochaine mise à jour de la lib...

--
Cédric
Le 17 févr. 2021 à 18:02 +0100, tofulm , a écrit :
> spip-contrib-extensions/adaptive_images
> -
> Par tofulm, le 17 février 2021 à 18h01min :
>
> si pas de largeur d'image, on retourne une chaine vide sinon, division par 0
>
>
> *Modifié*
> lib/AdaptiveImages/AdaptiveImages.php
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/adaptive_images/commit/238623ccfb6db12a65674590014b8d00278ff1b6
>
> ___
> spip-zone-com...@rezo.net - 
> https://listes.rezo.net/mailman/listinfo/spip-zone-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-bonux] 2 commits

2021-02-16 Par sujet Cerdic
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 :
> Cerdic a écrit le 16/02/2021 à 14:44 :
> > spip-contrib-extensions/spip-bonux | 2 commits
> > -
> > Par Cerdic, le 16 février 2021 à 11h34min :
> >
> > Amelioration du support des retour ligne dans les champ texte des CSV : 
> > c'est supporte par le standard et LibreOffice, on le permet donc, mais pas 
> > par Excel, on les supprime donc dans le cas ou on fait un export de type 
> > csv excel (tsv + charset iso)
> >
> >
> > *Modifié*
> > inc/exporter_csv.php
> >
> > Détails : 
> > https://git.spip.net/spip-contrib-extensions/spip-bonux/commit/67fa28751fa00fea2607c486bd89266441bc8c68
> >
> > ==
> > Par Cerdic, le 16 février 2021 à 14h43min :
> >
> > Ajout d'un exporteur xls qui permet un export plus etendu que le TSV limite 
> > : support des champs texte multilignes, des champs date et nombre
> > + on modifie la signature de la callback CSV pour unifier avec l'export XLS 
> > en retirant le delim des arguments passes
>
> Bonjour Cédric,
>
> Au cas où, est-ce que tu as vu
> https://contrib.spip.net/Spout_SPIPCSV-export-CSV-ameliore-pour-SPIP ?
> Ça marche en particulier directement depuis l'export format excel de
> Formidable (facile à tester donc).
>
> Je teste de mon côté dès que je peux avec ce que tu viens de faire.
>
>
> --
> RealET
>
>
> ___
> 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] [dist] Fix https://core.spip.net/issues/3431 : utiliser (...)

2021-02-09 Par sujet Cerdic
La viewbox et le width/heigh sont 2 trucs séparés qu’on peut décoréler oui.

Et oui c’est un peu verbeux pour emboiter avec balise_svg :(

[(#CHEMIN{spip.svg}|image_reduire{60,40}|extraire_attribut{src}|balise_svg)]

mais je vais y revenir, car même pour les balises img on a de plus en plus 
besoin de piloter les dimensions lors de l’insertion (pour les images x2, x3 … 
par exemple) et donc je pense proposer une extension de balise_img qui permet 
ça et du coup de manière homogène pour balise_svg

--
Cédric
Le 9 févr. 2021 à 20:37 +0100, nicod_ , a écrit :
> Le 09/02/2021 à 20:26, Cerdic a écrit :
> > Sorry c’est l’optimisation du svg que j’ai fait à la fin qui a fait
> > sauter le width et le height
> > J’ai rétabli
> Le viewbox qui colle pas, c'est pas grave ?
>
> > Sinon pour mémoire |image_reduire s’applique aussi aux SVG.
> Euh, tu l'utilises comment concrètement, avec balise_svg ?
> Chez moi ça marche pas, du tout.
>
> > Les fonctions de inc/svg sont des fonctions internes supports pour les
> > filtres images qui doivent rester l'usage
>
>
> --
> nicod_
>
___
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 Cerdic
Sorry c’est l’optimisation du svg que j’ai fait à la fin qui a fait sauter le 
width et le height
J’ai rétabli

Sinon pour mémoire |image_reduire s’applique aussi aux SVG.
Les fonctions de inc/svg sont des fonctions internes supports pour les filtres 
images qui doivent rester l'usage

--
Cédric
Le 9 févr. 2021 à 20:16 +0100, 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 ?
>
> --
> nicod_
___
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] Plantage traitement d'images

2021-02-02 Par sujet Cerdic
Oui enfin achtung hein.

SPIP propose d’utiliser convert, mais ça ne concerne que les redimensionnements 
d’image (|image_reduire), le filtre historique, utilisé dans l’espace privé, et 
qui donc bénéficié d’une quintuple implémentation 
(gd/gd2/convert/netpbm/imagick).

Pour tous les autres filtres de traitement d’image (donc a commencer par 
|image_recadre), c’est uniquement GD2 qui est utilisé, quel que soit le réglage 
de l’espace privé.

Ce plantage brutal et silencieux de GD est une plaie depuis mathusalem, et il y 
a pas vraiment de solution
https://stackoverflow.com/questions/1117344/a-fail-safe-way-to-prevent-gd-image-library-from-running-out-of-memory-php

Enfin là je perçois bien une idée qui serait de lancer un process spip-cli pour 
faire chaque traitement d’image dans un process indépendant au lieu de le faire 
dans le process principal, ce qui éviterait le process principal d’échouer 
brutalement.

Mais ça repose in fine sur la disponibilité d’exec, ce qui n’est pas universel, 
donc c’est un peu compliqué de passer du temps sur une solution qui ne serait 
que partielle, ou alors il faudrait le faire en http sur soit même si on a pas 
exec...

Bref le ration energie à depenser/emmerdements fait que pour le moment on 
traine toujours ce problème...

--
Cédric
Le 2 févr. 2021 à 15:11 +0100, nicod_ , a écrit :
> Le 02/02/2021 à 14:57, nicod_ a écrit :
> > Le 02/02/2021 à 14:43, Bruno Bergot a écrit :
> > > > Sinon, par expérience, est ce que Convert serait plus efficace / plus
> > > > fiable que GD ?
> > >
> > > Pour faire court, oui.
> > >
> > > Convert ne bloquera pas PHP, même s'il est lui aussi tributaire des
> > > ressources qu'on lui alloue.
> >
> > Ok, en lisant le code des filtres je comprends : convert passe par un
> > appel à une commande système (exec), donc si ça plante ça n'empêche pas
> > la suite du traitement PHP, contrairement à GD qui utilise des fonctions
> > PHP.
> > J'ai bon ?
>
> Mais du coup, concrètement, quelles sont les limites de convert, au
> niveau système ?
>
> --
> nicod_
> ___
> 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] [Git] =?utf-8?Q?Contr=C3=B4le_d'int=C3=A9grit=C3=A9_?=: demande de copie de dépôt

2021-01-26 Par sujet Cerdic
Hello,

C’est le moment de nous dire si les dépôts mirroir sont utiles !

https://git-mirror.spip.net/spip-contrib-extensions/porte_plume_gbe
https://git-mirror.spip.net/spip-contrib-extensions/gabarits
https://git-mirror.spip.net/spip-contrib-extensions/doc2article
https://git-mirror.spip.net/spip-contrib-extensions/souhaits
https://git-mirror.spip.net/spip-contrib-extensions/app
https://git-mirror.spip.net/spip-contrib-extensions/colonne_raccourci
https://git-mirror.spip.net/spip-contrib-extensions/metasplus

Si le clone de ces dépôts ne te suffit pas, on a évidemment sur le disque du 
serveur un clone complet depuis git.spip.net en mode —mirror de chacun des 
dépôts source...

--
Cédric
Le 26 janv. 2021 à 10:28 +0100, cam.lafit , a écrit :
>
> Bonjour
> Dans le cadre d'un contrôle d'intégrité des divers dépôts du serveur, je 
> constate des erreurs mineures que j'aimerai auditer.
> Pour ce faire j'aurais besoin d'avoir de copies externes (au serveur) de ces 
> projets :
> spip-contrib-extensions/porte_plume_gbe
> spip-contrib-extensions/gabarits
> spip-contrib-extensions/doc2article
> spip-contrib-extensions/souhaits
> spip-contrib-extensions/app
> spip-contrib-extensions/colonne_raccourci
> spip-contrib-extensions/metasplus
>
> Quand je parle de copie cela englobe tout le contenu local du .git
>
> Si vous possédez de telle copie cela m'intéresse fortement, merci à vous
>
> Km
>
>
> ___
> 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] Accès restreint 4.1.0 pas taggé ?

2021-01-23 Par sujet Cerdic
Hello,

désolé, j’avais pas pris le temps de regarder en détail.

Donc en effet, aucun raison, si ce n’est que je tag pas systematiquement, ça me 
laisse aussi le temps de tester.
Mais donc là on pourrait refaire un tag, mais probablement avec tes modifs 
postérieures à la v4.1.0, donc il faudrait incrementer la version en 4.1.1 et 
tagguer

--
Cédric
Le 23 janv. 2021 à 13:20 +0100, nicod_ , a écrit :
> Le 20/01/2021 à 19:08, nicod_ a écrit :
> > Salut Cédric,
> >
> > je voulais savoir s'il y avait une raison ?
> > C'est toujours la 4.0.0 qui remonte dans SVP.
>
> Je relance...
>
> --
> nicod_
> ___
> 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

[spip-dev] Certificat sur https://latex.spip.net/ et math.spip.org

2021-01-20 Par sujet Cerdic
Hello,

visiblement on a pas/plus de certificat sur https://latex.spip.net ni sur 
https://math.spip.org
alors que par ailleurs on a changé l’URL dans le core pour la mettre en https

cf 
https://git.spip.net/spip/spip/commit/222cf3549a22f5d3f8125a4e341646bf69931f96
suivi de
https://git.spip.net/spip/spip/commit/067bd798c0e0f9c9f37078a1d6a7a3bbbebaf80a

est-ce qu’on sait/peut réparer le certificat sur https://math.spip.org a minima 
?
ou est-ce qu’on remet une URL en http dans le core ?

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

Re: [spip-dev] [spip ↪ boucles_anonymes] Introduction des boucles anonymes : dans la plupart des (...)

2021-01-18 Par sujet Cerdic
Oui ça marche, mais avec en utilisant l’identifiant anonyme dans la variable 
debut_xxx ce qui veut dire :

• que c’est pas joli (mais ça osef un peu)
• que c’est pas super stable (car si tu changes le contenu de ta boucle a 
priori l’id anonyme va changer)
• qu’il vaut mieux du coup utiliser une pagination nommée dans ce cas (ce qui 
ne semble pas documenté ici https://www.spip.net/fr_article4867.html mais l’est 
ici https://www.spip.net/fr_article3367.html)


--
Cédric
Le 18 janv. 2021 à 14:15 +0100, nicod_ , a écrit :
> Le 18/01/2021 à 12:40, Cerdic a écrit :
> > spip/spip
> > -
> > Par Cerdic, le 18 janvier 2021 à 12h34min :
> >
> > Introduction des boucles anonymes : dans la plupart des cas les boucles 
> > sont simples, non imbriquees, et on a pas besoin de les nommer
> > Il est donc possible d'ecrire des boucles anonymes, sans nom, completes ou 
> > partielles, du moment qu'on ne les imbrique pas :
>
> Hey, c'est rigolo ça :)
> La pagination marche aussi sur les boucles anonymes ?
>
> --
> nicod_
> ___
> 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] [Spip-zone-commit] Accès git

2021-01-18 Par sujet Cerdic
Hello Joël,

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

Je te rappelle donc que l’utilisation des outils communautaires est soumis à 
acceptation complète et sans équivoque de la charte 
https://www.spip.net/fr_article6431.html
et j’attire ton attention toute particulière sur le paragraphe "Buts et valeurs"

C’est un peu difficile de venir d’un côté cracher dans la soupe du projet 
politique et inclusif et de l’autre venir dire
« hé mais les gens, j’ai plus les accès, vous pouvez me les rétablir ?
Parce que bon de toute façon toutes ces discussions c’est de la gesticulation, 
on s’en fout bien et moi je veux continuer à faire mon petit bizness dans mon 
coin avec vos outils communautaires »

Donc je ne sais pas si quelqu’un•e a supprimé ton compte, mais ce serait tout à 
fait légitime.
Et a contrario, ça me semble tout à fait inapproprié de te réouvrir un compte 
comme si de rien n’était, tu ne crois pas ?

--
Cédric
Le 17 janv. 2021 à 22:09 +0100, BERTRAND Joël , a écrit :
> Bruno Bergot a écrit :
> > Hop,
> >
> > Le 15/01/2021 à 18:43, BERTRAND Joël a écrit :
> > > Jacques B a écrit :
> > > > Bonjour,
> > > > Est-ce que tu as un compte valide sur git ?
> > > > https://git.spip.net/explore/users
> > >
> > > Bonsoir,
> > >
> > > J'avais. Mais comme je ne peux plus poster sur les listes de spip non
> > > plus, je me demande si une petite main n'est pas passée pour fermer le
> > > compte en question.
> > >
> >
> > J'ai vérifié, il n'y a aucun compte portant ce mail sur git.spip.net
> >
> > Qui t'avait créé ton compte ? Ça date de quand ? (désolé j'ai la flemme
> > de chercher dans les archives de la liste ^^)
>
> Bonsoir,
>
> S'il n'y a pas moyen de retrouver, on peut peut-être en recréer un pour
> que je puisse mettre à jour Multiflex ? D'ailleurs, j'ai vu que sur le
> git, il y a deux versions du plugin en question. Laquelle est la bonne ?
>
> Bien cordialement,
>
> JB
> ___
> 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] Gitea et le débardeur

2021-01-05 Par sujet Cerdic
Hello,

Oui, le debardeur récupère déjà les zips de gitea, c’est là que ça se passe
https://git.spip.net/spip-contrib-extensions/debardeur/src/branch/master/debardeur/connecteur/gitea.php#L63

Par contre pour github on est obligé de les reconstruire parce que l’API de 
github est limitée en nombre de requêtes sauf à sortir la grosse artillerie en 
faisant une auth oauth etc, mais j’ai laché l’affaire. Du coup on clone en git 
et on zip nous même mais c’est à la marge.

--
Cédric
Le 5 janv. 2021 à 18:52 +0100, Eric Lupinacci , a écrit :
> Yop,
>
> > Le mar. 5 janv. 2021 à 17:57, RastaPopoulos  a 
> > écrit :
> > > Le 05/01/2021 à 17:13, Eric Lupinacci a écrit :
> > > > 1) Le problème ne concerne pas les tags ni la génération systématique 
> > > > des zips par le débardeur. On pourrait même étendre à l'ensemble des 
> > > > tags si on voulait... Maintenant, ne pourrait-on pas éviter de 
> > > > regénérer les zips existant sur Gitea ?
> > >
> > > C'est pas déjà le cas, genre si le débardeur voit que ça existe sur 
> > > gitea, il le récupère tel quel ?
> > >
> >
> > Ben tu me mets le doute en fait.
> > Cédric ou Matthieu doivent savoir confirmer ou infirmer.
> >
> >
> > >
> > > - https://core.spip.net/issues/3017 dont la conséquence est que SVP 
> > > devrait être amélioré pour connaitre plus qu'une unique mise à jour 
> > > existante : en effet à un instant T, un plugin peut avoir une version 
> > > majeure sortie X+N *et* une version Y+N ou même juste Z+N, et 
> > > l'utilisateur ne veut PAS forcément changer de X, mais bien changer que Y 
> > > voire même ne changer que Z pour être sûr de ne rien casser et avoir 
> > > juste les corrections. Au niveau ergonomique, le travail est en gros 
> > > fini, mais par contre, la conception de SVP ne le permet pas, donc pas 
> > > possible de générer plusieurs boutons de mises à jour différentes à la 
> > > fois. (Exemple de Sézi dans la maquette, qui a 4 mises à jour possible à 
> > > la fois)
> > >
> > > Ce dernier point est le plus compliqué il me semble, car SVP c'est 
> > > compliqué et qu'il y a eu un gros angle mort de conception sur ce point 
> > > on dirait. Cependant j'ai l'impression que pour les utilisateurs finaux 
> > > (qui ne suivent pas le code), c'est encore bien plus important qu'avoir 
> > > le changelog complet : les gens devraient absolument pouvoir faire des 
> > > mises à jour mineures, sans qu'on leur montre uniquement la majeure, et 
> > > illes sont capables de choisir l'option la moins dangereuse pour elleux 
> > > même sans changelog complet avec les phrases claires et simples (on 
> > > comprend la différence entre "màj corrective/fonctionnelle/majeure" et 
> > > donc la dangerosité ou pas à changer sans tout péter).
> >
> > Je ne suis pas sur que ce soit si compliqué en fait sauf peut-être pour la 
> > logique de dépendances.
> > On a commencé une réflexion avec Matthieu (qui a aussi débuté le codage) 
> > pour continuer le découpage de SVP en un plugin chargé de construire le 
> > référentiel (unique sur un serveur donné) et le plugin SVP d'installation 
> > présent sur chaque site qui lit les informations en provenance du premier 
> > (avec l'idée du passage à composer in fine).
> > Je pense qu'on peut réfléchir à introduire une logique plus large sur le 
> > choix des versions mais il faut spécifier exactement ce que l'on veut 
> > réaliser.
> >
> >
> > >
> > > Mais faisons déjà les choses "simples", sur lesquelles on a la main plus 
> > > vite.
> > >
> >
> > Ok, on s'y prend comment pour lancer ce chantier ?
> >
> > ++
> > 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
___
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] Les PR sont coincées !

2020-12-30 Par sujet Cerdic
Hello Camille,

je sais pas si c’est lié à la mise à jour, mais toutes les PR de 
https://git.spip.net/spip/spip/ sont bloquées dans un état "Vérification des 
conflits de fusion en cours. Réessayez dans quelques instants."

Au début j’ai cru que c’était parce que c’étaient des vieilles PR difficiles à 
traiter, mais même sur une PR toute simple et récente on a le problème
https://git.spip.net/spip/spip/pulls/82

--
Cédric
Le 22 déc. 2020 à 09:43 +0100, cam.lafit , a écrit :
> Bonjour
>
> De 10 à 11h le serveur git va basculer en maintenance. Il y a plusieurs
> mises à jour de retard, alors je profite d'un petit créneau pour m'y coller.
>
> Km
> ___
> 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] fichier des traductions (archivelists)

2020-12-28 Par sujet Cerdic
Hello,

non non non, il ne faut pas confondre le archivelist-externals.txt et le 
traductions.txt qui ont 2 buts totalement séparés.

# Pour la génération des zips
Par défaut on prend tous les repositories de git.spip.net, et on créé un zip 
pour chaque tag.
Dans le cas où un projet n’est pas hébergé sur git.spip.net mais qu’on veut 
quand même générer des zips pour le rendre visible via SVP notamment, alors on 
utilise archivelist-externals.txt, qui ne contiendra donc que des références 
vers des projets externes

# Pour la traduction des plugins
Là il faut toujours déclarer manuellement ce qu’on veut traduire, parce que ce 
sont des humains qui travaillent derrière, et que tout n’est pas toujours dans 
un état qui mérite traduction.

Donc pour la traduction, on déclare dans le fichier traduction.txt, que ce soit 
un projet de git.spip.net ou un projet externe sur
gihub ou une autre plateforme.

Pour ce qui concerne les plugins « deprecated » ou en tout cas que j’ai marqué 
comme tels dans le fichier traductions.txt, ce sont essentiellement des plugins 
plus maintenus mais qui ont été traduits. A priori le mieux est de les laisser 
là, car de toute façon même si tu les supprime du fichier ils resteront tels 
quels dans la base de trad.spip.net, mais on aura perdu le lien.

--
Cédric
Le 28 déc. 2020 à 20:28 +0100, Franck , a écrit :
> Hello 
> Bein si, justement, il y a bien un problème, car ils sont dans 
> traductions.txt et non dans archivelist-externals.txt alors qu'ils sont sur 
> githup
> Sinon, tu aurais un avis pour les plugs dit "deprecated" ? qui sont dans le 
> fichier "traduction.txt"
> Franck
>
> -Message d'origine-
> De : Bruno Bergot 
> Envoyé : lundi 28 décembre 2020 14:57
> À : Franck ; 'SPIP-Dev' 
> Objet : Re: [spip-dev] fichier des traductions (archivelists)
>
> Hop,
>
> Le 27/12/2020 à 12:05, Franck a écrit :
> >
> > Il y a aussi des cas un peu particuliers comme « seenthis » (
> > https://git.spip.net/spip-contrib-outils/archivelists/src/branch/maste
> > r/traductions.txt#L1348
> >
> > ) qui bien qu’il y a des plugs « seenthis » sur git
> > https://git.spip.net/spip-contrib-extensions?tab=
> >  > =seenthis> =recentupdate=seenthis le squelette se trouve sur
> > github https://github.com/seenthis/seenthis_squelettes et donc ne
> > devrait pas être dans le fichier
> > https://git.spip.net/spip-contrib-outils/archivelists/src/branch/maste
> > r/traductions.txt mais plutôt dans
> > https://git.spip.net/spip-contrib-outils/archivelists/src/branch/maste
> > r/archivelist-externals.txt
> >
> >
> >
> > Concernant geodiversite/geodiversite_album/geodiversite_balades, ils
> > ne sont que sur github, donc pareil, ils devraient être dans
> > https://git.spip.net/spip-contrib-outils/archivelists/src/branch/maste
> > r/archivelist-externals.txt et non dans:
> > https://git.spip.net/spip-contrib-outils/archivelists/src/branch/maste
> > r/traductions.txt#L1351
> >
> >
>
> Si je ne dis pas de bêtise :
>
> - archivelist-externals.txt sert à générer des zips pour des repos non 
> présents chez nous
> - traductions.txt sert à indiquer à salvatore que ces repos doivent être 
> proposés sur trad.spip.net
>
> Donc, il n'y a pas de problème avec seenthis et geodiversite.
>
> ++
> b_b
>
> ___
> 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] [Spip-zone-commit] [tarteaucitron] 2 commits

2020-12-28 Par sujet Cerdic
Salut Klaus,

j’ai vu que tu avais travaillé sur la traduction allemande de tarteaucitron.
Malheureusement, trad.spip.net était branché sur une vieille version de github, 
et du coup n’était pas à jour.

Je viens de tout resynchroniser et du coup il y a des chaines modifiées et de 
nouvelles chaines, et l’export de la langue de n’a pas été fait.
Je te laisse revoir les chaines modifiées et ajoutées :

https://trad.spip.net/tradlang_module/tarteaucitron?lang_orig=fr_cible=de


--
Cédric
Le 28 déc. 2020 à 09:36 +0100, Git-commit , a écrit :
> spip-contrib-extensions/tarteaucitron | 2 commits
> -
> Par klaus++, le 28 décembre 2020 à 09h35min :
>
> [Salvatore] [source:lang/ paquet-tarteaucitron] Export depuis 
> https://trad.spip.net de la langue de
>
>
> *Ajouté*
> lang/paquet-tarteaucitron_de.php
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/tarteaucitron/commit/449b39e653556afee5659c40302dafa5829c8311
>
> ==
> Par Salvatore, le 28 décembre 2020 à 09h35min :
>
> [Salvatore] [source:lang/ paquet-tarteaucitron] Export depuis 
> https://trad.spip.net de la langue fr
> [Salvatore] [source:lang/ paquet-tarteaucitron] Mise a jour du bilan depuis 
> https://trad.spip.net
>
>
> *Modifié*
> lang/paquet-tarteaucitron.xml
> lang/paquet-tarteaucitron_fr.php
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/tarteaucitron/commit/f36aea4774abe639d0112118d17b74d1be900e2f
>
> ___
> spip-zone-com...@rezo.net - 
> https://listes.rezo.net/mailman/listinfo/spip-zone-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] Critères optionnel avec opérateur : doc imprécise ou bug?

2020-12-18 Par sujet Cerdic
franchement, non, on va pas compliquer ce critère déjà incompréhensible.
Limite toi à {id_bidule?} et pour le reste du fait un critère personalisé si 
besoin.

Le jour où on saura faire un critère conditionnel compréhensible et utilisable 
avec un opérateur, on aura pas de remords à casser la compat vu comment 
l’existant ne fonctionne pas vraiment

--
Cédric
Le 18 déc. 2020 à 14:20 +0100, Maïeul Rouquette , a écrit :
> Le vendredi 18 décembre 2020 à 14:16 +0100, nicod_ a écrit :
> > Le 16/12/2020 à 14:00, Eric Lupinacci a écrit :
> > > En fait, je ne sais pas si je dis une connerie (c'est possible
> > > hein)
> > > mais le #ENV{variable} est presque inutile puisqu'on va chercher
> > > une
> > > variable de même nom que le critère lui-même ?
> >
> > C'est mon impression aussi.
> > En fait je n'utilise que {id_bidule?}, jamais autre chose.
> >
>
> c'est utile si tu a des comparateurs d'autres qu'égalité,
> encore qu'on pourait imaginer une syntaxe abrégée
> {id_bidule ?>}
>
> mais bon ce serait abscon
>
> ___
> 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] [compositions] Ajout de l'icone 16px manquante dans le menu + (...)

2020-12-17 Par sujet Cerdic
A propos de flex ? juste mettre un h1 en flex pour faire l’alignement de 
l’image en début, pourquoi pas, mais c’est inattendu.

Là j’ajoute un small dans le h1 pour afficher une info en plus et l’affichage 
est foiré parce que tout se comporte en blocs, sans marge, avec des alignement 
blocs alors qu’on est dans un h1 et qu’on attends un comportement inline de ce 
qu’on mets dedans.

Disons que ça correspond pas du tout aux conventions et aux usages dans SPIP 
(qui certes datent et gagneraient beaucoup à être revues, mais c’est un autre 
sujet...)

--
Cédric
Le 17 déc. 2020 à 11:49 +0100, nicod_ , a écrit :
> Le 17/12/2020 à 10:56, Cerdic a écrit :
> > spip-contrib-extensions/compositions
> > -
> > Par Cerdic, le 17 décembre 2020 à 10h55min :
> >
> > Ajout de l'icone 16px manquante dans le menu + affichage du nom de fichier 
> > dans la page composition + petits ajustements styles de ce fait - flex 
> > c'est bien mais ca correspond pas a l'usage dans spip et du coup c'est un 
> > peu la surprise... on revient a du old school donc
> >
> > Détails : 
> > https://git.spip.net/spip-contrib-extensions/compositions/commit/13d96f1d3d8044e090b575d9622d8ef328785822
>
>
> > flex c'est bien mais ca correspond pas a l'usage dans spip
>
> Je comprends pas, tu peux préciser ?
>
> --
> nicod_
> ___
> 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] Critères optionnel avec opérateur : doc imprécise ou bug?

2020-12-16 Par sujet Cerdic
oui mais non.
En fait je pense que cette extension du {id_article?} initial était une fausse 
bonne idée.
Le fonctionnement actuel est lié à plusieurs raisons qui ne sont certes pas de 
bonnes raisons, mais les justifications techniques :

• au départ existait uniquement {id_article?} donc qui testait implicitement 
l’existence d’un #ENV{id_article} et le cas échéant le prenait en compte et 
sinon ignorait le critère
• l’extension sous la forme {id_article?=#ENV{truc}} est donc une extension de 
ça et continue à tester uniquement la présence de #ENV{id_article}
• id_article est forcément statique, et on sait quoi vérifier, c’est énonçable 
lors de la compilation
• #ENV{truc} est totalement dynamique et peut aussi bien être #ENV{#GET{toto}} 
ou #GET{truc} quoi que ce soit d’autre, autant dire que "vérifier que dans le 
#ENV on a cette variable » n’a plus de sens
• a la limite il faudrait étendre avec quelque chose du genre « si le membre 
utilisé pour la comparaison est null, on ignore la condition, sinon on 
l’applique » car c’est ce qui s’approche le plus de « il y a une variable 
id_article dans le env}
• mais voila, le compilateur est ainsi fait que l’on caste a tous les etages, 
et je ne pense pas qu’on soit en mesure de distinguer véritablement la valeur 
null (=pas de valeur) d’une liste vide par exemple (qui doit donc retourner une 
selection vide) ou d’une valeur zéro

Bref, il y a bug quelque part, mais peut-être à l’introduction même de cette 
feature que je prends soin de ne jamais utiliser car trop ambigu et incertaine 
à mon avis (sans compter que si un jour on est capable de lui donner le sens 
attendu, ça cassera tous les usages...)

--
Cédric
Le 16 déc. 2020 à 13:47 +0100, RastaPopoulos , a écrit :
> Le 16/12/2020 à 13:32, Maïeul Rouquette a écrit :
> > Donc : incompréhension de la doc, ou bug ?
>
> Les deux :p
>
> 1) La doc c'est pas assez clair et oui il faudrait être encore plus explicite 
> que ça.
>
> 2) Moi je considère que c'est au moins un demi-bug, un gros gros manque, car 
> à partir du moment où un critère permet de préciser *ce qu'on veut* comme 
> comparaison à droite : un #ENV ou un #GET ou un #ARRAY etc, alors c'est ÇA 
> qui devrait être testé si vide ou pas. En effet, ce n'est pas parce qu'il 
> existe le critère {truc} qu'on va vouloir l'utiliser QU'UNE unique fois dans 
> la boucle, et que donc c'est forcément #ENV{truc} qu'il faut tester. Si par 
> exemple on a plusieurs filtres sur le même critère : {truc #ENV{filtre1}} 
> {truc #ENV{filtre2}} : c'est bien ces deux valeurs là qu'on veut tester. Et à 
> peu près tout critère peut être utilisé autant de fois qu'on veut !
>
> --
> RastaPopoulos
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2020-12-11 Par sujet Cerdic
Hello,

je suis pas trop chaud pour cette modif qui a été introduite.

Il y a 2 possibilités :

• soit un permet dans la configuration du plugin d’afficher une explication 
dans le formulaire, en permettant alors de saisir le texte a afficher depuis le 
formulaire de configuration
• soit on a aucune configuration, et ce pourrait etre juste un texte que l'on 
passe en appelant le formulaire, en option (il y a un tableau option en second 
argument qui permet deja de personaliser des choses)

MAIS tout cela me parait bancal, car cela présume de ce que va faire le 
formulaire, qui peut être utilisé pour souscrire à une ou plusieurs listes, et 
chaque liste et site peuvent avoir des usages très différents.

Chaque liste peut par ailleurs fournir une description de ce à quoi elle sert, 
et il me semble que ce serait le bon endroit pour mettre un texte aguicheur 
donnant envie de s’abonner (car c’est bien de cela qu’il sagit au final)

ENFIN j’aimerai fortement éviter que ce formulaire de souscription ne devienne 
un arbre de noël à options, comme on trouve dans certains plugins.
Je pars du principe que de toute façon on couvrira jamais 100% des besoins, et 
je préfère avoir quelque chose de simple et propre qui couvre 80%, a charge 
pour ceux qui veulent plus de faire un peu de personnalisation, qu’une usine à 
gaz qui fasse 90%

Eventuellement on peut envisager de faire, à côté, sous un autre nom, ou dans 
un plugin de complément, un formulaire d’inscription newsletter 
multiconfigurable qui fasse tout ou presque.
Mais je rappelle qu’il y a déjà une option de formidable qui permet de faire 
les inscriptions à une liste, et qui peut donc être utilisé pour faire de la 
personalisation de formulaire d’inscription.

Bref, cette modif me parait pas très adaptée ni souhaitable, et en effet comme 
le rappelle b_b, une PR c’est pas mal pour discuter d’une proposition :)

--
Cédric
Le 11 déc. 2020 à 20:54 +0100, plac...@roxing.net, a écrit :
>
> > +1 si on doit pouvoir ajouter un texte c'est uniquement optionnel, par 
> > défaut vide, et l'explication du champ doit juste être pour dire quoi 
> > configurer dedans. Mais aucun exemple entier comme ça de texte qui seront 
> > forcément totalement différent sur chaque site, suivant chaque contexte, 
> > pour ce besoin je vois pas de phrase qui serait générique (et par défaut 
> > c'est rien comme avant de toute façon).
> >
>
> Ah ouais, conditionner l'affichage de l'explication à une longueur de la
> chaîne non nulle, c'est pas bête (et ça économise l'option de configuration)
>
> Le question sous jacente, c'est est-ce qu'une chaine vide ne va pas
> faire dérailler salvatore et cie ?
> ___
> 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] Écriture inclusive (!)

2020-12-03 Par sujet Cerdic
Les outils de la communauté ne sont pas là pour répondre à des demandes de 
clients ou clientes,
mais pour servir à la communauté avec ses valeurs, son histoire et sa pluralité.

Les gens ont toujours de bonne raison de ne pas vouloir changer leurs 
habitudes, être dérangés dans leur confort de caste etc. Mais c’est les faire 
grandir que des de les confronter à une réalité qui n’est pas la leur.

Et si ils veulent pas grandir franchement on s’en fout.
On a pas a faire supporter à la communauté un effort collectif pour produire 
quelque chose qui va a l’encontre de ses valeurs.

Même si le marché s’est intéressé à SPIP a un moment, SPIP en tant qu’outil - 
et en tant que communauté - a toujours été en dehors du marché et son 
développement n’a jamais été dicté par les besoins du marché.

Ce sont les valeurs et les convictions politiques de ses contributeurs qui 
guident SPIP et renoncer à cela se serait perdre ce qui en fait l’essence.

--
Cédric
Le 3 déc. 2020 à 21:08 +0100, Ybbet SPIP , a écrit :
> Bonsoir à tous,
>
> Merci pour ce thread.
> J’ai une question, est-il possible (pour ceux.elles qui le désirent) de 
> soumettre sur https://trad.spip.net/ la langue « fr_academie » ? Au même 
> titre qu’a été publié en son temps « fr_fem ».
> J’ai des client.e.s qui n’aiment pas cette écriture inclusive. Ils et elles 
> ont leurs propres raisons. Cela ne me regarde pas particulièrement. Je 
> cherche juste une solution pour répondre à leur demande.
>
> Amicalement,
> Ybbet.
>
> > Le 3 déc. 2020 à 20:19, RastaPopoulos  a écrit :
> >
> >
> > Purée mais cym, yannx, pascal, joel (oui tous dans le même panier), juste… 
> > soit barrez vous soit taisez vous si le projet politique qu'il y a 
> > *toujours* eu derrière SPIP ne vous convient pas :
> > - soit vous utilisez le logiciel parce que techniquement ça vous est utile 
> > (comme un site du FN peut utiliser SPIP s'il veut, voyez moi aussi je peux 
> > faire du Godwin),
> > - soit vous allez voir ailleurs, mais sans troller votre dominance sur le 
> > projet politique un tant soit peu émancipateur qu'il y a toujours eu 
> > derrière (si tant est qu'on puisse très très légèrement améliorer les 
> > choses, mais on fait sur quoi on a la main dessus, en l'occurrence là dans 
> > SPIP et nos plugins)
> >
> > Certains sujets sont à débattre, d'autres sont au fondement même de la 
> > charte de la communauté et non, on ne débattra pas là-dessus à priori et il 
> > n'y a pas à comprendre la position adverse : on la connait plutôt bien, et 
> > devinez quoi : on n'est pas d'accord *politiquement* avec ! Et donc ya 
> > aucun consensus à chercher là dessus. SPIP ce n'est pas "que de l'amour", 
> > c'est de la tendresse entre gens qui acceptent la charte commune et qui 
> > portent des valeurs similaires. SPIP c'est pas Jésus, et non ya pas 
> > forcément d'amour pour tout le monde (et encore même Jésus il peut mettre 
> > dehors les marchands du temple).
> >
> > Que par contre on débatte sur *les modalités* de l'écriture inclusive, ça 
> > oui, sur la manière manière de le faire, la plus lisible tout en étant la 
> > moins lourde, c'est légitime. Et on l'a déjà fait et on continuera sûrement 
> > (l'état du débat étant = équilibre à trouver à chaque contexte et non pas 
> > en règle unique, au maximum des mots épicènes, puis du doublonnage avec 
> > deux termes, et en dernier recours des points médians lorsque c'est un 
> > contexte qui doit vraiment rester court sans possibilité de doublonner 
> > masculin et féminin).
> >
> > Mais tout ce thread n'a aucun rapport avec ça ! Et donc ce n'est pas ici 
> > dans ce thread qu'on débattra de ces modalités, vu que ce ne sont que des 
> > invectives réacs et anti-féministes.
> >
> > --
> > RastaPopoulos
> >
> > ___
> > liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> > doc: https://www.spip.net/
> > dev: https://core.spip.net/
> > irc://irc.freenode.net/spip
>
> ___
> 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] [HS] Re: Écriture inclusive (!)

2020-12-03 Par sujet Cerdic
Hello,

Désolé Joël mais tu es hors sujet complet en effet : depuis sa création SPIP 
est un outil politique.

Que les utilisateurs s’en soient emparés pour en faire autre chose est presque 
un malentendu.
Donc que ça te plaise ou non l’outil continuera de porter les valeurs défendues 
par sa communauté, d’une façon ou d’une autre.

La bonne nouvelle est que l’outil est hautement personnalisable, tu pourras 
donc en faire l’usage que tu veux selon tes propres valeurs.
Ou changer d’outil si tu préfères.

--
Cédric
Le 3 déc. 2020 à 14:53 +0100, BERTRAND Joël , a 
écrit :
> Maïeul Rouquette a écrit :
> > Le 03/12/2020 à 14:23, BERTRAND Joël a écrit :
> > > Bonjour à tous,
> > >
> > > Franchement, je ne veux pas être vieux jeu, mais l'écriture inclusive
> > > dans les pages privées (par exemple la configuration du plugin
> > > Formidable), ça pique les yeux ! Je ne suis pas sûr que ce soit
> > > réellement une nécessité absolue.
> > >
> > > Exemple :
> > > "seul·es les auteur·trices d’un formulaire"
> > > "seul·es les administrateurs et administratrices"
> > >
> > > Là, camarades, il faut choisir son camp. Soit on a le culot d'écrire
> > > "seul.e.s les administrateur.rice.s", soit on écrit le Français
> > > correctement en considérant que le masculin pluriel est le neutre du
> > > Français (ce qui est est grammaticalement le cas).
> > >
> > > JB
> > > ___
> > > liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> > > doc: https://www.spip.net/
> > > dev: https://core.spip.net/
> > > irc://irc.freenode.net/spip
> > >
> > Je t'invite à lire les ouvrages d'Eliane Viennot sur le fait que non, le
> > masculin pluriel n'est pas le neutre du français.
>
> Dans ce cas, la grammaire à changé. Et ce n'est pas non plus ce
> qu'indique l'Académie Française
> (https://www.dictionnaire-academie.fr/article/A9N0368). Il y a par
> ailleurs une littérature complète sur ce point, à commencer par celle de
> Moignet.
>
> Trêve de plaisanterie, merci de ne pas imposer cette saleté. Le but
> d'un outil comme Spip n'est pas de faire du militantisme mal placé. Ou
> si vous voulez absolument mettre cette horreur dans les pages, prévoyez
> un bouton quelque part avec une option "je veux avoir les yeux qui
> saignent" ou "je veux mon site en Français". Ou créez une localisation
> "français inclusif" et foutez la paix à ceux qui veulent encore écrire
> un Français tout juste correct.
>
> En Français, que tu le veuilles ou non, le masculin pluriel est non
> genré comme en Allemand, le féminin pluriel est non genré. C'est comme
> ça, et prétendre que massacrer la grammaire française va résoudre des
> problèmes de société est inepte.
>
> C'était mon coup de gueule, le genre de coup de gueule qui peut me
> faire abandonner un outil parce que la politique n'a rien à voir là-dedans.
>
> Je n'y reviendrai pas.
>
> JB
> ___
> 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] [Spip-zone-commit] [badge_don] 2 commits

2020-11-27 Par sujet Cerdic
Clairement c’est de la syntaxe qui va mourir et qu’il faut considérer comme 
dépréciée...

--
Cédric
Le 26 nov. 2020 à 20:59 +0100, RealET , a écrit :
> Bruno Bergot a écrit le 26/11/2020 à 19:29 :
> > Hop,
> >
> > Merci pour l'ajout, par contre il y une faut dans l'item de langue, cf :
> >
> > exemple pour affichage dans une MediaBox  : mediabox boxWidth-960px
> > boxHeight-90pc)
> >
> > px pas pc, mais ahma il ne faut pas coller cette mention, car elle sera
> > dépassée si mediabox change de syntaxe, et les gens n'utiliseront pas
> > forcément cette classe pour ça.
> Ok pour simplifier la chaîne de langue.
>
> Par contre, c'est bien pc pour pourcentage.
> cf https://contrib.spip.net/MediaBox#Utilisation-simple qui indique :
> Remarquez que la classe est donc constituée de la valeur souhaitée.
> Cette valeur s’exprime dans les unités CSS valides (px, em, pt ...). Cas
> particulier, les ’%’ sont notés pc (le caractère ’%’ n’étant pas
> autorisé pour les noms de classe).
>
> Ceci dit, ayant un peu cherché pour la syntaxe de mediabox, je trouvais
> intéressant de fournir ça dans l'explication.
>
> Mais ça peut être fait dans la doc (qu'il faudrait que je puisse mettre
> à jour d'ailleurs)
>
>
>
> --
> RealET
>
>
> ___
> 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] Classe spécifique pour la Splash Boîte de Médiabox

2020-11-24 Par sujet Cerdic
Ah bonne remarque :

• la splashbox devrait donc avoir une class en plus systematiquement, pour 
pouvoir la distinguer
• il faut vérifier que l’on peut effectivement passer ça en option de la 
mediabox refondue
• et il faut que je termine ce chantier :p


--
Cédric
Le 23 nov. 2020 à 17:50 +0100, Bruno Bergot , a écrit :
> Hop,
>
> Le 19/11/2020 à 11:22, jeanmarie a écrit :
> > Salut,
> >
> > est-ce qu'il y a une solution pour avoir une classe spécifique pour la
> > splash boite de Médiabox qui s'affiche sur n'importe quelle page à la
> > 1ère visite ?
> >
> > De ce que je vois, on a id="colorbox" et class="box_mediabox
> > box_modalbox" dans tous les cas, que ça soit la splash boite ou une
> > boite modale "normale" (par ex portfolio).
> >
>
> Oui, c'est un manque qui pourrait être comblé par le patch suivant dans
> javascript/splash.mediabox.js :
>
> @@ -12,13 +12,15 @@
> overlayClose:true,
> iframe: true,
> width: box_settings_splash_width,
> - height: box_settings_splash_height
> + height: box_settings_splash_height,
> + className: 'splashbox'
> },options));
> } else {
> $.fn.mediabox($.extend({
> href:href,
> onComplete:set_cookie,
> - overlayClose:true
> + overlayClose:true,
> + className: 'splashbox'
> },options));
> }
> };
>
>
> Par contre, je ne suis pas certain que ça soit le bon moment de
> l'intégrer puisque mediabox est en cours de refonte dans la 3.3 cf le
> travail de Cedric à ce sujet.
>
> ++
> b_b
> ___
> 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] [html5up_editorial] 2 commits

2020-11-16 Par sujet Cerdic
C’est donc un bug de scssphp mais qui en fait était déjà là avant et produisait 
un selecteur css invalide, et qui maintenant, se controlant lui même, nous 
jette à la face sa propre erreur :p

https://github.com/scssphp/scssphp/issues/273

--
Cédric
Le 16 nov. 2020 à 14:52 +0100, Matthieu Marcillaud , a écrit 
:
> Le 16/11/2020 à 13:32, chanka...@choc0.net
> a écrit :
> > salut,
> > l'erreur telle quelle :
> >
> > SCSS : Echec compilation fichier
> > plugins/squelettes/html5up_editorial/css/main.scss
> > `$\28xlarge\29` is not a valid Selector in `.\39u\28xlarge\29,
> > .\39u$\28xlarge\29`: failed at `$\28xlarge\29`
> > ScssPhp\ScssPhp\Compiler::evalSelectors on line 1, at column 24
> >
> > issue des mixins qui ne font plus leur boulot dans le fichier
> > css/libs/_skel.scss l257 de le v1.2.3
> > ... il me semble...
>
> Passer sur irc avant, ou poser la question sur .devel, aurait pu aider
> je pense.
>
> Cette nouvelle version de la lib est plus proche de la spec de Sass sur
> les opérateurs de calculs, qui nécessitent un espace de part et d’autre
> de l’opérateur. Je suppose que le problème est là ? Ou pas
>
> Et s’il n’est pas là, tu aurais pu en parler avant de virer tous tes
> fichiers :)
>
> Dans le cas présent, si tu pointes
> https://git.spip.net/spip-contrib-squelettes/html5up_editorial/src/commit/c9443814608606e66be868230790564040d1d278/css/libs/_skel.scss#L257
> et les lignes suivantes, il y a de quoi peut être être sur des cas
> limites pour le parseur...
>
> $x est définit à par exemple `\28xlarge\29`
> Et utilisé comme sélecteur après : `.\31 2u#{$x}`
>
> - Possiblement les \ ne sont plus autorisés dans les sélecteurs ?
> - Possiblement un sélecteur ne peut commencer par un chiffre ?
> - Possiblement un bug laisse ce `$` trainer ? mais pourquoi sur le 39 et
> pas les autres ?...
>
> Je n’ai pas la réponse là, mais c’est peut être des choses comme ça à
> regarder...
>
> MM.
>
> ___
> 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] [Spip-zone-commit] [html5up_editorial] 2 commits

2020-11-16 Par sujet Cerdic
Hello,

Soit c’est un problème de mixins qui est pas propre et passait par chance dans 
une ancienne version de scssphp et alors il faudrait corriger le scss, soit 
c’est un bug de scssphp et alors il faudrait le signaler pour corriger scssphp.

Parce que planquer le bug sous le tapis en virant le scss au profit d’une css 
c’est pas super cool et le bug va péter dans la tronche de quelqu’un d'autre, 
non ?

Tu as pu compiler le scss avec un autre outil ?

Pour le détail, la version 1.3.0 de la lib scssphp a introduit la revalidation 
des selecteurs calculés lors de la compilation. Ie, après compilation on 
vérifie que le selecteur généré est css-valide.

Il y a eu un bug sur cette fonction, remonté après publication de la version 
1.3.0 mais il était lié aux espaces en debut de selecteur et a été corrigé
https://github.com/scssphp/scssphp/issues/245

Cela dit ici j’ai reussi a reproduire le bug avec un cas test simple, et il 
compile normalement avec SassMeister, c’est donc bien un bug dans ScssPHP.
https://github.com/scssphp/scssphp/issues/273


Mais le principe de l’open-source c’est que si personne ne signale un bug, 
personne ne le corrigera...

--
Cédric
Le 16 nov. 2020 à 13:32 +0100, chanka...@choc0.net , a 
écrit :
> salut,
> l'erreur telle quelle :
>
> SCSS : Echec compilation fichier 
> plugins/squelettes/html5up_editorial/css/main.scss
> `$\28xlarge\29` is not a valid Selector in `.\39u\28xlarge\29, 
> .\39u$\28xlarge\29`: failed at `$\28xlarge\29` 
> ScssPhp\ScssPhp\Compiler::evalSelectors on line 1, at column 24
>
> issue des mixins qui ne font plus leur boulot dans le fichier 
> css/libs/_skel.scss l257 de le v1.2.3
> ... il me semble...
>
>
> Le 16/11/2020 à 12:11, Cerdic a écrit :
> > Hello Chankalan,
> >
> > peux-tu dire te quoi tu parles concernant les « erreurs scss » ?
> > Quelles erreurs rencontre-tu ?
> >
> >
> > --
> > Cédric
> > Le 16 nov. 2020 à 10:27 +0100, chankalan , a 
> > écrit :
> > > spip-contrib-squelettes/html5up_editorial | 2 commits
> > > -
> > > Par chankalan, le 16 novembre 2020 à 10h12min :
> > >
> > > éviter les erreurs scss (avec scssphp v2.7.0)
> > > en passant par du css (mais en gardant le scss pour les surcharges)
> > >
> > >
> > > *Ajouté*
> > > css/fontawesome-all.min.css
> > > css/main.css
> > > webfonts/fa-brands-400.eot
> > > webfonts/fa-brands-400.svg
> > > webfonts/fa-brands-400.ttf
> > > webfonts/fa-brands-400.woff
> > > webfonts/fa-brands-400.woff2
> > > webfonts/fa-regular-400.eot
> > > webfonts/fa-regular-400.svg
> > > webfonts/fa-regular-400.ttf
> > > webfonts/fa-regular-400.woff
> > > webfonts/fa-regular-400.woff2
> > > webfonts/fa-solid-900.eot
> > > webfonts/fa-solid-900.svg
> > > webfonts/fa-solid-900.ttf
> > > webfonts/fa-solid-900.woff
> > > webfonts/fa-solid-900.woff2
> > > *Supprimé*
> > > css/_font.scss
> > > css/base/_page.scss
> > > css/base/_typography.scss
> > > css/components/_box.scss
> > > css/components/_button.scss
> > > css/components/_features.scss
> > > css/components/_fonts.scss
> > > css/components/_form.scss
> > > css/components/_icon.scss
> > > css/components/_image.scss
> > > css/components/_list.scss
> > > css/components/_mini-posts.scss
> > > css/components/_posts.scss
> > > css/components/_section.scss
> > > css/components/_table.scss
> > > css/fontawesome/font-awesome.min.css
> > > css/fonts/FontAwesome.otf
> > > css/fonts/fontawesome-webfont.eot
> > > css/fonts/fontawesome-webfont.svg
> > > css/fonts/fontawesome-webfont.ttf
> > > css/fonts/fontawesome-webfont.woff
> > > css/fonts/fontawesome-webfont.woff2
> > > css/fonts/opensans-italic-webfont.woff
> > > css/fonts/opensans-italic-webfont.woff2
> > > css/fonts/opensans-regular-webfont.woff
> > > css/fonts/opensans-regular-webfont.woff2
> > > css/fonts/opensans-semibold-webfont.woff
> > > css/fonts/opensans-semibold-webfont.woff2
> > > css/fonts/opensans-semibolditalic-webfont.woff
> > > css/fonts/opensans-semibolditalic-webfont.woff2
> > > css/fonts/robotoslab-bold-webfont.woff
> > > css/fonts/robotoslab-bold-webfont.woff2
> > > css/fonts/robotoslab-regular-webfont.woff
> > > css/fonts/robotoslab-regular-webfont.woff2
> > > css/layout/_banner.scss
> > > css/layout/_footer.scss
> > > css/layout/_header.scss
> > > css/layout/_main.scss
> > > css/layout/_menu.scss
> > > css/layo

Re: [spip-dev] [Spip-zone-commit] [html5up_editorial] 2 commits

2020-11-16 Par sujet Cerdic
Hello Chankalan,

peux-tu dire te quoi tu parles concernant les « erreurs scss » ?
Quelles erreurs rencontre-tu ?


--
Cédric
Le 16 nov. 2020 à 10:27 +0100, chankalan , a écrit :
> spip-contrib-squelettes/html5up_editorial | 2 commits
> -
> Par chankalan, le 16 novembre 2020 à 10h12min :
>
> éviter les erreurs scss (avec scssphp v2.7.0)
> en passant par du css (mais en gardant le scss pour les surcharges)
>
>
> *Ajouté*
> css/fontawesome-all.min.css
> css/main.css
> webfonts/fa-brands-400.eot
> webfonts/fa-brands-400.svg
> webfonts/fa-brands-400.ttf
> webfonts/fa-brands-400.woff
> webfonts/fa-brands-400.woff2
> webfonts/fa-regular-400.eot
> webfonts/fa-regular-400.svg
> webfonts/fa-regular-400.ttf
> webfonts/fa-regular-400.woff
> webfonts/fa-regular-400.woff2
> webfonts/fa-solid-900.eot
> webfonts/fa-solid-900.svg
> webfonts/fa-solid-900.ttf
> webfonts/fa-solid-900.woff
> webfonts/fa-solid-900.woff2
> *Supprimé*
> css/_font.scss
> css/base/_page.scss
> css/base/_typography.scss
> css/components/_box.scss
> css/components/_button.scss
> css/components/_features.scss
> css/components/_fonts.scss
> css/components/_form.scss
> css/components/_icon.scss
> css/components/_image.scss
> css/components/_list.scss
> css/components/_mini-posts.scss
> css/components/_posts.scss
> css/components/_section.scss
> css/components/_table.scss
> css/fontawesome/font-awesome.min.css
> css/fonts/FontAwesome.otf
> css/fonts/fontawesome-webfont.eot
> css/fonts/fontawesome-webfont.svg
> css/fonts/fontawesome-webfont.ttf
> css/fonts/fontawesome-webfont.woff
> css/fonts/fontawesome-webfont.woff2
> css/fonts/opensans-italic-webfont.woff
> css/fonts/opensans-italic-webfont.woff2
> css/fonts/opensans-regular-webfont.woff
> css/fonts/opensans-regular-webfont.woff2
> css/fonts/opensans-semibold-webfont.woff
> css/fonts/opensans-semibold-webfont.woff2
> css/fonts/opensans-semibolditalic-webfont.woff
> css/fonts/opensans-semibolditalic-webfont.woff2
> css/fonts/robotoslab-bold-webfont.woff
> css/fonts/robotoslab-bold-webfont.woff2
> css/fonts/robotoslab-regular-webfont.woff
> css/fonts/robotoslab-regular-webfont.woff2
> css/layout/_banner.scss
> css/layout/_footer.scss
> css/layout/_header.scss
> css/layout/_main.scss
> css/layout/_menu.scss
> css/layout/_sidebar.scss
> css/layout/_wrapper.scss
> css/main.scss
> css/theme.scss
> *Modifié*
> css/libs/_skel.scss
> css/spip.scss
> inclure/head.html
>
> Détails : 
> https://git.spip.net/spip-contrib-squelettes/html5up_editorial/commit/7167ea9f7e993fc7e9169f30e45f5914a023de6a
>
> ==
> Par chankalan, le 16 novembre 2020 à 10h25min :
>
> v1.3.0 toujours en test
>
>
> *Modifié*
> paquet.xml
>
> Détails : 
> https://git.spip.net/spip-contrib-squelettes/html5up_editorial/commit/184bad2c7894bd2d24d1ee4dbdb7746dd93dca12
>
> ___
> spip-zone-com...@rezo.net - 
> https://listes.rezo.net/mailman/listinfo/spip-zone-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] Reposter sur twitter facebook et Instagram ?

2020-11-11 Par sujet Cerdic
On fait pas ou on fait plus.

Tw*tter comme faceb**k (et donc instagr*m) ferment de plus en plus leurs apis, 
les seuls moyens d’encore arriver à interragir c’est d’ouvrir un compte 
développeur, d’enregistrer une app, de renseigner des tokens, ce qui est un 
parcours du combatant pour un résultat de moins en moins probant.

Bref, pour tw*tter j’ai arrêté le combat, ça ne marche pas ou plus (enfin je 
pense que certains sites continuent de marcher quand ils avaient bien été 
paramétrés et que par chance le compte developpeur ou l’app n’a pas été 
suspendu ou que sais-je, mais c’est quasi impossible de paramétrer le plugin 
sur un nouveau site).

Pour fb et inst. la dernière fois que j’ai voulu regarder je suis resté bloqué 
à l’étape de devoir filer mon numéro de portable pour éspérer ouvrir un compte 
développeur. Et j’ai dit fuck.

--
Cédric
Le 11 nov. 2020 à 10:16 +0100, JLuc , a écrit :
> Hello
>
> J'aimerais diffuser certains contenus éditoriaux, ou leur annonce, sur 
> twitter, facebook et instagram notamment.
> Certains sites comme iftt permettent pas mal de choses à partir d'un flux RSS,
> mais ils utilisent des raccourcisseurs non maîtrisés, le paramétrage semble 
> limité
> et le rendu n'est pas toujours satisfaisant. À moins que vous ne connaissiez 
> une super ressource ?
>
> Visiblement il y a des API pour facebook et instagramm qui semblent permettre 
> cela :
> - API "New Page Experience" : https://developers.facebook.com/docs/pages
> - Flux rss des Instant Articles : 
> https://developers.facebook.com/docs/instant-articles/publishing/setup-rss-feed
> - API des Instant Articles : 
> https://developers.facebook.com/docs/instant-articles/api
> - instagram : https://developers.facebook.com/docs/instagram + 
> https://developers.facebook.com/docs/instagram-api
>
> J'ai cherché dans la proche galaxie spip et trouvé le plugin twitter 
> https://contrib.spip.net/4393
> Il est bien prévu pour poster sur twitter,
> mais les derniers commentaires indiquent que ce plugin ne marche plus,
> probablement en raison d'une modification de l'API.
> Des personnes parviennent elles quand même à s'en servir actuellement ?
>
> Il y a aussi un plugin facebook d'il y a 10 ans mais il doit être périmé vu 
> que les API changent régulièrement.
>
> Et vous comment faites-vous pour ces fonctionnalités ?
>
> JLuc
>
> ___
> 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] Refonte Mediabox [wip]

2020-11-06 Par sujet Cerdic
Hello,

j’ai donc poussé tout le chantier dans une PR 
https://git.spip.net/spip/mediabox/pulls/1
La branche est en test sur contrib, toujours, et inclus maintenant 
l’utilisation de lity dans ecrire/

--
Cédric
Le 13 oct. 2020 à 11:59 +0200, pierre laszczak , a 
écrit :
> Au niveau du focus sur un champ du  formulaire à l'ouverture  de la modal 
> c'est très perturbant pour le commun des mortels en navigation mobile:
> Entre le scroll sur le premier champ  et le clavier virtuel qui s'affiche sur 
> la moitié de l'écran on a vraiment du mal à comprendre ce qui se passe à 
> l'écran.
>
> > Le mar. 13 oct. 2020 à 11:12, RealET  a écrit :
> > > Matthieu Marcillaud a écrit le 13/10/2020 à 11:02 :
> > > > Y a un focus automatique du lien sur la croix de fermeture ? C’est assez
> > > > bizarre (disgracieux) à la souris / trackpad du coup ce focus visible
> > > > sur la croix à l’ouverture de la modale. C’est voulu ?
> > > J'en profite pour faire remonter qu'on peut avoir besoin que ce soit un
> > > élément de formulaire dans la modale qui ait le focus à l'ouverture (ex
> > > pour une modale qui affiche juste un champ formulaire de recherche ou
> > > abonnement à une newsletter).
> > > Une discussion à ce sujet chez nicofr :
> > > https://github.com/nicofr/jquery-accessible-modal-window-aria/issues/20
> > >
> > > Discussion qui a donné lieu à son intégration.
> > >
> > > --
> > > RealET
> > >
> > >
> > > ___
> > > 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
___
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] [Pousseur] Erreur sur soyezcreateurs

2020-11-04 Par sujet Cerdic
Peut-être parce que
https://git.spip.net/spip-contrib-outils/archivelists/src/branch/master/traductions.txt#L1317

?
Y a pas de magie en ce bas monde, si personne fait rien, rien ne se passe...

--
Cédric
Le 4 nov. 2020 à 09:59 +0100, RealET , a écrit :
> salvat...@rezo.net a écrit le 04/11/2020 à 09:55 :
> > *Traduire SPIP*
> >
> > Erreur lors du commit :
> > > svn commit ’soyezcreateurs_en.php’ ’soyezcreateurs.xml’
> > —username=’x’ —password=’x’ —no-auth-cache —non-interactive
> > —trust-server-cert -m ’[Salvatore] [source : soyezcreateurs] Export
> > depuis https://trad.spip.net  de la langue en
> > [Salvatore] [source : soyezcreateurs] Mise a jour du bilan depuis
> > https://trad.spip.net 
> > Credits : RealET 
> > ’ 2>&1
> > svn : E210002 : Échec de la propagation (commit), détails :
> > svn : E210002 : La connexion réseau a été fermée de façon inattendue
> >
> >
> >
> >
> >
> > — Envoyé par Traduire SPIP 
> >
> >
> >
> Bizarre que ça parle de SVN alors qu'il est bien passé sur
> https://git.spip.net/spip-contrib-squelettes/soyezcreateurs
>
>
> --
> RealET
>
>
> ___
> 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] Refonte Mediabox [wip]

2020-10-13 Par sujet Cerdic
J’ai fait du fignolage esthétique, des transitions slide left/right sur les 
précedent/suivant et ajouté un preloader sur le next dans les albums.
Ça commence à être pas mal du tout amha

--
Cédric
Le 10 oct. 2020 à 09:59 +0200, Eric Lupinacci , a écrit :
> Oui je trouve ça nickel là.
>
> > Le sam. 10 oct. 2020 à 05:36, nicod_  a écrit :
> > > Le 09/10/2020 à 23:19, Cerdic a écrit :
> > > > C’est corrigé et je viens d’ajouter une fonction diaporama.
> > >
> > > Top avec toutes ces modifs.
> > >
> > > Comment ça marche ta fonction diaporama ? Je ne vois pas ça sur la démo.
> > > Niveau accessibilité, on n'est pas censés déclencher une animation
> > > automatiquement, et au pire il doit y avoir un bouton pour l'arrêter.
> > >
> > > > Je crois qu’avec ça on a toutes les features. Il reste à gérer les
> > > > quelques configs et on aura une bonne base
> > > > (il y aura surement aussi une passe à faire d’affinage des styles en
> > > > petit écran)
> > >
> > > Je vais tester ça sur crossbrowsertesting asap.
> > >
> > > --
> > > nicod_
> > > ___
> > > 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] [Spip-zone-commit] [mailsubscribers] 4 commits sur issue_2_sync

2020-10-11 Par sujet Cerdic
oui mais non ça va pas :

• une fonction genie reçoit $t en premier argument, c’est conventionnel on et 
on ne peut pas changer ça
• l’action ne va plus fonctionner dans les cas où elles était appelée avant, 
sans argument (et sans verification de cle car j’avais jugé que c’était 
superflu de la securiser


--
Cédric
Le 11 oct. 2020 à 13:29 +0200, jluc , a écrit :
> spip-contrib-extensions/mailsubscribers | 4 commits
> -
> Par jluc, le 9 octobre 2020 à 19h43min :
>
> Bouton synchroniser pour chaque page de liste - fixes #2
>
>
> *Modifié*
> prive/objets/infos/mailsubscribinglist.html
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/mailsubscribers/commit/32c9dd0239d4c3718c3b3bc6330287841c5ac5c4
>
> ==
> Par jluc, le 10 octobre 2020 à 19h16min :
>
> le genie de synchro doit prendre en compte son argument - WIP : le flux du 
> php boucle mystérieusement et s'arrête au milieu du traitement
>
>
> *Modifié*
> action/mailsubscribers_synchro_lists.php
> genie/mailsubscribers_synchro_lists.php
> inc/mailsubscribers.php
> prive/objets/infos/mailsubscribinglist.html
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/mailsubscribers/commit/52ec31fbb4c134a4d682beaa58149f88da57aa07
>
> ==
> Par jluc, le 11 octobre 2020 à 12h38min :
>
> debuging en cours
>
>
> *Modifié*
> action/mailsubscribers_synchro_lists.php
> genie/mailsubscribers_synchro_lists.php
> inc/mailsubscribers.php
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/mailsubscribers/commit/836037e8642ab4dac1663ee5dd127741cc0f1197
>
> ==
> Par jluc, le 11 octobre 2020 à 13h27min :
>
> passer l'identifiant donc puisqu'il existe + laminer les lame logs
>
>
> *Modifié*
> action/mailsubscribers_synchro_lists.php
> genie/mailsubscribers_synchro_lists.php
> inc/mailsubscribers.php
> prive/objets/infos/mailsubscribinglist.html
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/mailsubscribers/commit/5b90971ee1864c4132782a8fe87ed72a8a18371c
>
> ___
> spip-zone-com...@rezo.net - 
> https://listes.rezo.net/mailman/listinfo/spip-zone-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] Refonte Mediabox [wip]

2020-10-10 Par sujet Cerdic
essaye avec un ?var_mode=calcul peut-être ?

Evidemment aucune animation ne démarre automatiquement, et c’est un bouton qui 
permet de démarrer et d’arrêter le diaporama !

--
Cédric
Le 10 oct. 2020 à 05:36 +0200, nicod_ , a écrit :
> Le 09/10/2020 à 23:19, Cerdic a écrit :
> > C’est corrigé et je viens d’ajouter une fonction diaporama.
>
> Top avec toutes ces modifs.
>
> Comment ça marche ta fonction diaporama ? Je ne vois pas ça sur la démo.
> Niveau accessibilité, on n'est pas censés déclencher une animation
> automatiquement, et au pire il doit y avoir un bouton pour l'arrêter.
>
> > Je crois qu’avec ça on a toutes les features. Il reste à gérer les
> > quelques configs et on aura une bonne base
> > (il y aura surement aussi une passe à faire d’affinage des styles en
> > petit écran)
>
> Je vais tester ça sur crossbrowsertesting asap.
>
> --
> nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2020-10-09 Par sujet Cerdic
C’est corrigé et je viens d’ajouter une fonction diaporama.

Je crois qu’avec ça on a toutes les features. Il reste à gérer les quelques 
configs et on aura une bonne base
(il y aura surement aussi une passe à faire d’affinage des styles en petit 
écran)

--
Cédric
Le 9 oct. 2020 à 17:24 +0200, Cerdic , a écrit :
> Oui et non : les boutons suivant/précédent sont actuellement presque sur 
> toute la hauteur de l’écran, donc si tu as un petit écran, ou que l’image est 
> très grande il reste presque pas de zone « en dehors de l’image et en dehors 
> des boutons »
> Peut-être il faut des boutons un peu plus petit en hauteur en limitant par 
> exemple à 25% de la hauteur de l’écran ?
>
> --
> Cédric
> Le 9 oct. 2020 à 17:08 +0200, Eric Lupinacci , a écrit :
> > Hello,
> >
> > Un petit truc.
> > Quand on est sur une image le fait de cliquer en dehors de l'image ferme la 
> > popup. Ok.
> > Quand on est dans une galerie le fait de cliquer en dehors de l'image est 
> > équivalent aux boutons suivant et précédent.
> > C'est voulu ? normal ? Parce que je trouve ça déroutant la première fois 
> > par rapport au comportement des images.
> >
> >
> >
> >
> >
> > > Le ven. 9 oct. 2020 à 16:59, Cerdic  a écrit :
> > > > Hello,
> > > >
> > > > merci pour vos retours.
> > > >
> > > > Les points suivants sont donc corrigés :
> > > > - le signalement du focus des boutons close/prev/next est forcé dans la 
> > > > css de la box, et non hérité par défaut du site
> > > > - les boutons prev/next sont en position fixed dans l’écran et ne 
> > > > bougent donc plus. Ils sont par ailleurs visible immédiatement et plus 
> > > > seulement au survol
> > > > - il y a un background sur les images
> > > > - on peut fermer la box pendant son chargement si c’est trop long
> > > >
> > > > --
> > > > Cédric
> > > > Le 9 oct. 2020 à 15:11 +0200, pierre laszczak 
> > > > , a écrit :
> > > > > Hello,
> > > > >
> > > > > Super! je viens de tester à l'instant sur contrib et je suis du même 
> > > > > avis que tcharlss
> > > > >
> > > > > > Une petite suggestion d'UX : pour les galeries, est-ce que c'est 
> > > > > > possible de mettre les flèches de navigation en position fixe sur 
> > > > > > les côté (et ce de base, sans avoir à bidouiller les styles) ?
> > > > > > Là elles sont collées par-dessus l'image, ce qui fait qu'avec des 
> > > > > > images de tailles différentes elles changent constamment de place, 
> > > > > > ce qui rend la navigation à la souris moins facile.
> > > > >
> > > > > Il y a un autre soucis sur les connexions lentes, je pense notamment 
> > > > > au diaporama:
> > > > > -> Une fois qu'une action js est lancée on ne peut pas l'annuler en 
> > > > > cliquant sur close ou hors de la fancybox! on est obligé d'attendre 
> > > > > que la requête ajax soit terminée.
> > > > >
> > > > > > Le ven. 9 oct. 2020 à 00:48, nicod_  a écrit :
> > > > > > > Le 07/10/2020 à 23:59, nicod_ a écrit :
> > > > > > > > Il faudrait pouvoir la faire tester par un·e expert·e 
> > > > > > > > accessibilité.
> > > > > > > >
> > > > > > > > Peut être Roman, s'il nous lit ici ?
> > > > > > >
> > > > > > > Un premier retour de notabene :
> > > > > > >
> > > > > > > > Au clavier c'est tout bon (sauf le bouton "fermer" qui n'a pas 
> > > > > > > > d'outline perceptible). On cycle dans la popin sans en sortir, 
> > > > > > > > pas de perte de focus, etc. Quand on ferme la popin ça remet le 
> > > > > > > > focus sur le lien ouvrant. Tout bon.
> > > > > > > >
> > > > > > > > Les flèches ne sont affichées qu'au survol, ça n'aide pas  
> > > > > > > > l'utilisateur pour voir que la popin est un carrousel (il peut 
> > > > > > > > pas deviner tout seul gauche/droite).
> > > > > > > >
> > > > > > > > J'essaie de tester bientôt avec mon lecteur d'écran. Mais déjà 
> > > > > > > > c'est bien cool.
> > > > > > >
> > > > > > > https://toot.cafe/@accessiblestef/105000951846500269
> > > > > > >
> > > > > > > Ça sent bon tout ça, en plus elle est vachement plus light et 
> > > > > > > jolie
> > > > > > > cette box :)
> > > > > > >
> > > > > > > --
> > > > > > > nicod_
> > > > > > > ___
> > > > > > > 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
> ___
> 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] Refonte Mediabox [wip]

2020-10-09 Par sujet Cerdic
Oui et non : les boutons suivant/précédent sont actuellement presque sur toute 
la hauteur de l’écran, donc si tu as un petit écran, ou que l’image est très 
grande il reste presque pas de zone « en dehors de l’image et en dehors des 
boutons »
Peut-être il faut des boutons un peu plus petit en hauteur en limitant par 
exemple à 25% de la hauteur de l’écran ?

--
Cédric
Le 9 oct. 2020 à 17:08 +0200, Eric Lupinacci , a écrit :
> Hello,
>
> Un petit truc.
> Quand on est sur une image le fait de cliquer en dehors de l'image ferme la 
> popup. Ok.
> Quand on est dans une galerie le fait de cliquer en dehors de l'image est 
> équivalent aux boutons suivant et précédent.
> C'est voulu ? normal ? Parce que je trouve ça déroutant la première fois par 
> rapport au comportement des images.
>
>
>
>
>
> > Le ven. 9 oct. 2020 à 16:59, Cerdic  a écrit :
> > > Hello,
> > >
> > > merci pour vos retours.
> > >
> > > Les points suivants sont donc corrigés :
> > > - le signalement du focus des boutons close/prev/next est forcé dans la 
> > > css de la box, et non hérité par défaut du site
> > > - les boutons prev/next sont en position fixed dans l’écran et ne bougent 
> > > donc plus. Ils sont par ailleurs visible immédiatement et plus seulement 
> > > au survol
> > > - il y a un background sur les images
> > > - on peut fermer la box pendant son chargement si c’est trop long
> > >
> > > --
> > > Cédric
> > > Le 9 oct. 2020 à 15:11 +0200, pierre laszczak 
> > > , a écrit :
> > > > Hello,
> > > >
> > > > Super! je viens de tester à l'instant sur contrib et je suis du même 
> > > > avis que tcharlss
> > > >
> > > > > Une petite suggestion d'UX : pour les galeries, est-ce que c'est 
> > > > > possible de mettre les flèches de navigation en position fixe sur les 
> > > > > côté (et ce de base, sans avoir à bidouiller les styles) ?
> > > > > Là elles sont collées par-dessus l'image, ce qui fait qu'avec des 
> > > > > images de tailles différentes elles changent constamment de place, ce 
> > > > > qui rend la navigation à la souris moins facile.
> > > >
> > > > Il y a un autre soucis sur les connexions lentes, je pense notamment au 
> > > > diaporama:
> > > > -> Une fois qu'une action js est lancée on ne peut pas l'annuler en 
> > > > cliquant sur close ou hors de la fancybox! on est obligé d'attendre que 
> > > > la requête ajax soit terminée.
> > > >
> > > > > Le ven. 9 oct. 2020 à 00:48, nicod_  a écrit :
> > > > > > Le 07/10/2020 à 23:59, nicod_ a écrit :
> > > > > > > Il faudrait pouvoir la faire tester par un·e expert·e 
> > > > > > > accessibilité.
> > > > > > >
> > > > > > > Peut être Roman, s'il nous lit ici ?
> > > > > >
> > > > > > Un premier retour de notabene :
> > > > > >
> > > > > > > Au clavier c'est tout bon (sauf le bouton "fermer" qui n'a pas 
> > > > > > > d'outline perceptible). On cycle dans la popin sans en sortir, 
> > > > > > > pas de perte de focus, etc. Quand on ferme la popin ça remet le 
> > > > > > > focus sur le lien ouvrant. Tout bon.
> > > > > > >
> > > > > > > Les flèches ne sont affichées qu'au survol, ça n'aide pas  
> > > > > > > l'utilisateur pour voir que la popin est un carrousel (il peut 
> > > > > > > pas deviner tout seul gauche/droite).
> > > > > > >
> > > > > > > J'essaie de tester bientôt avec mon lecteur d'écran. Mais déjà 
> > > > > > > c'est bien cool.
> > > > > >
> > > > > > https://toot.cafe/@accessiblestef/105000951846500269
> > > > > >
> > > > > > Ça sent bon tout ça, en plus elle est vachement plus light et jolie
> > > > > > cette box :)
> > > > > >
> > > > > > --
> > > > > > nicod_
> > > > > > ___
> > > > > > 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
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2020-10-09 Par sujet Cerdic
Hello,

merci pour vos retours.

Les points suivants sont donc corrigés :
- le signalement du focus des boutons close/prev/next est forcé dans la css de 
la box, et non hérité par défaut du site
- les boutons prev/next sont en position fixed dans l’écran et ne bougent donc 
plus. Ils sont par ailleurs visible immédiatement et plus seulement au survol
- il y a un background sur les images
- on peut fermer la box pendant son chargement si c’est trop long

--
Cédric
Le 9 oct. 2020 à 15:11 +0200, pierre laszczak , a 
écrit :
> Hello,
>
> Super! je viens de tester à l'instant sur contrib et je suis du même avis que 
> tcharlss
>
> > Une petite suggestion d'UX : pour les galeries, est-ce que c'est possible 
> > de mettre les flèches de navigation en position fixe sur les côté (et ce de 
> > base, sans avoir à bidouiller les styles) ?
> > Là elles sont collées par-dessus l'image, ce qui fait qu'avec des images de 
> > tailles différentes elles changent constamment de place, ce qui rend la 
> > navigation à la souris moins facile.
>
> Il y a un autre soucis sur les connexions lentes, je pense notamment au 
> diaporama:
> -> Une fois qu'une action js est lancée on ne peut pas l'annuler en cliquant 
> sur close ou hors de la fancybox! on est obligé d'attendre que la requête 
> ajax soit terminée.
>
> > Le ven. 9 oct. 2020 à 00:48, nicod_  a écrit :
> > > Le 07/10/2020 à 23:59, nicod_ a écrit :
> > > > Il faudrait pouvoir la faire tester par un·e expert·e accessibilité.
> > > >
> > > > Peut être Roman, s'il nous lit ici ?
> > >
> > > Un premier retour de notabene :
> > >
> > > > Au clavier c'est tout bon (sauf le bouton "fermer" qui n'a pas 
> > > > d'outline perceptible). On cycle dans la popin sans en sortir, pas de 
> > > > perte de focus, etc. Quand on ferme la popin ça remet le focus sur le 
> > > > lien ouvrant. Tout bon.
> > > >
> > > > Les flèches ne sont affichées qu'au survol, ça n'aide pas  
> > > > l'utilisateur pour voir que la popin est un carrousel (il peut pas 
> > > > deviner tout seul gauche/droite).
> > > >
> > > > J'essaie de tester bientôt avec mon lecteur d'écran. Mais déjà c'est 
> > > > bien cool.
> > >
> > > https://toot.cafe/@accessiblestef/105000951846500269
> > >
> > > Ça sent bon tout ça, en plus elle est vachement plus light et jolie
> > > cette box :)
> > >
> > > --
> > > nicod_
> > > ___
> > > 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] Refonte Mediabox [wip]

2020-10-08 Par sujet Cerdic
C’est corrigé : il y a un bizarre « height:100% » sur le body sur contrib, qui 
fait que le body est bloqué à la taille de la fenetre, le reste étant visible 
par chance (grace a un overflow pas défini).
Du coup a un moment le navigateur rescroll à 0.

J’ai forcé un overflow:hidden;height:auto; sur le body quand la box est ouverte 
est ça fait le job

--
Cédric
Le 8 oct. 2020 à 17:21 +0200, Cerdic , a écrit :
> Oui, je vois ça : sur contrib chaque ouverture de la boite (quel que soit le 
> lien) fait scroller le fond de page en haut (on le devine en arrière plan à 
> travers l’opacité de la box).
>
> C’est spécifique à contrib ou une interaction malheureuse avec un autre 
> plugin JS car je n’ai pas ça sur mon site de test qui est en spip-dist+z sans 
> fioriture : le body reste exactement où il est quand je clic que un lien et 
> que la box s’ouvre...
>
> --
> Cédric
> Le 8 oct. 2020 à 17:09 +0200, RealET , a écrit :
> > Cerdic a écrit le 08/10/2020 à 16:59 :
> > > Bon, voila, contrib tourne avec lity en font et la page de demo est là
> > > https://contrib.spip.net/?page=test-mediabox
> > > <https://contrib.spip.net/?page=test-mediabox>
> > Merci Cédric !
> >
> > Sous Chrome 86 (Win 10)
> > Les 2 liens
> > Nouvelle syntaxe, basée sur des data-xx
> > Une popin inline
> > Cliquer pour voir | Cliquer pour voir
> >
> > Et celui juste au dessus scrolle la page tout en haut ce qui fait qu'au
> > retour, si on avait scroller vers le bas avant d'afficher la popup, le
> > lien qu'on venait de cliquer n'est plus au même endroit sur l'écran.
> > Assez déstabilisant.
> >
> >
> > --
> > RealET
> >
> >
> > ___
> > 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
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2020-10-08 Par sujet Cerdic
Oui, je vois ça : sur contrib chaque ouverture de la boite (quel que soit le 
lien) fait scroller le fond de page en haut (on le devine en arrière plan à 
travers l’opacité de la box).

C’est spécifique à contrib ou une interaction malheureuse avec un autre plugin 
JS car je n’ai pas ça sur mon site de test qui est en spip-dist+z sans 
fioriture : le body reste exactement où il est quand je clic que un lien et que 
la box s’ouvre...

--
Cédric
Le 8 oct. 2020 à 17:09 +0200, RealET , a écrit :
> Cerdic a écrit le 08/10/2020 à 16:59 :
> > Bon, voila, contrib tourne avec lity en font et la page de demo est là
> > https://contrib.spip.net/?page=test-mediabox
> > <https://contrib.spip.net/?page=test-mediabox>
> Merci Cédric !
>
> Sous Chrome 86 (Win 10)
> Les 2 liens
> Nouvelle syntaxe, basée sur des data-xx
> Une popin inline
> Cliquer pour voir | Cliquer pour voir
>
> Et celui juste au dessus scrolle la page tout en haut ce qui fait qu'au
> retour, si on avait scroller vers le bas avant d'afficher la popup, le
> lien qu'on venait de cliquer n'est plus au même endroit sur l'écran.
> Assez déstabilisant.
>
>
> --
> RealET
>
>
> ___
> 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] Refonte Mediabox [wip]

2020-10-08 Par sujet Cerdic
Bon, voila, contrib tourne avec lity en font et la page de demo est là
https://contrib.spip.net/?page=test-mediabox

Les images choisies pour la demo sont les images les plus lourdes et des 
petites images, donc normal que certaines soit possiblement un peu lentes à 
charger.

J’ai désactivé ancre douce aussi, qui foirait le focus sur les liens ouvrant 
une box inline (et qui plus est ne semble plus marcher correctement)

--
Cédric
Le 8 oct. 2020 à 15:48 +0200, nicod_ , a écrit :
> Le 08/10/2020 à 11:10, Cerdic a écrit :
> > Probablement que le mieux serait de le mettre le plugin mediabox_plus
> > sur contrib qui est en 3.3 je crois (en basculant aussi la branche du
> > plugin mediabox), et on aurait la page de démo et on pourrait la tester
> > en conditions réelles
>
> Ça me parait un très bon plan.
>
> --
> nicod_
> ___
> 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] Refonte Mediabox [wip]

2020-10-08 Par sujet Cerdic
Non je pense pas qu’elle soit testable en 3.2

Pour info j’ai vérifié et/ou corrigé les points suivants :

- focus sur le premier élément tabulable (qui est le bouton close)
- tab et shift-tab ne se déplacent pas en dehors de la fenetre modale
- fermeture avec Esc ou au clic à l'extérieur de la fenêtre
- Let me use the left and right arrow keys to step through images in a 
slideshow.
- When I press Esc, close the lightbox.
- add focusable elements (links or buttons) for close/next/previous, put 
keyboard focus on the first focusable object in the lightbox, make sure I can’t 
tab to something behind the lightbox, and make it visually obvious which object 
has keyboard focus.
- When the lightbox closes, return keyboard focus to where it was when I opened 
it.

Par ailleurs
- les images sont balisées via un … avec un aria-describedby sur la balise img qui 
pointe sur le figcaption
- le markup de la box utilise   (mais je me demandais si garder ça tout 
le temps ou si dans le cas de visualisation des images un div serait plus 
adapté), avec un title explicite qui mentionne que Echap ferme la box
- tout le contenu derrière est mis en aria-hidden (mais sans wrapper autour, 
donc sans modification du markup qui peut être un problème)

- le déclencheur peut être un lien comme d’hab ou un bouton, c’est à 
l’initiative de celui qui fait le site et ça c’est pas vraiment dans le scope 
du plugin

Probablement que le mieux serait de le mettre le plugin mediabox_plus sur 
contrib qui est en 3.3 je crois (en basculant aussi la branche du plugin 
mediabox), et on aurait la page de démo et on pourrait la tester en conditions 
réelles

--
Cédric
Le 7 oct. 2020 à 23:59 +0200, nicod_ , a écrit :
> Le 07/10/2020 à 15:59, Cerdic a écrit :
> > J’ai donc joué un peu avec lity et plus ça va plus je pense que c’est un
> > bon choix :
> > - la box est très légère et bien codée, tout en étant très facilement
> > extensible, et maintenue
> > - j’ai amélioré l’implémentation dans le plugin
>
> Super nouvelle !
>
> Il faudrait pouvoir la faire tester par un·e expert·e accessibilité.
>
> Peut être Roman, s'il nous lit ici ?
>
> A ton avis, ce serait utilisable sur un SPIP 3.2 ? Si oui, je peux la
> faire tester par Temesis éventuellement.
>
> --
> nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2020-10-07 Par sujet Cerdic
J’ai donc joué un peu avec lity et plus ça va plus je pense que c’est un bon 
choix :
- la box est très légère et bien codée, tout en étant très facilement 
extensible, et maintenue
- j’ai amélioré l’implémentation dans le plugin 
https://git.spip.net/spip-contrib-extensions/mediabox_plus et j’ai pu assez 
facilement ajouter la prise en charge ajax et la gestion des galeries, ainsi 
qu’améliorer le markup en gérant le focus (focus sur le bouton close à 
l’ouverture, retour où l’on était à la fermeture), le markup (balise  + 
figure/figcaption avec un aria-describedby sur les images)

On a maintenant une prise en charge complète des différents types de contenu 
(image/inline/ajax/iframe) et une prise en charge des galeries à l’identique de 
ce que faisait colorbox (ainsi que la gestion des events evidemment)

Ce n’est pas encore tout à fait industriel, il reste un peu d’optimisation à 
faire sur les transitions en mode galerie, et à ajouter la configuration comme 
on avait pour colorbox (min/max-width/height et opacité), et quelques 
traductions à compléter, sur les erreurs principalement.

Pour le reste c’est testable avec le plugin mediabox dans sa branche 
dev/mediabox-extensible + le plugin mediabox_plus

--
Cédric
Le 5 oct. 2020 à 17:57 +0200, Cerdic , a écrit :
> Oui, tout à fait, je suis (re)tombé dessus ensuite, et elle semble avoir bien 
> des qualités aussi en terme d’accessibilité, tout en étant très légère.
>
> Petit défaut, elle ne gère pas du tout les galeries, et son developpeur 
> considère que c’est hors de son objectif, mais il me semble qu’il y a tous 
> les points d’entrée pour faire ça en personalisation - et sinon son 
> developpeur a dit qu’il était ok pour ajouter des points d’entrées pour le 
> permettre.
>
> Je viens d’intégrer une version dans le plugin proof of concept pour 
> progresser dessus
> https://git.spip.net/spip-contrib-extensions/mediabox_plus/commit/3983cec76af7a66612074762e26ea84aa7547c60
>
> --
> Cédric
> Le 5 oct. 2020 à 15:34 +0200, CSI , a écrit :
> > Bonjour,
> >
> > J'avais aussi repéré ça:  https://sorgalla.com/lity/  mais j'ai pas testé. 
> > Se revendique "accessible" aussi mais j'ai l'impression que c'est comme les 
> > termes "durable", "vert", "illimité", etc ... plus beaucoup de matière 
> > derrière le discours marketing :-( En tous cas ça a l'air léger (7k + 3k), 
> > ça fait à peu près tout sauf .. les galeries j'ai l'impression.
> >
> > Le 05/10/2020 à 15:10, Cerdic a écrit :
> > > Bon donc en synthèse, après une rapide revue des troupes :
> > >
> > > • la modale de Nicolas est top et accessible… pour une modale : elle fait 
> > > très bien le job pour un usage de modale avec interactions, mais elle 
> > > fait pas du tout la gestion des medias (ie gérer le chargement d’images, 
> > > d’iframe, adapter la taille de la popin à la taille des images, gérer les 
> > > galeries avec le passage suivant/précédent...)
> > > • featherlight pas plus que glightbox ne sont particulièrement 
> > > accessibles (on a bien une navigation au clavier dans les 2 cas, mais 
> > > c’est le service minimum)
> > > • tobii se revendique accessible mais est encore totalement en dev cf 
> > > https://github.com/rqrauhvmra/tobii/issues/28
> > > • modaal https://humaan.com/modaal/ semble la plus intéressante, avec une 
> > > bonne base concernant l’accessibilité et le support des medias et 
> > > galleries…
> > > MAIS elle ne semble pas très activement maintenue. Je vois des PR et des 
> > > Issues sur https://github.com/humaan/Modaal qui sont un peu gênantes, 
> > > concernent l’accessibilité ou le support des versions récentes de jQuery
> > >
> > > On a donc aucune solution prêt à l’emploi et que des emmerdes à gérer :p
> > >
> > --
> > Pierre
> > ___
> > 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
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2020-10-05 Par sujet Cerdic
Oui, tout à fait, je suis (re)tombé dessus ensuite, et elle semble avoir bien 
des qualités aussi en terme d’accessibilité, tout en étant très légère.

Petit défaut, elle ne gère pas du tout les galeries, et son developpeur 
considère que c’est hors de son objectif, mais il me semble qu’il y a tous les 
points d’entrée pour faire ça en personalisation - et sinon son developpeur a 
dit qu’il était ok pour ajouter des points d’entrées pour le permettre.

Je viens d’intégrer une version dans le plugin proof of concept pour progresser 
dessus
https://git.spip.net/spip-contrib-extensions/mediabox_plus/commit/3983cec76af7a66612074762e26ea84aa7547c60

--
Cédric
Le 5 oct. 2020 à 15:34 +0200, CSI , a écrit :
> Bonjour,
>
> J'avais aussi repéré ça:  https://sorgalla.com/lity/  mais j'ai pas testé. Se 
> revendique "accessible" aussi mais j'ai l'impression que c'est comme les 
> termes "durable", "vert", "illimité", etc ... plus beaucoup de matière 
> derrière le discours marketing :-( En tous cas ça a l'air léger (7k + 3k), ça 
> fait à peu près tout sauf .. les galeries j'ai l'impression.
>
> Le 05/10/2020 à 15:10, Cerdic a écrit :
> > Bon donc en synthèse, après une rapide revue des troupes :
> >
> > • la modale de Nicolas est top et accessible… pour une modale : elle fait 
> > très bien le job pour un usage de modale avec interactions, mais elle fait 
> > pas du tout la gestion des medias (ie gérer le chargement d’images, 
> > d’iframe, adapter la taille de la popin à la taille des images, gérer les 
> > galeries avec le passage suivant/précédent...)
> > • featherlight pas plus que glightbox ne sont particulièrement accessibles 
> > (on a bien une navigation au clavier dans les 2 cas, mais c’est le service 
> > minimum)
> > • tobii se revendique accessible mais est encore totalement en dev cf 
> > https://github.com/rqrauhvmra/tobii/issues/28
> > • modaal https://humaan.com/modaal/ semble la plus intéressante, avec une 
> > bonne base concernant l’accessibilité et le support des medias et galleries…
> > MAIS elle ne semble pas très activement maintenue. Je vois des PR et des 
> > Issues sur https://github.com/humaan/Modaal qui sont un peu gênantes, 
> > concernent l’accessibilité ou le support des versions récentes de jQuery
> >
> > On a donc aucune solution prêt à l’emploi et que des emmerdes à gérer :p
> >
> --
> Pierre
> ___
> 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] Refonte Mediabox [wip]

2020-10-05 Par sujet Cerdic
Bon donc en synthèse, après une rapide revue des troupes :

• la modale de Nicolas est top et accessible… pour une modale : elle fait très 
bien le job pour un usage de modale avec interactions, mais elle fait pas du 
tout la gestion des medias (ie gérer le chargement d’images, d’iframe, adapter 
la taille de la popin à la taille des images, gérer les galeries avec le 
passage suivant/précédent...)
• featherlight pas plus que glightbox ne sont particulièrement accessibles (on 
a bien une navigation au clavier dans les 2 cas, mais c’est le service minimum)
• tobii se revendique accessible mais est encore totalement en dev cf 
https://github.com/rqrauhvmra/tobii/issues/28
• modaal https://humaan.com/modaal/ semble la plus intéressante, avec une bonne 
base concernant l’accessibilité et le support des medias et galleries…
MAIS elle ne semble pas très activement maintenue. Je vois des PR et des Issues 
sur https://github.com/humaan/Modaal qui sont un peu gênantes, concernent 
l’accessibilité ou le support des versions récentes de jQuery

On a donc aucune solution prêt à l’emploi et que des emmerdes à gérer :p

--
Cédric
Le 22 sept. 2020 à 14:35 +0200, nicod_ , a écrit :
> Le 22/09/2020 à 09:05, Cerdic a écrit :
> > Oui je suis bien d’accord, encore faut-il trouver une telle ressource !
> > Continuons de chercher donc, mais si par hasard il y’a des ressources
> > connues on est preneur !
>
> Parmi mes ressources habituelles (et validées), les composants de
> Nicolas Hoffmann, dont sa modale, qui existent en version jQuery :
> https://a11y.nicolas-hoffmann.net/
> et en ES2015 :
> https://van11y.net/
>
> Sa modale a été adaptée dans la lib Scampi ("pour une pleine conformité
> RGAA") :
> https://pidila.gitlab.io/scampi/documentation/modal.html
>
> Précisions intéressantes sur les attentes en terme d'a11y :
>
> > Respect du design pattern 
> > https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal
> >
> > focus sur le premier élément tabulable
> > tab et shift-tab ne se déplacent pas en dehors de la fenetre modale
> > fermeture avec Esc ou au clic à l'extérieur de la fenêtre
>
> Autres ressources :
>
> http://www.webaxe.org/?s=lightbox
>
> https://www.456bereastreet.com/archive/200910/lightboxes_and_keyboard_accessibility/
>
> Et notamment, sur les attentes en terme d'a11y :
>
> > - Let me use the left and right arrow keys to step through images in a 
> > slideshow.
> > - When I press Esc, close the lightbox.
> > - Do one of the following:
> > - Either add focusable elements (links or buttons) for close/next/previous, 
> > put keyboard focus on the first focusable object in the lightbox, make sure 
> > I can’t tab to something behind the lightbox, and make it visually obvious 
> > which object has keyboard focus.
> > - or close the lightbox when I press Tab.
> > - When the lightbox closes, return keyboard focus to where it was when I 
> > opened it.
>
>
> --
> nicod_
___
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] [crayons] sur touti-patch-1 : Mise à jour de 'css/crayons.css' suppression de (...)

2020-10-03 Par sujet Cerdic
Salut Touti,

ce max-width est là depuis toujours ou presque, pour des raisons principales de 
lisibilité : si on édite sur un div qui est très large on se retrouve avec des 
lignes de texte beaucoup trop longues.

Dans la dernière modif le concernant, j'avais modifié le max-width fixe en px 
en le passant en rem, ce qui est plus générique
https://git.spip.net/spip-contrib-extensions/crayons/commit/b61034d6c81257a7b890632d0c5a9a81d9be364e

Je ne pense pas que le supprimer soit une bonne idée, c’est généralement mieux 
de l’avoir.
Si il y a des cas précis qui ne le justifient pas je pense qu’il faut 
simplement personaliser dans la css de ton site, non ?

--
Cédric
Le 30 sept. 2020 à 21:00 +0200, touti , a écrit :
> spip-contrib-extensions/crayons
> -
> Par touti, le 30 septembre 2020 à 20h59min :
>
> Mise à jour de 'css/crayons.css'
>
> suppression de max-width: 44rem; qui restreint la largeur du textarea 
> inutilement (je suppose que crayon se base sur le width de la div englobante )
>
>
> *Modifié*
> css/crayons.css
>
> Détails : 
> https://git.spip.net/spip-contrib-extensions/crayons/commit/ed4c2620cf2ccc43260549724f0ec814bab5821e
>
> ___
> spip-zone-com...@rezo.net - 
> https://listes.rezo.net/mailman/listinfo/spip-zone-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] Plugin Font Awesome

2020-09-27 Par sujet Cerdic
Hello !

Il te plaisait pas mon plugin fontawesome tout récent et à jour ?
https://git.spip.net/spip-contrib-extensions/fontawesome

(qui n’a rien à voir avec l’ancien plugin utilisé pour faire des raccourcis 
typo)

--
Cédric
Le 24 sept. 2020 à 13:58 +0200, erational , a écrit :
> Hello,
>
> Il y a un plugin Font Awesome sur la zone:
> https://contrib.spip.net/Picto-avec-FontAwesome
>
> J'aimerai le mettre à jour à la version 5.14.0 de la police et en
> profiter pour rationaliser le process comme pour les plugins bootstrap
>
> - renommer le plugin de façon explicite fontawesome
>
> ensuite quelle statégie adopter par rapport aux versions  ?
> - créer un dépot avec un préfixe explicite par version majeure ?
> fontawesome5, fontawesome6, . (ce qu'on a fait pour bootstrap)
> ou
> - avoir un master et taguer les versions selon leur intégration.
>
>
> mon objectif est de fournir la librairie simplement avec autres plugins
> sans casser les designs  si on met à jour via svp.
>
> des avis ?
>
>
>
> --
> _
> https://www.erational.org
>
> ___
> 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] Refonte Mediabox [wip]

2020-09-22 Par sujet Cerdic
Oui je suis bien d’accord, encore faut-il trouver une telle ressource ! 
Continuons de chercher donc, mais si par hasard il y’a des ressources connues 
on est preneur !

--
Cédric
Le 21 sept. 2020 à 18:32 +0200, nicod_ , a écrit :
> Le 21/09/2020 à 14:26, nicod_ a écrit :
> > Le 20/09/2020 à 11:23, Cerdic a écrit :
> > > Mais donc,
> > > ce qui aiderait vraiment,
> > > c’est un test éclairé et comparé sous l’angle de l’accessibilité, de
> > > featherlight et glightbox, pour décider laquelle embarquer par défaut
> > > dans le core...
> >
> > Je peux demander à des experts avec qui je suis en contact.
>
> Un premier retour :
>
> > En regardant rapidement ces 2 solutions, elles sont, toutes les 2, très 
> > éloignées des standards d'accessibilité.
> > Elles possèdent de nombreux problèmes bloquants.
> > Je ne sais pas si vous pourriez les adapter, mais même dans ce cas je ne 
> > pense pas qu'elles constituent une bonne base de départ.
> >
> > D'un point de vue global, je pense qu'il faudrait peut-être partir d'une 
> > ressource qui clame son respect de l'accessibilité (même là il n'y aura pas 
> > forcément que des bonnes choses) car lorsque le sujet n'est pas 
> > explicitement déclaré, il serait miraculeux d'en avoir une prise en compte, 
> > même minimale.
> Voilà voilà... :)
>
> --
> nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2020-09-20 Par sujet Cerdic
Mais donc,
ce qui aiderait vraiment,
c’est un test éclairé et comparé sous l’angle de l’accessibilité, de 
featherlight et glightbox, pour décider laquelle embarquer par défaut dans le 
core...

--
Cédric
Le 20 sept. 2020 à 10:27 +0200, RealET , a écrit :
> Cerdic a écrit le 19/09/2020 à 16:27 :
> > Sur le sujet, je creuse un peu les libs récentes car j’ai un peu de
> > doute sur l’accessibilité de featherlight...
> Je suis tombé sur
> https://github.com/rqrauhvmra/tobi
> (qui a une v2 en beta
> https://github.com/rqrauhvmra/Tobii)
> via https://awesomeopensource.com/project/rqrauhvmra/tobi
> site qui permet de rechercher des projet accessibles :
> https://awesomeopensource.com/projects/a11y
> https://awesomeopensource.com/projects/lightbox
>
> La doc est plein d'Aria ;-)
>
> --
> RealET
>
>
> ___
> 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] Refonte Mediabox [wip]

2020-09-20 Par sujet Cerdic
Oui j’ai vu tobii aussi mais je l’ai pas retenue car :

• la v1 est archivée, figée, donc pas question de démarrer une nouvelle 
séquence dessus
• la v2 est en beta, et de ce que j’ai testé ça semblait globalement pas très 
fini - mais les seules démos sont sous codepen, ce qui facilite pas le test en 
conditions réeelles.
Mais globalement donc cette v2 me parait encore très jeune et pas rôdée et j’ai 
pas trop envie d’essuyer les plâtres et de se retrouver à maintenir une box en 
plus du reste...


--
Cédric
Le 20 sept. 2020 à 10:27 +0200, RealET , a écrit :
> Cerdic a écrit le 19/09/2020 à 16:27 :
> > Sur le sujet, je creuse un peu les libs récentes car j’ai un peu de
> > doute sur l’accessibilité de featherlight...
> Je suis tombé sur
> https://github.com/rqrauhvmra/tobi
> (qui a une v2 en beta
> https://github.com/rqrauhvmra/Tobii)
> via https://awesomeopensource.com/project/rqrauhvmra/tobi
> site qui permet de rechercher des projet accessibles :
> https://awesomeopensource.com/projects/a11y
> https://awesomeopensource.com/projects/lightbox
>
> La doc est plein d'Aria ;-)
>
> --
> RealET
>
>
> ___
> 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] Refonte Mediabox [wip]

2020-09-19 Par sujet Cerdic
Sur le sujet, je creuse un peu les libs récentes car j’ai un peu de doute sur 
l’accessibilité de featherlight...

Dans les libs dispos qui font tous les types de contenu et dont la licence 
serait compatible sans ambiguité je trouve 
https://biati-digital.github.io/glightbox/ qui a l’air pas mal du tout, moderne 
et maintenue

Un avis, un retour d'experience ?

--
Cédric
Le 18 sept. 2020 à 22:20 +0200, pierre laszczak , a 
écrit :
> Super merci!
>
> @nicod_  Oui ça fonctionnait bien et c'était déja compatible avec le markup 
> existant (z-bloc ajax, iframe html... toussa) et les class css mediabox qui 
> déclenchaient / definissaient  les galeries
>
> Dans le privé le seul soucis constaté c'était les maj  successives de plugin 
> ou les installations par lots qui ne s'affichaient pas dans la boite modal. 
> Pour le reste c'était plutôt niquel.
>
___
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] Refonte Mediabox [wip]

2020-09-18 Par sujet Cerdic
Hello,

j’ai donc lancé le chantier de refonte de la mediabox en m’inspirant très 
fortement de ce qu’a fait Placido que je remercie donc pour sa contribution et 
la mise a disposition de son code dans lequel j’ai allègrement pioché.

Pour assurer la compatibilité avec l’existant et pour garder une structure plus 
simple j’ai un peu divergé sur la forme et la position des pipelines et la 
façon dont on configure le tout, mais ça reste quand même très proche.

Vous trouverez donc une branche de travail sur le plugin mediabox
https://git.spip.net/spip/mediabox/src/branch/dev/mediabox-extensible
qui en l’état ne fait visuellement rien de plus que le master, sauf à proposer 
un pipeline en plus pour permettre l’extension, obtenue après refonte.

Et vous trouverez par ailleurs un plugin proof of concept qui ajoute la box 
featherlight et la rend donc disponible comme choix pour le site public
https://git.spip.net/spip-contrib-extensions/mediabox_plus

La peinture n’est pas fraiche, il reste des bugs js sur l’intégration des box, 
des cas aux limites, et je pense unifier le namespace en ‘mediabox’ car ‘box’ 
tout court est pas assez différenciant et on risque des collisions.
L’intégration featherlight propose une configuration spécifique à cette box, 
mais ce n’est pas utilisé en l’état, j’ai repris telle quelle la css de la lib

Le plugin mediabox_plus propose aussi une page de test pour Z qui permet de 
tester les différentes utilisations de la box et de vérifier qu’on ne casse 
rien.
Si vous avez sous la main des petits cas un peu tordus n’hésitez pas à 
completer cette page

Bises,

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

Re: [spip-dev] SPIP 3.3 et Compositions

2020-09-18 Par sujet Cerdic
C’est le bon usage oui, mais...

il nous manque la possibilité de spécifier la taille que l’on veut sur le 
filtre balise_img car le filtre a été fait a une epoque sans retina, et en vrai 
aujourd’hui on voudrait plutôt faire un truc du genre
[(#CHEMIN_IMAGE{cadenas-32.png}|balise_img{16})]
ou
[(#CHEMIN_IMAGE{cadenas-xx.svg}|balise_img{16})]

j’ai donc filtre plus complet en chantier que j’essaye de stabiliser et je 
reflechi comment gérer la transition en cassant le moins de chose, notamment je 
pense qu’il faut supporter des syntaxes du genre :

// images carrees
[(#CHEMIN_IMAGE{cadenas-xx.svg}|balise_img{16})]

// specifier la resolution plutot que la taille explicite
[(#CHEMIN_IMAGE{cadenas-32.png}|balise_img{x2})]

// specifier largeurxhauteur
[(#CHEMIN_IMAGE{truc.svg}|balise_img{16x32})]

Je ne sais pas encore si on peut gérer la transition en étendant le filtre 
balise_img et sans casser ses usages anciens tout en supportant la nouvelle 
syntaxe, et sinon il faudra lui trouver un joli nom explicite

--
Cédric
Le 18 sept. 2020 à 10:04 +0200, Bruno Bergot , a écrit :
> Hop,
>
> Le 17/09/2020 à 13:34, Bruno Bergot a écrit :
> >
> > C'est corrigé cf
> > https://git.spip.net/spip-contrib-extensions/compositions/commit/1f0f6f5b944c76bd04bff3528aa7a81b5eb9bd6b
> >
>
> Un autre patch possible serait un simple
> [(#CHEMIN_IMAGE{cadenas-16.png}|balise_img)] qui permet d'avoir l'image
> svg à la bonne taille grâce à
> https://git.spip.net/spip/spip/commit/da298555d81f323361ca320fb8d3c97307390742
>
> Cedric, t'en penses quoi ? Perso ça me paraît plus clair/pérenne.
>
> ++
> b_b
___
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 et Compositions

2020-09-17 Par sujet Cerdic
Hello,

C’est là
https://git.spip.net/spip/spip/commit/9ef4c078fae4ccef00782a3901b340fe9888d2d3

--
Cédric
Le 17 sept. 2020 à 17:46 +0200, JLuc , a écrit :
> Le 17/09/2020 à 17:34, Bruno Bergot a écrit :
> > Point de sorcellerie, juste de la magie :)
> > https://git.spip.net/spip/spip/commit/b572418d55c7cad0d9e1542a9f7f18e8ff7db25e
>
> Hihi non je ne crois pas que cette ligne spoile le "truc"
> car elle teste si le fichier existe, auquel cas ça le renvoie,
> et donc ok ça permet à #CHEMIN_IMAGE de renvoyer un SVG reçu en paramètre...
> mais dans le code de composition corrigé, #CHEMIN_IMAGE reçoit un PNG en 
> argument
> 
> et renvoie un SVG
> c'est bien ça ?
> Alors c'est autre chose. Ça pourrait être dans
> https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/icone_renommer.php
> qui fait de la magie aussi, mais je vois pas où car nulle par ça ne favorise 
> un svg
> et le fichier n'a pas changé dans la branche "icones_svg"
> ...
>
> JL
>
>
>
> ___
> 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] [conception] Un plugin Progressive Web App commun en coquille vide ? (1 SW 2 rule dem all)

2020-09-15 Par sujet Cerdic
yakafokon (tm)

On peut faire plein de choses pour simplifier, industrialiser, automatiser, 
mais bon, le premier point c’est de valider que tout marche : ie si je fais une 
nouvelle version avec des choses qui changent est-ce que la mise à jour se fait 
bien, est-ce que j’evite les liens brisés, est-ce il y a des utilisateurs qui 
restent scotchés avec du vieux contenus a vie, est-ce que..

Bref, avant de sortir la sulfateuse qui t’envoie une nouvelle version par 
minute, faudrait déjà faire en sorte que « envoyer une nouvelle version » ça 
marche correctement et bien, et c’est pas acquis.
Bref on en est là, de ce que j’ai vu sur contrib y a des bugs, et il faut 
passer du temps dessus pour les corriger.
Mais c’est pas un problème simple, et pour exemple je me suis payé pendant des 
mois des « pages introuvables » sur le site de francetvinfo à cause de leur 
serviceworker (ou d’une version bugguée que j’ai eu un moment dans mon 
navigateur) et il suffisait que je fasse f5 pour recharger et voir la page.

Le problème étant que tu as zéro information pour savoir ce qui se passe, que 
tu peux rien loger pour debug vu que tout se passe dans le navigateur du 
visiteur, et donc c’est un debug de longue haleine.
Quand ça sera totalement fiable on pourra voir la suite oui

--
Cédric
Le 15 sept. 2020 à 13:29 +0200, RastaPopoulos , a écrit 
:
> Le 15/09/2020 à 08:25, Cerdic a écrit :
> > Mais potentiellement il faut remettre à jour la listes des urls à 
> > télécharger, en particulier si tu as des ressources générées 
> > automatiquements (css, js..) dont les URLs peuvent changer (si tu as fais 
> > des modifs de squelette), ou si tu veux que les visiteurs téléchargent par 
> > défaut les derniers articles ou…
> >
> > bref ça dépend aussi comment tu veux utiliser le plugin
>
> Ok alors pour cette liste de démarrage : y a-t-il un squelette surchargeable 
> permettant de personnaliser la liste des pages (justement pour "les derniers 
> articles" ou plus précisément "la même liste que ceux qu'on voit sur 
> l'accueil") ?
>
> Car la doc parle de comment générer des boutons pour des objets entiers avec 
> offline/urls-{objet}.html, ça ok. Mais pour la liste automatiquement chargée 
> à l'installation ?
> J'ai vu que dans la config ya un champ libre pour en personnaliser en plus à 
> la main, mais ça c'est du ponctuel manuel. Pour faire comme les boutons pour 
> objets, des automatismes (donc avec boucles) pour lister dans l'installation 
> les mêmes que sur l'accueil, ya un squelette ou un pipeline PHP possible ?
>
> Pour le build d'installation avec spip offline:build:services (ou le rebuild 
> total avec les objets aussi), ya deux possibilités, pour que ce soit moins 
> complexe pour Booz, et qu'il n'y ait que à changer le numéro dans l'admin :
> - sur le serveur on peut programmer un vrai cron pour l'appeler une fois par 
> nuit, et donc le lendemain ça enverra les nouveaux contenus aux gens, si ça 
> suffit comme période
> - si on veut encore plus de réactivité, on pourrait imaginer une option 
> "--if-version-changed". Dans ce cas on pourrait programmer un vrai cron 
> *toutes les minutes*, mais la commande sortirait immédiatement si ça détecte 
> que la version éditoriale dans la config n'a pas changé depuis le dernier 
> build. Évidemment pour pouvoir faire ça, il faut que lors d'un build, ça 
> enregistre dans un fichier ou en base, le numéro de la version éditoriale 
> utilisée à ce moment, pour pouvoir comparer ensuite.
>
> --
> RastaPopoulos
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2020-09-15 Par sujet Cerdic
Faut lire TOUTE la doc, et notamment la partie 
https://git.nursit.net/open/offline#build

Le numero de version editoriale, c’est un flag qu’on modifie et ça permet de 
forcer une mise à jour chez les internautes.
Mais potentiellement il faut remettre à jour la listes des urls à télécharger, 
en particulier si tu as des ressources générées automatiquements (css, js..) 
dont les URLs peuvent changer (si tu as fais des modifs de squelette), ou si tu 
veux que les visiteurs téléchargent par défaut les derniers articles ou…

bref ça dépend aussi comment tu veux utiliser le plugin

--
Cédric
Le 14 sept. 2020 à 22:40 +0200, RastaPopoulos , a écrit 
:
> Le 28/07/2020 à 20:43, BoOz a écrit :
> > la mise à jour de la version éditoriale est complexe (ligne de commandes 
> > plus vider le cache plus..., j'ai fini par me décourager en testant, il 
> > faudrait que je m'y remette)
>
> Ce point m'interroge : je croyais en lisant la doc que justement il y avait 
> *dans l'interface* de la config, un "numéro éditorial" changeable 
> manuellement (donc pas un admin sys), et que changer ce champ permettait de 
> forcer la mise à jour du contenu chez les gens.
>
> Et pas juste la doc, c'est l'explication collée au champ même : "Version 
> éditoriale. Le changement de numéro de version force la mise à jour de toutes 
> les pages en cache chez tous les visiteurs."
>
> Du coup ce que tu dis pour le Diplo parait bizarre, ça ne marche pas ?
>
> --
> RastaPopoulos
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
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] Release, Git, Composer

2020-09-14 Par sujet Cerdic
Je suis d’accord qu’il faut remettre au carré la convention de nommage des tags 
et branches, tant sur le core que sur les plugins du core.
On peut décider d’utiliser une convention propre à partir de la prochaine 
version 3.3, ou de remettre au propre toutes les branches et tags sur toutes 
les versions 3.x (ou tout, si on est courageux), ça me va.

Par contre, avant de releaser une 3.3 bta et vu qu’on a déjà bien attendu, 
je règlerai bien cette histoire de mediabox pour éviter de s’embarquer 5 ans de 
plus avec une colorbox qui n’est plus du tout à jour...

--
Cédric
Le 14 sept. 2020 à 10:51 +0200, erational , a écrit :
> Bravo Marcimat !
>
> On tente de sortir cette fameuse SPIP 3.3 bta ?
>
> le pad est toujours actif:
> https://semestriel.framapad.org/p/spip3.3-beta
>
> Le 14/09/2020 à 09:59, Matthieu Marcillaud a écrit :
> > # Release, Git, Composer
> >
> > ## Outils de release
> >
> > J’ai pris un peu de temps pour faire des outils de release pour nos
> > prochaines versions, et en attendant de passer un jour espérons le à
> > Composer pour de vrai...
> >
> > Ces outils sont à des emplacements temporaires (déplacés sur la zone
> > si on les utilise vraiment) (pas la peine de mettre en marque ta page :))
> >
> > - https://gitlab.com/magraine/spip-releases
> > - https://gitlab.com/magraine/spip-archives
> > - https://gitlab.com/magraine/spip-packages
> >
> > ### spip-releases
> >
> > Ce script permet de faciliter la création des tags et changelog pour
> > SPIP et ses plugins-dist, et de pusher le tout sur les différents Git
> > correspondants. Le script s’adapte et crée (à ce jour) comme c’est
> > fait actuellement (à ce jour) sur ces git (! on en discute plus bas,
> > parce que c’est pas forcément génial...) :
> >
> > - un tag spip-x.y.z pour une branche SPIP (ou spip-x.y.z-beta pour
> > master par exemple)
> > - des tags spip/x.y.z pour les plugins dist.
> >
> > - si on release depuis master, on pose des tags de version en plus sur
> > chaque plugin (v1.0.4 du plugin) éventuellement en incrémentant la
> > version selon le contexte.
> >
> > ### spip-archives
> >
> > Ce script permet de créer un zip d’une version ou branche de SPIP.
> >
> > Il intègre 2 méthodes différentes :
> >
> > - via le résultat du script checkout.php, qui est le plus proche de ce
> > qu’on avait avant, mais a aussi quelques limitations (il lit un
> > fichier .gitsvnextmodules qui n’a plus de sens). Il utilise ensuite
> > `composer archive` pour générer une archive.
> > - via le réstulat d’un `composer install` spécial, qui utilise [un
> > plugin
> > composer-installer](https://github.com/spipremix/composer-installer)
> > spécifique et un repository composer tout aussi spécial (cf:
> > spip-packages). Il y a quelques différences (notamment l’écran de
> > sécurité est forcément à jour), et quelques micros détails.
> >
> >  spip-packages
> >
> > Ce script génère un fichier `packages.json` de type repository pour
> > Composer en déclarant quelques versions de SPIP (branches 3.1+ et
> > derniers tags) et quelques versions de plugins (branches, derniers
> > tags, et tags spip/x.y.z), et ajoute les require qui vont bien sur
> > `spip/spip` correspondant à la branche/tag, en s’appuyant sur la
> > présence des tags `spip/x.y.z` des plugins.
> >
> > C’est assez limité comme utilisation en dehors du script spip-archives.
> >
> > ## TODO Git pour Composer
> >
> > De regarder ceci m’a fait pointer du doigt différents problèmes à
> > corriger avec les repos Git de SPIP et des plugins dist
> >
> > Effectivement il est de bon ton de suivre 'semver' pour les branches
> > et tags de version afin que Composer puisse comprendre à quoi tout ça
> > correspond.
> >
> > Problèmes rencontrés :
> >
> > ### sur spip/spip
> >
> > - les branches sont nommées `spip-3.2`.
> >   - devrait être `3.2` (ou `3.2.x` — ou à la rigueur `v3.2` ou `v3.2.x`)
> > - les tags sont nommés `spip-3.2.7`,
> >   - devrait être `3.2.7` ou `v3.2.7`
> >
> > ### sur spip/{plugin} (tel que spip/mots)
> >
> > - il existe des branches `3.2`, `3.1`, `3.0`
> >   - ces branches correspondent aux versions de SPIP et pas aux
> > branches de version du plugin
> >   - devraient être renommées `spip-3.2` pour l’historique
> > éventuellement et le maintient des versions SPIP encore actives
> >   - ne devrait plus servir pour spip >= 3.3 (ou 3.4)
> > - ils ont des tags `spip/x.y.z`
> >   - admettons (pour l’historique), mais il ne faudrait pas poursuivre
> > ça dans le futur (c’est à la distribution SPIP de mettre un require
> > adapté, et au plugin de définir sa compatibilité avec SPIP).
> > - ils n’ont pas de branches pour leurs propres versions
> > - ils n’ont pas tous les tags de leurs différentes versions
> >   - ce n’est pas forcément gênant encore.
> >
> > ### gestion des versions des plugins-dist
> >
> > Avec Git et les tags, il est possible qu’un plugin-dist n’ait pas
> > bougé entre 2 versions de SPIP.
> > On peut temporairement lui ajouter les tags `spip/x.y.z` sur le 

Re: [spip-dev] Fancybox pour une mise a jour de la mediabox ?

2020-09-11 Par sujet Cerdic
Merci Placido,

je vais regarder en détail, car c’était vraiment l’esprit du plugin mediabox 
d’avoir une surcouche api pour permettre de changer de box dans le futur sans 
casser tous les plugins et squelettes.

Je pense qu’il faut sans doute faire quelque chose d’intermédiaire :
- avoir le plugin mediabox dans le core avec une api claire, comme tu as fait
- mais qu’il intègre par défaut une box dans un sous dossier ; du coup 
peut-être pas fancybox en effet, le choix d’une box très light pour le core est 
peut-être pas idiot
- et qu’on puisse choisir ensuite une autre box facilement en activant un 
plugin qui necessitera mediabox et viendra prendre la place de la box par defaut

Mais on peut sans doute faire quelques choix de simplification :
- Je pense pas qu’il faille trop compliquer en essayant d’avoir plusieurs boxs 
qui s'activent d’un coup. Amha il faut que le mecanisme permette d’activer une 
box ou une autre, mais une seule sera dispo à la fois, et donc configurable etc
- sur la possibilité d’avoir des js et css dynamiques en squelette, je suis un 
peu réservé, j’aime vraiment pas trop ça et en terme de perf c’est vraiment pas 
génial

Et les plugins qui ont utilisé directement l’api colorbox au lieu de mediabox 
devront de débrouiller pour s’adapter, c’est une erreur de leur part :)
(y compris SVP !)

(peut-être que pour éviter trop de casse on ajoutera quelques classes 
historiques issues de colorbox ?)

En tout cas la version 3.3 de SPIP parait le bon moment pour changer : il faut 
faire ça sur une montée de version car il y aura un peu de casse quand même, et 
je pense pas qu’il soit une bonne idée d’embarquer colorbox quelques années de 
plus

--
Cédric
Le 11 sept. 2020 à 13:08 +0200, plac...@roxing.net, a écrit :
> J'ai planché il y a quelques temps sur la mise en place d'une mediabox
> alternative, car je trouvais moi aussi la colorbox un peu trop "rigide"
> sur mobile.
>
> Du coup, je suis allé un peu plus loin dans la tentative de faire de
> mediabox une API, sur laquelle on pourrait brancher indifferement
> plusieurs libs.
>
> Du coup on a un découpage comme ceci:
> [core]
> https://framagit.org/cantal-tech/cantal-tech-spip/mediabox
>
> [colorbox]
> https://framagit.org/cantal-tech/cantal-tech-spip/colorbox
>
> [featherlight]
> https://framagit.org/cantal-tech/cantal-tech-spip/featherlight
>
> Les briques sont en place pour connecter d'autres lib, j'avais même fait
> un test avec fancybox (pas publié cependant).
>
> Ç'est fonctionnel en partie privé et publique, et même en prod sur
> quelques sites, mais reste quelques soucis ;
>
> A) la méthode de déploiement est un peu alambiquée, car il faut
> surcharger un plugin-dist, et, sur ce point, SVP est un peu retord. De
> plus, dans la gestion de dépendances actuelle, on ne peut pas spécifier
> que mediabox a besoin d'AU MOINS UNE lib tierce pour fonctionner (mais
> c'est un problème propre à mediabox).
>
> B) Quelques problèmes d'appels à colorbox en dur dans le core
> (https://core.spip.net/issues/4183), ou code js/CSS trop spécifiques sur
> d'autres plugins (inserer_modeles de mémoire).
>
> C) L'organisation du formulaire de configuration de la modale box ; les
> sous-plugins peuvent y insèrer leur propres préférences, (ex: une
> couleur de fond et une opacité pour featherlight) ; Faut-il garder une
> seule configuration générale, ou bien cloisonner chaque configuration
> par en fonction de la lib choisie ?)
>
>
> Avec le recul, assurer un comportement consistant avec plusieurs libs,
> pour l'ensemble de l'eco-système de plugins SPIP me parait illusoir.
>
> Mais adopter un nouvelle lib par défaut, j'acquièce.
> Fancybox est vraiment jolie, quoique un peu gloutone ; et l'ambiguité
> sur la licence associée m'avait finalement reporté sur featherlight.
> ___
> 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

[spip-dev] Fancybox pour une mise a jour de la mediabox ?

2020-09-11 Par sujet Cerdic
Hello,

je (re)découvre la fancybox qui dans sa v3 gère bien tous les types de contenu
https://fancyapps.com/fancybox/3/

Et je me disais que ce serait peut-être un bon plan de l’utiliser comme base 
dans le plugin mediabox de SPIP,
pour remplacer la colorbox qui n’est plus maintenue depuis plusieurs années 
https://github.com/jackmoore/colorbox et a encore des bugs sur les mobiles et 
petits écrans

Des avis, des retour d’expérience ?

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

Re: [spip-dev] Soyez sympa, arrêtez de rembobiner...

2020-09-09 Par sujet Cerdic
Hello !

Bon, il y a moyen de reprendre une activité normale ?

Parce que là :
- personne ne veut plus de subgit
- l’argument de « non mais là on continue à se pourrir la vie avec ce truc 
parce qu’il sert à maintenir un autre truc que personne utilise » ne tient pas 
la route
- quand on aura assez avancé sur composer et qu’on aura pris des décisions il 
sera temps de voir le meilleur moyen de maintenir 2 repos ecrire/ et prive/ et 
SI on a besoin d’un outil automatique pour ça (c’est peut-être demain, mais 
c’est peut-être aussi dans 10 ans donc bon)

Je rappelle quand même que la décision sur laquelle on était d’accord c’était « 
on coupe subgit au 1er juillet ».
C’est ça qu’on a acté, pas « on coupe le svn en ecriture et on garde subgit 
pour synchroniser le svn » car on avait déjà acté que subgit nous posait 
définitivement trop de problème et qu’on ne voulait plus subir tous les aléas 
liés à cet outil.

Donc est-ce qu’on peut définitivement faire ça s’il te plait Camille : couper 
subgit partout, sur tous les repos ?

--
Cédric
Le 8 sept. 2020 à 09:28 +0200, Matthieu Marcillaud , a écrit 
:
> Le 07/09/2020 à 14:49, cam.lafit a écrit :
>
> Mes commits de ce matin ont disparu dans les limbes d’une branche
> "unsynced", envoyé pourtant sur master et spip-3.2...
>
> - https://git.spip.net/spip/spip/commit/ebcf7f8f
> - https://git.spip.net/spip/spip/commit/2edefda9
>
> > Hello
>
> [...]
> > On a encore un cas qui justifie en l'état subgit, c'est le découpage
> > "composer". C'est lui qui permet d'avoir les 2 sous projets ecrire/ et
> > prive/ sans avoir à commiter dessus.
>
> Si c’est que ça, on les supprime, et on verra plus tard.
>
> MM.
>
>
> ___
> 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] =?utf-8?Q?Donn=C3=A9es_?=Exif des images réduites

2020-09-04 Par sujet Cerdic
Je pense que pour image_reduire ça dépend aussi de la méthode que tu as choisi 
dans ecrire/ pour la création des vignettes.
Certaines méthodes probablement perdent aussi les données.

Mais ensuite, pour tous les filtres qui transforment les images (donc modifient 
son  contenu au delà d’une simple mise à l’échelle, donc y compris recadrent) 
il y a en effet création d’une nouvelle image via GD2 et aucun processus de 
recopie des exif de la source vers la destination.

--
Cédric
Le 4 sept. 2020 à 12:18 +0200, JLuc , a écrit :
> Le 17/07/2020 à 15:49, JLuc a écrit :
> > J'ai l'impression que le filtre image_reduire ne tient pas compte des 
> > données exif des photos,
> > et ne fournit aucune exif au fichier de l'image-réduite.
>
> Vacances finies je rééxamine le squelette et les exifs des différentes images 
> produites aux différentes étapes du
> traitement, et il m'apparaît que image_reduire conserve bien les données EXIF
> mais que c'est image_proportion qui les fait disparaître.
> Est-ce que ça facilite t il la prise en compte de ce soucis ?
>
> JL
>
> > Du coup, des photos prises en penchant l'appareil photo, qui ont donc une 
> > exif de rotation qui leur permet d'apparaître
> > partout à l'endroit car les lieux communs de visualisation d'une image 
> > tiennent compte des données exifs de rotation
> > apparaissent tournées une fois réduites
>
> ___
> 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

[spip-dev] Soyez sympa, arrêtez de rembobiner...

2020-09-03 Par sujet Cerdic
Bon donc hier j’ai envoyé 2 commits sur spip sur les branches spip 3.2 et 
master.

Et au moment de pousser une branche de dev et de faire une PR aujourd’hui je 
vois que ces deux commits ont disparus de master et de la branche 3.2.

De fait, quand je pioche dans les mails d’hier et que je clic sur les liens, 
les commits sont bien dans l’arbre, mais dans des branches
subgit/unsynced/...

https://git.spip.net/spip/spip/commit/9825b8b5874043fa987dfa5f6120bd04a2246e9d
https://git.spip.net/spip/spip/commit/06da062331024d62cf80d1ed06c3f5125816c783

Je constate que les 2 commits ne sont pas non plus sur le mirroir.

J’ai essayé de les repousser en regardant aussitot sur le git.spip.net : mes 2 
commits arrivent bien sur les branches, puis après pfiout ils disparaissent.

Ce qui m’amène aux reflexions et questions suivantes :

- jamais aucune forge git ne m’avait perdu des commits avant que de bosser sur 
git.spip.net !
- on avait dit qu’on se débarassait de subgit au 1er juillet, non ?
- qu’est ce que ce truc fait encore à nous pourrir la vie alors que plus 
personne n’en veut et qu’il ne nous sert plus à rien ?

On a pas autre chose à faire de notre peu d’énergie que de passer notre temps à 
récupérer les oups et les foirures de subgit, ou à s’écharper à son sujet ?

On a essayé, aussi fort et autant qu’on a pu.
Ça ne marche pas de façon satisfaisante.
Donc on va pas encore se farcir le truc des mois, on coupe et on arrête les 
frais.

Je comprends même pas que ce soit encore un sujet...

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

Re: [spip-dev] Écriture inclusive

2020-08-05 Par sujet Cerdic
Ce n’est pourtant pas compliqué à comprendre avec ton cerveau :
 - si X dit quelque chose
 - Y dit que ça le ou la blesse
 - X n’a aucune légitimité à expliquer à Y ce qu’il.elle devrait ressentir ou 
non et en quoi quand même c’est bien embêtant parce que X n’a pas envie de dire 
les choses autrement, et que c’est pas très ouvert comme position que de 
demander à X de changer de façon de dire les choses

Bref, soit X fait un effort pour changer de façon de s’exprimer pour ne pas 
blesser Y, soit X se tait.
Dans le cas contraire c’est nier le ressenti de Y, en se cachant sous des 
prétextes fallacieux, en coupant les cheveux en 4, ou toute autre stratégie 
visant à surtout ne pas être dérangé dans son petit confort parce que au fond X 
lui IL s’en fou, IL est très bien comme ça.

Il n’y a aucun débat à avoir sur le fait que des personnes se sentent ici 
exclues - voire niées, ce qui est une forme de violence - par un mode 
d’expression strictement masculin. Ce n’est pas ton ressenti, tu n’as aucun 
avis valide possible sur le sujet.
Et si tu crois en avoir un tu te trompes.

Tout le reste n’est qu’esquive et faux débat

--
Cédric
Le 5 août 2020 à 12:27 +0200, RealET , a écrit :
> Merveilleux !
> Merci d'illustrer ce que j'écrivais sur IRC à l'instant (11:35:46) :
> « Et les valeurs d'accueil de SPIP devraient me permettre de débattre en
> exprimant des arguments non majoritaires (dans ceux qui s'expriment,
> parce que certains se taisent aussi) »
>
> Et ça me fait bien rire quand je réalise que les féministes revendiquent
> pour les femmes d'être égales aux aux hommes, mais que le cerveau d'un
> homme (égal à celui d'une femme donc), ne lui permet pas d'avoir le
> droit de réfléchir sur le sujet et d'en débattre.
>
> J'ose croire que le débat (dans le respect des sensibilités
> personnelles) restera possible.
>
> --
> RealET
>
>
> Cerdic a écrit le 05/08/2020 à 12:12 :
> > La bonne nouvelle c’est qu’en tant qu’homme et partie de la classe
> > dominante, on en a strictement rien à faire de ton avis (et pas plus du
> > mien).
> > Il y a unanimité des femmes présentes sur la liste sur le sujet, donc
> > aucun débat.
> >
> > Si tu as pas envie de respecter les règles de discussions ici qui
> > incluent de faire attention à toutes et tous et prendre en compte les
> > demandes des personnes qui expriment un besoin dans ce sens, le mieux
> > est d’arrêter de parler.
> >
> > Bonne journée
> >
> > --
> > Cédric
> > Le 5 août 2020 à 12:03 +0200, RealET , a écrit :
> > >
> > > Ce qui me semble pouvoir être contre productif, c'est justement
> > > d'introduire une distinction de genre, de mettre le projecteur sur le
> > > sexe des personnes.
> >
>
>
>
>
> ___
> 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] Écriture inclusive

2020-08-05 Par sujet Cerdic
La bonne nouvelle c’est qu’en tant qu’homme et partie de la classe dominante, 
on en a strictement rien à faire de ton avis (et pas plus du mien).
Il y a unanimité des femmes présentes sur la liste sur le sujet, donc aucun 
débat.

Si tu as pas envie de respecter les règles de discussions ici qui incluent de 
faire attention à toutes et tous et prendre en compte les demandes des 
personnes qui expriment un besoin dans ce sens, le mieux est d’arrêter de 
parler.

Bonne journée

--
Cédric
Le 5 août 2020 à 12:03 +0200, RealET , a écrit :
>
> Ce qui me semble pouvoir être contre productif, c'est justement
> d'introduire une distinction de genre, de mettre le projecteur sur le
> sexe des personnes.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2020-07-28 Par sujet Cerdic
Hello,

pour répondre "oui et non" parce que la vie c’est pas simple :)

Pour le Oui :

1/ il y a dans offline déjà tout le mécanisme dont tu parle dans 
https://git.nursit.net/open/offline/-/blob/master/action/api_offline.php :

• l’api avec routeur vers des methodes extensibles
• le builder de l’installeur, du service worker
• la gestion de l’installation, la désinstallation via 
https://git.nursit.net/open/offline/-/blob/master/offline_pipelines.php

2/ il suffirait donc de l’extraire en le prefixant de manière plus générique en 
offrant des pipelines pour construire la liste des JS a inclure dans le build 
(mais il faut construire une liste de JS ET une liste d’arguments à passer, qui 
seront ajoutés sous forme de tableau de config js)

3/ il manque un mécanisme d’auto-destruction du service worker
C’est fil qui me l’avait suggéré, et au retour d’expérience ça semble 
totalement indispensable : quand on envoie un service worker chez le navigateur 
client, il s’installe et a sa propre vie, autonome. Si on envoie un bug, 
notamment autour de la mise à jour, c’est mort : le service worker ne se mettra 
jamais à jour, le client est planté à jamais, sauf à faire un shift+reload, ce 
qu’un•e utilisateur•ice normal•e ne fera jamais.

La bonne parade c’est donc que le service worker soit toujours envoyé avec une 
date de péremption, éventuellement configurable. Cela l’oblige à se mettre à 
jour tous les X jours, mais cela garanti aussi qu’en cas de gros bug les effets 
indésirables ne dureront pas plus longtemps

Pour le Non :

1/ de ce que j’ai vu dans l’utilisation des services workers c’est que c’est 
vraiment pas simple à faire marcher de façon fiable, super compliqué à débuguer 
vu que tout se passe dans les navigateurs clients, avec toute leur diversité, 
et qu’on a aucune info en feedback (à part quelqu’un•e qui va dire « ça marche 
pas » ou «  je tombe tout le temps sur la page 404 », sans moyen de savoir ce 
qu’il y a de stocké dans son navigateur)

2/ de là je suis très frileux à voir plusieurs plugins ajouter leur JS et vogue 
la galère en espérant que tout marche bien à l’aveugle alors que déjà tu as du 
mal à faire marcher le truc correctement en maitrisant tout le code (autant 
croire au miracle)

3/ je trouve que ces plugins qui reposent sur un plugin qui doivent installer 
un plugin… etc pour s’installer c’est bien lourd. J’ai encore un peu en travers 
de la gorge le mini-calendrier extrait du plugin agenda « parce que bon c’est 
générique et d’autres en auront besoin » qui pourrit la vie des 
utilisateur•ices du plugin agenda depuis à peu près 14 ans sans que jamais 
aucun autre plugin n’ait utilisé ce fameux mini-calendrier

4/ je sais pas trop comment proposer une solution propre de partage


En conclusion j’ai envie de dire : avant de faire un plan à 20 ans pour que 
tout puisse s’assembler dans un monde idéal, et alors qu’on a pas de retour 
d’expérience sur le sujet, avançons donc sur les différents sujets en 
parallèle, et quand on comprendra tout comment ça marche bien, on aura sans 
doute une idée plus claire de ce qu’il faut mutualiser, ce qu’il faut séparer 
etc...

(et peut-être que d’ici là on aura avancé sur l’utilisation de composer ?)

--
Cédric
Le 25 juil. 2020 à 11:02 +0200, RastaPopoulos , a écrit 
:
>
> Après une semaine de diverses recherches, voici où j'en suis. Celleux qui 
> s'intéressent à la question (notamment Cédric car Offline), merci de me dire 
> ce que vous en pensez. :)
>
> Rappel : une PWA, ce n'est pas une fonctionnalité précise, mais un ensemble 
> de fonctionnalités JS qui augmentent les capacités d'un site web pour lui 
> permettre des choses que seules les applis natives pouvaient faire avant. Et 
> comme son nom l'indique : ça peut être progressif, on peut ajouter petit à 
> petit des choses. Ça peut être :
> - garder en mémoire des pages pour lire même déconnecté
> - synchroniser des données régulièrement
> - s'inscrire à des notifications push (qui arrivent donc même quand on n'a 
> pas ouvert le site)
>
> Point important 1 : on peut vouloir *une seule ou plusieurs* de ces 
> fonctionnalités. C'est forcément modulaire, ya aucune obligation d'avoir tout.
>
> Cependant elles utilisent un truc commun : un service worker, un programme JS 
> qui tourne chez la personne en parallèle du site.
>
> Point important 2 : il ne peut y avoir QU'UN service worker pour une même 
> "branche" de l'arbo des URL. Et par défaut la portée est celle du dossier/URL 
> où se trouve le fichier JS. Par exemple s'il est dans 
> exemple.com/javascript/sw.js alors par défaut il ne pourrait servir que pour 
> les requêtes sous exemple.com/javascript/… Si le fichier est à la racine du 
> site, alors la portée par défaut est "tout le site".
>
> Le plugin Offline de Nursit, fait pour le Diplo et utilisé en test grandeur 
> nature sur Contrib, ajoute la fonctionnalité "lecture hors ligne" :
> https://git.nursit.net/open/offline
> (au passage maintenant qu'on a git, est-ce qu'il pourrait 

  1   2   3   4   >