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

2021-05-08 Par sujet Matthieu Marcillaud

Le 08/05/2021 à 17:57, RastaPopoulos a écrit :

Le 08/05/2021 à 15:11, Eric Lupinacci a écrit :

Des avis ou des idées ?


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

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


Et qui dire de la comparaison spip_version_compare('3.0.7', '3.0.*', '=')

?

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


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

2021-05-07 Par sujet Matthieu Marcillaud

Le 07/05/2021 à 19:41, Bruno Bergot a écrit :

Hop,

Le 07/05/2021 à 19:36, tcharlss a écrit :

Juste prefixe.svg c'est garanti qu'à un moment ça va collisionner.



Claro, newsletter.svg/png à la racine d'un dossier squelettes et paf !



J'aimerais comprendre le "et paf".

Le logo du plugin a priori sera utilisé uniquement dans SVP/SPIP sur la 
page de liste des plugins, et charger avec `_DIR_PLUGIN_XX . {le nom 
choisi}.svg`. Pas de surcharge ici possible. (J'ai pas vérifié)


Une personne qui mettrait un squelettes/home.svg le chargeant avec 
#CHEMIN{...} ou que sais-je, ce fichier serait prioritaire dans le path. 
Donc ça n'utiliserait pas non plus celui du plugin.


Alors donc je présume que c'est possiblement bon comme ça.

Par contre… si une page veut réutiliser différents logo de plugins en 
s'appuyant uniquement sur le prefixe, et ferait #CHEMIN{$prefixe.svg} 
alors là il y aurait probablement problème.


Mais je suis aussi d'accord pour ne pas utiliser directement 
{prefixe}.svg qui me parait un peu trop simple, a première vue...


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

[spip-dev] Les listes de diffusion évoluent. La liste spip-dev en premier. (Mailman -> Discourse)

2021-05-07 Par sujet Matthieu Marcillaud


Bonjour,

Vous l'avez aperçu ces derniers jours, les listes de discussions de 
rezo.net dont SPIP fait partie, vont être migrées au fil des jours de 
la plateforme Mailman à la plateforme Discourse.Â


Il devenait très difficile pour Fil de maintenir Mailman. Discourse 
estdoncla solution de migration qui a été retenue et appliquée avec 
brio par Loïc après un audit de différents outils de remplacement.


La liste spip-dev est la première testée ; elle a essuyé quelques 
petits plâtres de migration, en réveillant à tort de vieux comptes, 
mais c'est désormais réparé. Dimanche 9 mai, la liste basculera 
définitivement sur Discourse. Pour le moment le site se trouve à l'url 
https://discuter.spip.netÂ


En tant que personne inscrite à spip-dev, vous n'avez rien à faire, 
sinon vous y connecter en redemandant un nouveau mot de passe, et 
éventuellement en configurant un pseudo ou un nom sur votre compte. 
Vous pouvez aussiydéfinir différentes préférences concernantla 
réception des mails. Par défaut, votre compte "surveille" la 
catégorie "spip-dev" à laquelle vous êtes abonné, et donc,vous 
recevrez des mails sur les sujets et réponses des participant·es.Â


Vous pouvez répondre par email au messages également comme avant. 
Enfin, vous pouvez toujours envoyer de nouveaux messages à 
spip-dev@rezo.net .


Il va y avoir une petite phase de rodage à la fois pour les 
administratrices ou administrateurs, mais également pour les 
utilisateurs et utilisatrices, sur l'usage du Discourse. Cet outil est 
avant tout un forum, et par conséquent il y a la possibilité de 
modérer, déplacer des messages, renommer des sujets pour les 
préciser, etc...


Une fois la liste spip-dev testée et stabilisée, les autres listes 
SPIP migreront aussi de la même façon.


## Une note sur discuter.spip.net

Nous avons choisi le terme "discuter" au moins pour le moment, car il 
permet de regrouper plusieurs usages possiblesdu site, notamment les 
listes de discussionsetd'entraideetleforum... Et aussi parce que "forum" 
est déjà pris et qu'on ne voulait pas perturber encore plus les gens.


## Une note sur forum.spip.net

Vous le comprenez, Discourse étant un forum, la question se pose de la 
maintenance ensuite du site forum.spip.net : pour le moment il est 
laissé tel quel (accès lecture / écriture), mais a-priori, ses 
fonctionnalités sont totalement intégrées dans Discourse qui le 
remplacera. Peut être qu'une personne dévouée migrera les contenus et 
catégories dans Discuter (ça serait l'idéal) ; mais plus probablement 
au moins dans un premier temps, le site sera désactivé (paramétré en 
lecture seule). Mais ce n'est pas encore pour tout de suite.


## Une note sur les newsgroup (gmane / nntp)

Pour les personnes qui utilisaient les listes depuis les newsgroup, nous 
avons le regret de signaler que ça ne fonctionnera plus. C'est un peu 
triste, mais il n'y a pas de solution pour les rétablir. On espère que 
la présence d'un site web pour discuter avec une recherche intégrée, 
et la diffusion par email suffira à atténuer ce désagrément.


## Pour conclure�

Voilà. On espère que ces changements vous apporteront satisfaction.�
Ce n'est pas les seules choses qui évoluent chez SPIP en ce moment 
(notamment du côté des alpes, une migration des tickets de Redmine à 
Gitea se profile !) , et c'est un plaisir de voir toute cette effervescence.


L'équipe 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] Logos SVP

2021-05-06 Par sujet Matthieu Marcillaud

Je disais (c'était pas passé sur la liste !)

Le 06/05/2021 à 17:54, erational a écrit :
> spip-contrib-extensions/svp_api
> Détails : 
https://git.spip.net/spip-contrib-extensions/svp_api/commit/7affd39f7f8a351dbae39f886ec5e5b9ef012e21


Sur les icones de SVP… je voyais et vois un grand L ; et avant qu'on me 
dise que c'était un·e majordome, un·e serveur·se , je supposais que 
c'était un sorte de bureau d'ordinateur (genre console…) …


Alors je pense que l'icone est peut être pas assez suggestive. 1) y a 
pas de forme de bonhomme (juste un trait vertical), et 2) la main est 
quasi invisible.


Je proposerais bien, tout en conservant donc l'idée d'apporter des 
plugins, de simplifier pour ne conserver que la main, la manche et le 
plateau, un peu comme sur :


- https://www.flaticon.com/premium-icon/drinks_4130409
- ou https://www.flaticon.com/free-icon/waiter_1378849

Évidemment en changeant le contenu sur le plateau par les icones des 
différents plugins de SVP, notamment la prise, comme il y avait


Un avis Eric, erational ou autre ?

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

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

2021-05-06 Par sujet Matthieu Marcillaud

Le 06/05/2021 à 12:36, erational a écrit :

OK je m'en charge sur les prochains plugins.

c'est possible de le noter quelque part dans la doc svp  ?



Le 06/05/2021 à 12:31, Eric Lupinacci a écrit :

Je renouvelle ma demande de passer les logos à la racine du plugin svp.


Oui, je serais favorable… mais.

Ça marche la compat png-svg (3.2 - 4.0) si c'est pas dans prive/theme/ ?

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

Re: [spip-dev] spip-loader.php

2021-05-04 Par sujet Matthieu Marcillaud

Le 04/05/2021 à 09:40, team spipfactoy a écrit :

le soucis  rencontrer est que spip-loader affiche spip 4.0, cela prête a 
confusion , il s'attend a voir spip 4.0.Alpha


Oui je m'étais posé aussi la question, mais en fait ça affiche la 
branche dans le sélecteur. *Mais* en cliquant ensuite, tu as bien SPIP 
4.0.0-alpha qui s'affiche en gras à côté !


Donc je pense que ça ira très bien comme ça.

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


Re: [spip-dev] SPIP 4

2021-05-03 Par sujet Matthieu Marcillaud

Le 03/05/2021 à 16:06, Pierre-Jean Colliot a écrit :


Bonjour,

Je rebondis sur ce sujet car il met le doigt sur un point auquel je 
pense depuis quelques années et qui a modifié mes pratiques avec 
l'abandon des articles au profit de l'objet rubrique sur la quarantaine 
de sites que je gère.


C'est une idée qui a déjà eu des discussions, il y a peut être un ticket 
là dessus pour avoir des articles hiérarchisés, où un article peut être 
le descendant d'un autre. Je crois que ça s'est arrêté à des discussions 
et qu'il n'y a pas eu de Proof of concept en plugin.


Donc non : pour SPIP 4, c'est mort clairement ! On est à stabiliser / 
terminer toutes les modifs qu'en rajouter d'autres… Surtout une énorme 
comme celle là.


Il faut d'abord tester ce genre de choses en plugin. Et quid de la 
migration de la BDD et des squelettes ? Ça ouvre un champ de questions 
assez immense :)


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

Re: [spip-dev] alpha 4.0.0 => rétropédalage

2021-05-03 Par sujet Matthieu Marcillaud

Le 03/05/2021 à 09:48, team spipfactoy a écrit :

Bonjour, pour info

week-end studieux mais inefficace pour moi


L'expérience  spip 4.0.0  Alpha est OFF


Si tu ne sais pas ce que tu fais. Ne le fait pas. Simplement.

Et attends une version finale. Et pas un truc encore en dev.
On n'a même pas encore publié l'annonce de la sortie de l'alpha !

Zut. Tu envoies plein de mails indéchiffrables sur la liste spip-dev 
alors que c'est du ressort de spip-user (que tu pourrais envoyer en 
format texte par ailleurs plutôt que html ! ça serait bien plus lisible).


Depuis le temps, tu pourrais comprendre que : oui, les plugins ne sont 
*pas* encore déclarés compatible SPIP 4.0.0-alpha (c'est en cours, ça va 
se faire tranquillement). C'est ce qui tue ta mutu.


Donc merci de ne pas plomber l'ambiance.
Nous, on a la hype :)

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


Re: [spip-dev] BigUp est SPIP 3.2

2021-05-03 Par sujet Matthieu Marcillaud

Le 03/05/2021 à 08:16, RealET a écrit :

Est-ce qu'il serait possible de refaire la branche v1 à partir du 
dernier commit encore compatible :
https://git.spip.net/spip/bigup/commit/fd04b6e40a8c6f320cab8afc2618084914cb7afc 


Ça serait pas le commit avant l'introduction du .svg plutôt pour 3.2 ?

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


[spip-dev] Point sur l'aide en ligne intégrée

2021-05-02 Par sujet Matthieu Marcillaud

>> Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :
>>> Aide

[...]

> On va a priori intégrer cette proposition (en fr uniquement pour
> l'instant) dans l'alpha 4.0… histoire que les gens puissent tester et
> faire des retours.


(désolé c'est un peu en vrac)

Un point sur ça : la version 4.0.0-alpha a donc cette première version 
d'une aide en ligne intégrée à SPIP, dont le contenu est puisé dans des 
fichiers inclus du plugin Aide. Le contenu des fichiers peut donc suivre 
la version de SPIP associée au plugin. Un pipeline "aide_index" permet 
de compléter la liste des pages d'aides (et donc des plugins peuvent 
ajouter du contenu dedans)


Langues intégrées
-

J'ai juste intégré les langues [fr] et [en], en copiant / collant en 
gros le textes des articles d'aides de spip.net et en le découpant en 
différentes parties. C'est une première approximation qui sera 
certainement à améliorer.


Il faudra donc réintégrer les autres langues sur le même principe.


Réécritures & traductions
-

À mon avis, certains textes pourraient être réécris dedans. Aussi les 
extraits de code dans l'aide devraient être écrits avec  
plutôt que  actuellement, mais c'est à faire (vu que  ne 
fait pas ça tout seul).



Cependant il va être un peu plus difficile de suivre tout ça pour les 
personnes traductrices : vu que ça ne passe ni par traduire.spip.net, ni 
par un article SPIP standard, mais un fichier 
"aide/[lang]/raccourcis/lien.spip". Ceci dit le résultat est directement 
visible dans les pages ?exec=aide=raccourcis ce qui est moindre mal.



Enfin j'ai ajouté un "Résumé" des raccourcis typo les plus courants, 
avant le reste de l'aide. Il pourrait être amélioré aussi. Je trouve ça 
beaucoup plus succinct et parlant. Je n'ai pas traduit ce résumé en [en] 
par contre.



Groupes d'aide
--

Afin de rendre l'aide extensible, on a considéré les aides en terme de 
groupes. Seul actuellement le groupe des "Raccourcis typographiques" est 
présent. Il contient différentes entrées et peut contenir (c'est même 
conseillé) une introduction (un fichier "aide/[lang]/[groupe]/_intro.spip")


Il peut donc y avoir d'autres groupes d'aide. On pourrait remettre 
certaines parties : par exemple la description des articles virtuels ou 
des dates de publication, si c'est souhaitable / souhaité... dans un 
groupe "article" par exemple…


La page ?exec=aide de l'espace privé liste l'ensemble des groupes d'aide 
avec leur texte introductif.



Technique
-

- #AIDER{raccourcis} met l'icone et le lien pour charger le groupe 
d'aide des raccourcis typographiques.

- aide_generer_url('raccourcis') génère aussi l'url (en php).


Images
--

La question se pose si une aide souhaite présenter des images. Pour le 
moment on botte en touche.


Il y a plusieurs questionnement et/ou inconvénients aux images :

a) c'est plus difficile à maintenir (il faut refaire les capture d'écran 
régulièrement)
b) est-ce que les images sont "traduites" ? (et donc dupliquées pour 
chaque langue ou pas)
c) ça peut prendre un poids non négligeable dans le plugin, et donc sur 
l'hébergement

d) comment lier l'image au texte d'article d'aide ?

Pour le dernier point d), la solution d'un modèle (intégré au plugin 
d'aide) serait peut être le plus simple. On ne peut pas utiliser  
où XX est un document. Mais on pourrait avoir 
 qui chercherait 
"aide/[lang]/raccourcis/lien.svg". L'image serait cherchée en suivant le 
même chemin de fallback de langue que les traductions. Si l'image 
"aide/en/raccourcis/lien.svg" n'existe pas, on prendrait 
"aide/fr/raccourcis/lien.svg"...


Ça pourrait résoudre b) comme ça. Par contre b) avec traductions d'image 
n'est pas hyper compatible avec a) …


À voir.

Voilou.

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

Re: [spip-dev] Undefined array key "vars" in composer.php(95) : eval()'d code

2021-05-02 Par sujet Matthieu Marcillaud

Le 02/05/2021 à 22:27, Luis Speciale a écrit :
Quelqu’un pourrait me suggérer une piste pour résoudre ce problème 
aléatoire mais  persistant surtout depuis passage en 4.


J'ai cherché au niveau de composer et il me semble que ça doit être un 
squelette


Warning
: Undefined array key "vars" in
/usr/local/var/www/spip/ecrire/public/composer.php(95) : eval()'d code
on line
45


Il faut que tu trouves le squelettes, mais c'est un #GET{truc} qui est 
fait alors que #SET{truc, ...} n'est pas appelé auparavant.


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

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

2021-05-02 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 10:03, jeanmarie a écrit :


*Compagnon*


[...]

Comme évoqué par d'autres dans la discussion, ajouter la possibilité de 
le désactiver pour soi et


Au fait, sur cette 4.0.0-alpha, c'est fait : sur le message (de 
compagnon) de bienvenue de l'accueil, un bouton permet de désactiver le 
compagnon pour soi.


, tant qu'à y être, pour tout le monde si ça

mange pas de pain serait super.


Ça c'était déjà disponible dans la configuration du compagnon !


Aussi, rendre les boutons qui ferment les boites d'infos (Merci / J’ai 
compris ! / Parfait...) pourraient être plus explicites (avec une croix 
pour ? des styles plus boutons ? ...) pour que les gens les ferment (la 
plupart de mes utilisateur·rices reste avec pendant des mois avant que 
je leur dise qu'ils sont désactivables. > ça mérite un ticket ça ?


Ça aussi c'est fait sur la 4.0.0-alpha : il y a une croix en haut à 
droite visible sur chaque boite du compagnon.


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

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

2021-05-01 Par sujet Matthieu Marcillaud

Le 01/05/2021 à 02:37, Matthieu Marcillaud a écrit :

Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :


Aide


Il semble qu'il faut conserver le plugin au moins pour pouvoir gérer 
l'aide des raccourcis typographique 


[...]

Pour une première proposition en fichiers...

https://git.spip.net/spip/aide/pulls/2


On va a priori intégrer cette proposition (en fr uniquement pour 
l'instant) dans l'alpha 4.0… histoire que les gens puissent tester et 
faire des retours.


+ cacher le lien "aide" du bandeau qui ne mène à rien avec cette 
proposition pour le moment mais "plus tard peut être, un jour, lointain" 
pourrait revenir et amener sur une url externe tel que rediger.spip.net 
par exemple.


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

Re: [spip-dev] Et l'écran de connexion…

2021-05-01 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 19:15, a...@rezo.net a écrit :

Au fait, je l’avais pas encore vu parce que j’utilise généralement mon 
plugin «Écran de connexion», mais avec la magnifique interface d’espace 
privé que vous nous avez connecté,*l’écran d’identification à l’espace 
privé, il fait carrément tâche*… :-))


[...]

Alors j’ose pas trop toucher moi-même, mais j’aimerais bien qu’on 
modernise cet écran de connexion, éventuellement en s’inspirant de ce 
que j’ai fait pour «Écran de connexion» 


La présentation est très sympa, mais ça nécessite une image de fond non 
? Ou faudrait mettre un léger dégradé ou dégradé circulaire si pas 
d'image (et où prendre l'image sinon ?)


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

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

2021-04-30 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :


Aide


Il semble qu'il faut conserver le plugin au moins pour pouvoir gérer 
l'aide des raccourcis typographique 


[...]

Pour une première proposition en fichiers...

https://git.spip.net/spip/aide/pulls/2

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


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

2021-04-30 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :

[...]

Aide


[...]
Une proposition serait d'intégrer cette documentation d'aide directement 
dans le plugin. 


Ah oui, au fait, il y avait eu 
https://blog.smellup.net/spip.php?rubrique11 qui parlait de l'aide.


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


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

2021-04-30 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 19:04, Bruno Bergot a écrit :
[...]

J'arrive un peu tard, mais je suis pour le retrait de toute la liste 
proposée.


J'ai enlevé donc les plugins qui n'étaient pas discutés.

Il reste les cas donc de :

- squelettes par rubriques
- aide
- compagnon

Je vais tacher de faire un résumé de différentes discussions rapidement 
à leur sujet.



Squelettes par rubriques


Il est pratique, notamment simple pour débuter.

Contrairement à Composition, il fait une recherche sur toutes les 
inclusions pour vérifier s'il existe un =12.html ou -12.html ou .en.html 
et en remontant aussi la hiérarchie de rubriques le cas échéant. Le fait 
que ça s'applique sur toutes les inclusions est gourmand. Compositions 
ne le fait que sur certains blocs (notamment ceux déclarés à z-core).


Effectivement les 2 plugins n'ont pas exactement les mêmes 
caractéristiques (Compositions est visible dans l'espace privé par exemple)


Je pense qu'on peut proposer "squelettes par rubriques" uniquement en 
plugin et l'enlever des plugins-dist. La fonctionnalité ne disparait 
pas, et peut être réactivée donc facilement au besoin.



Compagnon
-

Il est mignon, mais il gène les utilisateurs aguerris. Certaines 
personnes ne voient pas que les messages peuvent se fermer.


J'ai amélioré l'UI des boites de compagnon pour mieux voir que ça se 
ferme. Ce point est réglé.


On peut peut être ajouter un bouton supplémentaire sur le message de 
bienvenue d'un auteur sur l'accueil (et celui-ci seulement) qui dit en 
gros (formulation sympa à trouver) "Je connais SPIP ! (ne plus 
m'afficher le compagnon nulle part)"



Aide


Il semble qu'il faut conserver le plugin au moins pour pouvoir gérer 
l'aide des raccourcis typographique ; potentiellement uniquement 
ceux-là. Mais ça veut dire qu'il faut… revoir le plugin pour que ça soit 
à jour. (je dirais : gasp ! faut un peu de temps quoi !)


Une proposition serait d'intégrer cette documentation d'aide directement 
dans le plugin. Ça ne facilite pas les traductions : car ce serait des 
fichiers (en chaîne de langue c'est trop difficile à gérer vu la 
longueur des textes).


Par exemple dans un répertoire : aide/fr_FR/raccourcis_liens.spip (ou 
.md j'y reviens après)


Il y aurait une déclaration explicite de "groupe" d'aide, et d'entrées, 
qui passerait par un pipeline. Par exemple (très rapide, juste pour l'idée)


$liste = [
'raccourcis' => [
'titre' => _T('aide:groupe_raccourcis_typo'),
'entrees' => [
'liens' => [
'titre' 
=>_T('aide:groupe_raccourcis_typo_liens'),
'fichier' => 'raccourcis_liens.spip'
]
]
];

L'exemple à l'inconvénient de devoir déclarer les titres et l'ordre (des 
groupes, des entrées), mais c'est probablement plus simple et clair que 
de l'extraire des fichiers automatiquement.


Les aides éventuelles, appelleraient par exemple #AIDER{raccourcis} (le 
nom du groupe), qui ouvrirait la modale (comme actuellement) avec en 
colonne le titre de chaque entrée (mais uniquement de ce groupe 
'raccourcis'), en en contenu le texte de chaque entrée (pris dans les 
fichiers .spip).


En tout cas c'est une piste possible.

Le lien "aide" du bandeau, pourrait ouvrir un menu avec tous les groupes 
déclarés (si tel est le cas), ou disparaitre...


C'est des réflexions live… désolé.

J'y pensais hier, mais Arno m'a devancé, la seule aide utile est il me 
semble cette des raccourcis typo du porte-plume. Et je me dis qu'on 
pourrait facilement la garder à jour et la traduire en la déportant dans 
un fichier MD inclus dans le plugin, ce qui ne bloque en rien l'envie de 
compléter ou traduire celle-ci, et en plus aurait l'avantage de 
versionner la doc en synchro avec la branche en cours.


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


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

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

2021-04-30 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 08:59, Eric Lupinacci a écrit :



Le ven. 30 avr. 2021 à 08:50, Arnaud Martin > a écrit :



Concernant l’aide, en fait il y a *une* seule page qui est
franchement utile: la page des «raccourcis typographiques». Parce
que même après 20 ans à faire du SPIP quotidiennement, je connais
pas les fusions de cases des tableaux, ni les appels de notes de bas
de page.


Oui, entièrement d'accord : l'aide c'est surtout utile pour les 
raccourcis typo. Il y a plein de subtilités / possibilités facilement 
oubliées.


Si la présentation actuelle de la popin d'aide est conservée, le menu de 
gauche pourrait contenir (à la place de l'actuel) les différentes 
parties des raccourcis typo (paragraphes, liens, notes, tableaux, ...) 
(des ancres vers le bon endroit du contenu central), ce qui serait un 
rien plus simple pour s'y retrouver déjà.




On pourrait quasiment virer l’aide mais ne conserver qu’un lien vers
les raccourcis. (Actuellement, à côté de «Texte», on a une aide
contextuelle qui dit «Le texte de l’article […] comme son nom
l’indique». Et la plupart des entrées sont à l’avenant. Sauf… la
page des raccourcis typographiques donc…

Ou alors faire comme pour Saisies et sa page d'explication accessible 
via un menu.


Mouais : y a déjà un lien "aide" dans le bandeau. Et ça irait dans quel 
menu ? (en statut rédacteur)


Là on aurait juste une page qui rappelle les raccourcis et qui serait 
accessible par le ?.


Alors… je me demandais si le bouton [?] n'était présent qu'en tant 
qu'icone du porte plume (et plus ailleurs), si ça serait suffisant ?


On pourrait même imaginer que certains plugins qui ajoutent des 
raccourcis puissent s'y insérer pour lister les leurs.


Certes. Enfin encore une fois il faut gérer les traductions également.
Ça peut être dans les fichiers de langue des plugins aussi.
Et si tu veux lier des images ou montrer le résultat du code, c'est plus 
difficile je suppose en chaine de langue.


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

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

2021-04-29 Par sujet Matthieu Marcillaud

Le 29/04/2021 à 17:31, jacq...@jack31.org a écrit :

Le 29/04/2021 à 17:07, Matthieu Marcillaud a écrit :

À débattre
==



Bonjour,
J'ai un doute sur le retrait de ces deux plugins d'aide :
- Perso le compagnon m'agace et s'il y avait un bouton pour le 
désactiver entièrement par auteur j'aimerais bien...


C'est une piste à étudier pour Compagnon, probablement pas trop complexe 
à mettre en place. Mais faut trouver l'UI qui va avec.


[...]

- Aide : livrer SPIP sans aide pour les rédacteurs c'est un peu dommage. 
Mais c'est vrai qu'aujourd'hui c'est plutôt obsolète, il y a peu de 
choses utilisables. Est-ce que ce serait imaginable que le plugin aille 
chercher une aide uniquement rédacteur basée sur des articles de 
spip.net qu'on identifierait par exemple avec un mot clé SPIP_4.0 ? ou 
une sélection d'articles listée quelque part ? L'idée serait d'en faire 
une aide vraiment utile avec les "trucs et astuces" utiles au rédacteur


Alors… Je n'ai aucune idée de comment ça pourrait se faire (sans 
douleur, énergie, temps disponible). Mais jusqu'à présent tout le monde 
a renoncé parce que c'était trop compliqué (conserver l'aide pour les 
anciens SPIP, les traductions, faire des aides adaptées à la version...) 
Tellement que bah… ça a fait statut quo — on touche rien, on attend la 
providence.


Pour ma part, si le lien "Aide" du bandeau amenait par exemple à un site 
externe, ça pourrait peut être convenir : et ça permettrait d'enlever 
tous (ou partie) des [?] assez disgracieux (en tout cas sur la page 
article, il y en a beaucoup trop je pense)


Mais même pour un site externe (tel que rediger.spip.net par exemple) 
bah il faut du temps, de l'énergie, de la volonté pour mettre ça en place.


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



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

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

2021-04-29 Par sujet Matthieu Marcillaud

Bonjour,

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


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




Déjà retiré
===

JQuery UI
-

Déjà avant tout soulignons que nous avons déjà enlevé "jquery-ui" des 
plugins-dist car cette librairie javascript n'est plus maintenue, et 
nous avons ajouté les alternatives JS (un "picker" de date et un 
"sortable") dans le core pour les utilisations principales qu'il y avait.


Pour d'autres plugins (Fabrique, Saisies, Albums, Rangs, ...), dans une 
premier temps il suffit d'ajouter un necessite à jquery-ui et de le 
réactiver en plugin. Dans un second temps, la communauté adaptera les 
plugins avec du nouveau code.




Pas d'objection ?
=


Vertèbres
-

Un outil de visualisation des tables SQL de SPIP. Ce plugin n'a 
pratiquement pas bougé depuis sa sortie. Il est avantageusement 
remplaçable par le plugin "Adminer".



Organiseur
--

Il contient l'agenda interne, la possibilité de messages entre auteurs 
et de pense-bête. Très pratique a une époque assez lointaine, un peu 
moins maintenant avec des agendas et outils de discussion sur tous les 
téléphones !


Il n'est a priori quasiment jamais utilisé sur les sites maintenant.

Les plugins comme Agenda ou Manuel du site sont parfois selon le besoin 
aussi une alternative.



Brèves
--

De courts éléments éditoriaux sans auteur.


Squelettes par rubriques


Ça permet de faire des squelettes tel que "article=3.html". Gourmands en 
performance pour retrouver ces squelettes, on préfère utiliser 
maintenant d'autres méthodes, notamment avec le plugin Compositions.



Pétitions
-

Permet de créer des pétitions. On reproche souvent au plugin de manquer 
de champs, de ne pas être adapté à ceci ou cela. Personne n'a pris le 
temps pour l'améliorer récemment.





À débattre
==


Compagnon ?
-

Là c'est plus subjectif et plus fortement sujet à discussion. Le 
compagnon offre des infos aux nouveaux visiteurs. Il était fait pour 
avoir un accueil plus agréable lors des premières installations.



Aide ?


Là encore plutôt sujet à discussion. Ce plugin ajoute les icones [?] à 
différents endroits de l'espace privé. Mais cette aide n'est plus à jour 
et est la même pour toutes les versions de SPIP. Quand elle n'est pas 
obsolète.




Des avis par ici ?

Bien à vous,
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

Re: [spip-dev] [spip ↪ boutons-danger] .danger sur réinstallation de la base

2021-04-22 Par sujet Matthieu Marcillaud

Salut Arno*

Welcome on git :)

Tu n'as peut être pas fait attention, mais il y a une plugin "dev" un 
peu caché https://git.spip.net/spip/dev/ qui propose une page 
?exec=charte avec quelques éléments dedans

(notamment à jour dans la branche dev/css_refacto_form ou qqc comme ça)

Dedans tu peux voir que y a un .btn_danger qui existe sur les boutons.
Je présume que c'est ce que tu cherchais à utiliser.

Certes par contre il faut le restyler avec un nouveau design, comme tu 
as fait avec les variables CSS là, plutôt que la hachure actuelle.


Il y a peut être d'autres variantes à faire pour les boutons, mais au 
moins préfixes de .btn_ si tel est le cas.


Merci d'être passé par une branche déjà avant :)

MM.



Le 22/04/2021 à 14:52, ARNO* a écrit :

spip/spip
-
Par ARNO*, le 22 avril 2021 à 14h43min :

.danger sur réinstallation de la base


*Modifié*
 prive/squelettes/contenu/admin_tech.html

Détails : 
https://git.spip.net/spip/spip/commit/8ff1233de03279cc5a9b171b2e4db5f44ffb3788



___
liste: https://listes.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 ↪ boutons-danger] .danger sur réinstallation de la base

2021-04-22 Par sujet Matthieu Marcillaud

Salut Arno*

Welcome on git :)

Tu n'as peut être pas fait attention, mais il y a une plugin "dev" un 
peu caché https://git.spip.net/spip/dev/ qui propose une page 
?exec=charte avec quelques éléments dedans

(notamment à jour dans la branche dev/css_refacto_form ou qqc comme ça)

Dedans tu peux voir que y a un .btn_danger qui existe sur les boutons.
Je présume que c'est ce que tu cherchais à utiliser.

Certes par contre il faut le restyler avec un nouveau design, comme tu 
as fait avec les variables CSS là, plutôt que la hachure actuelle.


Il y a peut être d'autres variantes à faire pour les boutons, mais au 
moins préfixes de .btn_ si tel est le cas.


Merci d'être passé par une branche déjà avant :)

MM.



Le 22/04/2021 à 14:52, ARNO* a écrit :

spip/spip
-
Par ARNO*, le 22 avril 2021 à 14h43min :

.danger sur réinstallation de la base


*Modifié*
 prive/squelettes/contenu/admin_tech.html

Détails : 
https://git.spip.net/spip/spip/commit/8ff1233de03279cc5a9b171b2e4db5f44ffb3788




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


Re: [spip-dev] [rang] Depuis #4573 (plus de Jquery UI du Core) Rang n'est (...)

2021-04-19 Par sujet Matthieu Marcillaud

Le 19/04/2021 à 12:57, nicod_ a écrit :

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



Hummm... un peu violent ton commit :)


Oui ! Et pas juste non plus.


Il faut plutôt adapter pour SPIP 3.3 avec le nouveau sortable :


Dans un premier temps mettre un necessite sur jQuery-UI
Qu'il faut qu'on propose en zip

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


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

2021-04-18 Par sujet Matthieu Marcillaud

Le 18/04/2021 à 02:48, Gildas Cotomale a écrit :


Et c'est une très bonne chose je pense (en tout cas de faire la
coloration côté JS - quelque soit la librairie JS ensuite).


Je ne suis pas sûr de comprendre : est-ce à dire que du coup les
personnes n'ayant pas JS n'auront plus droit à la coloration de code ?


Tout à fait, et quel serait le problème ? (et qui désactive javascript 
?) La coloration syntaxique peut être considérée comme une amélioration 
progressive de la  page. Ça n'empêche pas le site de fonctionner si tu 
ne l'as pas.


Le fait de basculer en JS plutôt qu'en PHP apporte plusieurs avantages :

- c'est plus simple à gérer côté SPIP : tu retournes le code tel quel ou 
presque
- si tu veux copier / coller le code source, tu n'as pas besoin de 
refaire un hit sur le serveur pour lui demander le code source brut (non 
coloré, qu'on a du mettre en cache spécial rien que pour ça : 
https://git.spip.net/spip-contrib-extensions/coloration_code/src/branch/master/coloration_code_fonctions.php#L105). 
Le code brut, c'est déjà ce que reçoit le navigateur par défaut : sans 
JS, au moins tu peux l'exploiter directement
- tu peux proposer l'édition du code directement dans le navigateur pour 
faire des tests lives, ce qui est impossible avec la coloration 
préalable côté PHP.


PrismJS c'est la librairie utilisée sur le site MDN pour faire la 
coloration (un exmeple 
: https://developer.mozilla.org/en-US/docs/Web/CSS/animation-duration)



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

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

2021-04-17 Par sujet Matthieu Marcillaud

Le 17/04/2021 à 15:57, Brice Boucard a écrit :

Bonjour à tous,


Cool Brice, Welcome.



Comme évoqué sur IRC il y a quelques jours, je me suis amusé - c'est
vraiment le terme - à créer un plugin de coloration syntaxique
alternatif à Coloration Code, utilisant la librairie PrismJS.


Et c'est une très bonne chose je pense (en tout cas de faire la 
coloration côté JS - quelque soit la librairie JS ensuite).



Je n'étais pas très à l'aise avec Geshi et la surcharge des styles CSS
et puis je crois bien que ça ne couvrait pas mon besoin d'avoir un
prompt.


C'est quelque chose à faire de basculer un jour "coloration_code" sur 
une lib JS plutôt que de faire le calcul en PHP. Je ne trouverais pas 
cela déconnant de faire une branche de dev-prismjs sur coloration_code 
pour tester PrismJs dessus, à la place de Geshi. C'est peut être un peu 
costaux à faire, mais quand ça marche, on le passe dans master. En 
acceptant de ne pas avoir la coloration "spip" au moins dans un premier 
temps, qui sera difficile à faire.


Bien évidemment sinon
- tu peux introduire ton propre plugin sur la zone (dans 
spip-contrib-extension),

- ou sur un espace qui te convient (github ou autre)
- ou forker sur la zone coloration_code sur ton compte le temps du dév 
si tu ne souhaites pas commiter directement sur une branche du plugin)


Ces 4 propositions sont correctes.

En général on préfère ne pas multiplier les plugins qui font la même 
chose (ici de la coloration syntaxique). Ma préférence serait donc 
l'adaptation du plugin coloration code, mais c'est peut être plus 
compliqué à faire.


Voilà mes pensées :)

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


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

2021-04-15 Par sujet Matthieu Marcillaud

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

Le 15/04/2021 à 15:27, Maïeul Rouquette a écrit :


Ça patche dans le lard de partout au niveau design / ux, et ça donne une 
grande impression de pas fini.
Entre les icônes sapin de noël, les formulaires et autres bidules à 
droite à gauche sans cohérence, ça va demander du boulot pour fignoler 
tout ça vraiment proprement.


Personne n'a dit qu'on sortait une version finale de toutes façons. 
L'idée c'était quand même plus une alpha ou beta…


Quant au sapin de noel… C'est très relatif : les icones sont bien plus 
nettes qu'avant en SVG… et il y a eu quelques améliorations ça et là ; 
et tout va dans le bon sens je crois. Vu les icones d'avant, ça semble 
mieux même en l'état très imparfait. Alors certes c'est pas parfait mais 
bon.


Sur les boutons principalement, et formulaires, etc, l'idée me semble 
t'il est justement d'apporter de la cohérence, et là encore bah oui, y a 
des corrections à droites à gauches à apporter… et ça prend du temps de 
se mettre d'accord, mais là encore je trouve que ça prend une bonne 
tournure avec les variables CSS entre autres. Et il va falloir un peu de 
temps pour les utiliser partout et combler les manques.


Vous aviez réussi à me convaincre pour le nommage 4.0 … on ne sortira 
jamais de version parfaite de toutes façons. On ne sera jamais 
entièrement satisfait. Je suis quasiment sûr qu'on pourrait néanmoins 
être heureux de l'appeler 4.0 et d'arriver avant à corriger les points 
les plus dérangeant.


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

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

2021-04-15 Par sujet Matthieu Marcillaud

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

Le 15/04/2021 à 12:05, RealET a écrit :

l'utilise sur tous les sites en 3.2)


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



Heu… dans ce cas on fait une branche 3.2 s'il ne l'a pas… mais faut pas 
s'empêche de le modifier : il n'a pas à conserver l'historique des 
vieilles versions dans master.


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

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

2021-04-13 Par sujet Matthieu Marcillaud

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

Hop,


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


[...]

Plusieurs remarques. Il ne me semble pas forcément pertinent pour la 
distribution SPIP / SPIP-core (je ne parle pas des plugins ou 
librairies) de suivre semver à tout prix. Il me semble qu'on est plus 
dans une notion un peu de paradigme de programmation (le X) : le 3 
indiquant le passage aux paquet.xml pour les plugins.


Si l'on considère que dès que l'on casse potentiellement quelque chose 
dans les squelettes on se met à augmenter X plutôt que Y, on serait déjà 
très haut, quasiment à chaque grande release. Non ?


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


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

Mais.

Effectivement indépendamment des trucs qui cassent ou pas, la version à 
venir a son lot de sympathies, et même visuellement il va y avoir une 
rupture nette dans l'espace privé.


Par ailleurs, si l'on va effectivement vers un changement du rythme des 
versions SPIP en suivant l'activité de celle de PHP (et en maintenant 
quelques temps une 3.2 LTS), c'est un autre argument en faveur d'un 
changement de paradigme, et du coup d'une version 4.0


J'aurais préféré ce 4 pour du Composer. mais si c'est 5 ou 6 ça ira aussi :)

Voilà mes pensées du moment.

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


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

2021-04-13 Par sujet Matthieu Marcillaud

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

Re: [spip-dev] SPIP 3.3 nécessitera PHP 7.3 minimum.

2021-04-06 Par sujet Matthieu Marcillaud

Le 06/04/2021 à 14:39, jeanmarie a écrit :

Hello,

Le 22/03/2021 à 15:31, Matthieu Marcillaud a écrit :
SPIP 3.3 nécessitera donc compatible de PHP 7.3 à 8.0 (enfin si on la 
sort avant décembre ! )


Super ces avancées PHP :)

Est-ce que la 3.3 est déjà pleinement compatible PHP 8 même si elle 
n'est pas encore releasée ?


Pour le Core et les plugins-dist oui.
Pour une partie des plugins que j'utilise oui.

Ceci dit PHP 8 est admirablement sensible et termine en Fatale à la 
moindre incohérence en entrée de certaines fonctions. C'est bien (mieux 
que de tolérer une entrée dont le type n'est pas celui attendu), mais on 
n'est pas à l'abri de tomber sur d'autres cas comme ça a des moments, 
parce que les usages de SPIP sont très variés…


Un point à noter aussi c'est que pour ses fonctions natives, qui n'ont 
aucun argument, PHP 8 ne tolère pas d'en passer (il ne tolèrera plus non 
plus pour certaines fonctions natives de dépasser le nombre d'arguments 
prévus). C'est le cas de time() par exemple qui n'a aucun argument : 
https://www.php.net/manual/fr/function.time.php et nous avions dans 
certains squelettes : `#VAL|time` ou `#NULL|time`. PHP 8 fera une fatale 
dans ce cas car la première appele `time('')` et la seconde 
`time(null)`. Nous n'avons pas de moyen actuellement dans les squelettes 
SPIP d'appeler une fonction sans argument, autrement que de faire : 
`#EVAL{time()}`


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

Re: [spip-dev] des PHP Warning en 3.2.11 up de ce matin

2021-04-02 Par sujet Matthieu Marcillaud

Salut,

La trace peut être utile dans ce cas là, mais il semblerait que tu 
appelles typo() et/ou generer_url_ecrire() d'une manière ou d'une autre 
dans ton fichier config/mes_options.php, c'est à dire avant le 
chargement complet de SPIP (avant spip_initialisation_suite()), ce qui 
provoque des bugs.


config/mes_options.php n'est pas là pour faire des traitements (il 
arrive avant l'initialisation complète de SPIP justement pour interférer 
dessus).


Donc, merci de donner plus de contexte.

On pourrait faire par exemple dans ces fonctions un brut :
if (!defined('_PROTOCOLES_STD')) {
throw new \RuntimeError("Function called before SPIP initialisation.");
}

Ou ce genre de chose. Au moins ce serait clair :p

MM.

Le 02/04/2021 à 09:41, RealET a écrit :

Bonjour,

J'ai ceci :
PHP Warning:  Use of undefined constant _PROTOCOLES_STD - assumed 
'_PROTOCOLES_STD' (this will throw an Error in a future version of PHP) 
in /home/www/ecrire/inc/lien.php on line 105
PHP Warning:  Use of undefined constant _SPIP_ECRIRE_SCRIPT - assumed 
'_SPIP_ECRIRE_SCRIPT' (this will throw an Error in a future version of 
PHP) in /home/www/ecrire/inc/utils.php on line 2044


En PHP 7.2



___
liste: https://listes.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] [polyhierarchie] Des notices PHP en moins dans les PHP récents, mais on (...)

2021-04-02 Par sujet Matthieu Marcillaud

Le 02/04/2021 à 10:20, Eric Lupinacci a écrit :

Hello,

Oui je suis assez d'accord car si on ne le fait pas on va se trainer ce 
truc voire plus s'en souvenir.


Je suis d'accord. Cela dit hier soir, ma problématique était de tester 
le nouveau Sortable.js … pas de brancher Polyhiérarchie :p

Ce qui au final aurait peut être été plus vite… :p

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

Re: [spip-dev] Erreur de compression CSS dans le privé sur un site en 3.2.11

2021-04-01 Par sujet Matthieu Marcillaud

Le 01/04/2021 à 23:14, RealET a écrit :


il y a un ";" en trop


Reporté du coup : https://git.spip.net/spip/compresseur/commit/374fe229

Merci.

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


[spip-dev] SPIP 3.3 nécessitera PHP 7.3 minimum.

2021-03-22 Par sujet Matthieu Marcillaud

Bonjour,

Comme nous en discutions là 
https://www.mail-archive.com/spip-dev@rezo.net/msg71162.html puis là 
https://www.mail-archive.com/spip-dev@rezo.net/msg71253.html , nous 
allons tenter de modifier notre cycle de release et la version de PHP 
avec lequel SPIP  est compatible.


À partir de la version 3.3 à venir, SPIP sera compatible avec les 
versions PHP maintenues au moment de la sortie de la version SPIP (cela 
concerne les nouvelles versions majeures x.0.0 ou x.y.0 seulement).


SPIP 3.3 nécessitera donc compatible de PHP 7.3 à 8.0 (enfin si on la 
sort avant décembre ! 😁)


Concernant SPIP 3.2, nous sortirons prochainement une version qui va 
améliorer le support jusqu'à PHP 7.4, en corrigeant des «deprecated» 
et diverses petites choses qui ne sont pas actuellement bloquantes, mais 
qui vont alléger un peu les log des serveurs.


SPIP 3.2 sera donc compatible de PHP 5.4 à 7.4

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

Re: [spip-dev] Notre cycle de release

2021-03-15 Par sujet Matthieu Marcillaud

Le 15/03/2021 à 15:38, Bruno Bergot a écrit :
[...]

Je pense qu'il serait vraiment bien qu'on adopte un rythme de release 
plus "régulier", afin de nous caler sur celui des releases de PHP, qui 
pour rappel est le moteur de SPIP :)


Amha, on pourrait se fixer :

- une release Y chaque année, dans la même période que la release d'une 
nouvelle version de PHP
- moins important, mais qui permettrait plus facilement de tenir le 
premier point, une release Z tous les X mois (je pense à 3 ou 4).


[...]

Dans tous les cas, la version maxi de PHP supportée par SPIP serait la 
version stable de l'année en cours, et on ne change pas de version maxi 
de PHP pour les anciennes releases.


Je plussois. J'espère qu'on réussira à maintenir (encore faut il 
commencer!) un cycle de release plus rapide… On avait espéré après la 
3.2 pourtant.


Ceci dit, maintenant nous sommes en Git, et il est plus facile de faire 
des branches de dev, de faire des branches pour les prochaines versions, 
etc. Donc… avec un peu de motivation ça devrait être jouable.


Pour récapituler, voici donc des exemples de ce que cela pourrait donner 
en terme de versions SPIP => versions PHP compatibles.



Scénario 1 : Releases minimales
===

1 release / an (après la sortie de version PHP, disons décembre)

- 3.3 (bientôt / prochainement / on y croit / ouf) => [7.3 .. 8.0]
- 3.4 (12 2021) => [7.4 .. 8.1]
- 3.5 (12 2022) => [8.0 .. 8.2]
- 3.6 (12 2023) => [8.1 .. 8.3] => fin de support sécu SPIP 3.3.


Scénario 2 : Releases pétillantes
=

1 release / an au minimum (après la sortie de version PHP, disons décembre)

- 3.3 (bientôt / prochainement / on y croit / ouf) => [7.3 .. 8.0]
- 3.4 (08 2021) => [7.3 .. 8.0]
- 3.5 (12 2021) => [7.4 .. 8.1]
- 3.6 (04 2022) => [7.4 .. 8.1] => fin de support sécu SPIP 3.3 ?
- 4.0 (07 2022) => [7.4 .. 8.1]
- 4.1 (09 2022) => [7.4 .. 8.1]
- 4.2 (12 2022) => [8.0 .. 8.2]
- 4.3 (04 2023) => [8.0 .. 8.2]

Juste donc, deux exemples pour situer. En gros, une release majeure de 
SPIP (x.y) suivrait simplement la version de PHP maintenue au moment de 
sa sortie.


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

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

2021-03-11 Par sujet Matthieu Marcillaud

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


Les versions PHP maintenues sont 7.3+ à ce jour.


Sur le sujet de monter la version minimale, scssphp se pose aussi la 
question pour sa version 2, et fait un petit bilan de certains CMS (qui 
utilisent scssphp) au passage 
: https://github.com/scssphp/scssphp/issues/314


Pour rappel cette librairie est utilisée par le plugin SPIP scssphp (et 
nécessaire aux plugins/squelettes bootstrap 3 et 4, spipr-dist...).


Pour eux c'est passer à 7.2 mini qui serait le plus intéressant pour 
bénéficier de la covariance / contravariance sur les types d'arguments 
des méthodes et retours de méthodes (enfin une partie en 7.2, le reste 
est introduit en 7.4). 
https://www.php.net/manual/fr/language.oop5.variance.php


Si on ne va pas directement à 7.3+ pour SPIP 3.3, on peut aussi aller 
vers PHP 7.2+ comme eux (à la place de 7.1), même si pour SPIP 
actuellement l'intérêt direct est plus limité.


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

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

2021-03-11 Par sujet Matthieu Marcillaud

Le 11/03/2021 à 08:42, erational a écrit :

Hello

Quelqu'un pourrait relancer le cron pour générer le master s'il vous 
plait ?


Alors le zip se génère correctement.
Mais après le débardeur considère qu'il n'est pas plus récent car sa 
date n'a pas bougé (il met la date du dernier commit du core)



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)


J'ai «corrigé» si on veut, en mettant la date du dernier commit (core ou 
plugins-dist / squelettes-dist ; le plus récent)


Du coup, le débardeur devrait être content.

On verra à son prochain passage.

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


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

2021-03-04 Par sujet Matthieu Marcillaud

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

Bonjour,


[...]


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


Du coup, dans ma grande motivation, je viens de reporter différents 
commits pour PHP 7.2 et 7.3 en SPIP 3.2 qui enlèvent pas mal de 
deprecated et certains warnings.


Puis dans la foulée, j'ai reporté aussi des éléments pour la compat PHP 
7.4 dans SPIP 3.2.


Donc là, a priori il ne devrait plus y avoir de gros problèmes dans le 
Core pour ces versions PHP là en SPIP 3.2. En tout cas je ne vois rien 
de flagrant.


Ça pourra mériter une petite release de maintenance du coup.

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

[spip-dev] Version PHP minimum SPIP 3.3

2021-03-04 Par sujet Matthieu Marcillaud

Hello,

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


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


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


Les versions PHP maintenues sont 7.3+ à ce jour.

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

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

Des avis avisés ?

MM.

___
liste: https://listes.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 Matthieu Marcillaud

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


Re: [spip-dev] Création de balise - vérification sur champ_sql - existence d'une valeur

2021-02-23 Par sujet Matthieu Marcillaud

Le 23/02/2021 à 18:02, Vincent Callies a écrit :

Bonjour les écureuils,


[...]

Première rédaction dysfonctionnelle : Que le nom d'usage soit indiqué 
dans la table ou non, le nom est considéré comme existant.


function balise_LE_NOM ($p) {
$_nom = (champ_sql('nom_usage', $p)) ? champ_sql('nom_usage', $p) : 
champ_sql('nom_famille', $p) ;

$p->code = "$_nom";
return $p;
}


En fait tu pourrais regarder en mode debug par exemple le code PHP que 
te génère cette balise ; ça t'aiderait à comprendre.


Ce qui ce passe c'est que $p->code génère un code valide PHP. La 
fonction "champ_sql()" retourne du code PHP (comment obtenir "nom_usage" 
dans la ligne de bdd). Pas la valeur elle-même dans la bdd, inconnue à 
ce stade.


Du coup, tester "champ_sql('X', $p)) ? A : B" comme ici retournera 
toujours A. car pour peu que le champ X existe, ça retourne du code PHP. 
Donc du contenu (true) ? A : B.


Ce que tu veux tester c'est le résultat de l'exécution de ce code PHP 
(dans $p->code), comme tu fais dans la seconde fonction.


Tu aurais pu écrire aussi (je n'ai pas testé là) :

$_nom_usage = champ_sql('nom_usage', $p);
$_nom_famille = champ_sql('nom_famille', $p);
$p->code = "(\$a = $_nom_usage) ? \$a : $_nom_famille";

Tu affectes (affecteras) le résultat (de l'éxécution du code php 
$_nom_usage) dans $a (sa vrai valeur en bdd pour le coup) ; s'il a du 
contenu, tu l'affiches, sinon tu utilises le nom de famille (en 
exécutant son code pour l'obtenir).


De la sorte l'instruction pour obtenir le nom d'usage n'est exécuté 
qu'une fois au lieu de deux.



MM.



Seconde rédaction opérationnelle :

function balise_LE_NOM ($p) {
// chopper les valeurs des champ sql dans la boucle
$_nom_usage = champ_sql('nom_usage', $p) ;
$_nom_famille = champ_sql('nom_famille', $p) ;
$_nom = "(strlen($_nom_usage))
? $_nom_usage
: $_nom_famille";
$p->code = "$_nom";
return $p;
}

Merci par avance pour vos lumières. Et accessoirement dois-je protéger 
l'écriture de sortie d'un nom qui serait avec une apostrophe ou un 
caractère spécial ou bien SPIP fait cela tout seul ?


Thrax



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


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

2021-02-23 Par sujet Matthieu Marcillaud

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

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

À poursuivre donc.


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

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


MM.

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


Re: [spip-dev] Gestion des icones - SPIP 3.3

2021-02-22 Par sujet Matthieu Marcillaud

Le 20/02/2021 à 11:44, Eric Lupinacci a écrit :

Hello,


Quand j'affiche la page des compositions j'obtiens des erreurs sur les 
icones 


Effectivement.
Corrigé par https://git.spip.net/spip/spip/commit/1fc530e6 si tout va bien.

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


Re: [spip-dev] mise a jour spip parSpip Loader

2021-02-17 Par sujet Matthieu Marcillaud

Le 17/02/2021 à 03:54, Eric Priou a écrit :

Bonjour,

J‘ai utilisé le spip loader 3.0.9 pour passer de Spip 3.2.7 à 3.2.9 avec 
succès.




Par contre, la fenêtre indiquait passage  de 3.2.7 à 3.2.7, ce qui était 
un peu perturbant. Pourriez-vous changer le message?


On est à la version 4.3 du spip_loader. Ce n'est pas pour rien.


Demande subsidiaire: je voudrais installer la dernière version de spip 
loader mais j’ai un problème non encore résolu avec Filezilla.


Il est *fortement* déconseillé d'utiliser le spip_loader si tu n'as pas 
accès à tes fichiers (ftp, ssh, ...) (pour réparer a minima en cas de 
problème)...


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

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

2021-02-17 Par sujet Matthieu Marcillaud

Le 16/02/2021 à 19:53, David Prévot a écrit :

[...]

Bullseye (la prochaine version stable de Debian) fournira PHP 7.4. Elle 
proposera SPIP 3.2.9 (fingers crossed, early testing welcome…).


Alors clairement je doute fortement que SPIP 3.2 fonctionne avec PHP 7.4 
sans warnings bloquants (impactants le fonctionnement), voire fatales. 
Et je doute encore plus que l'on reporte les corrections faites à ce 
sujet (trop nombreuses) de la 3.3 vers la 3.2.


À part sortir une 3.3, je ne vois pas de solution.

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

Re: [spip-dev] SPIP loader ne télécharge pas le master ?

2021-02-01 Par sujet Matthieu Marcillaud

Le 28/01/2021 à 17:40, jeanmarie a écrit :

Si c'est ce fichier https://files.spip.net/spip/dev/ (spip-master.zip) 
qui est téléchargé, il semble dater du 29/9/20.


Tu pourras retester ? (le cron ne tournait effectivement pas).

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


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

2020-12-04 Par sujet Matthieu Marcillaud

Le 04/12/2020 à 15:05, nicod_ a écrit :

Le 04/12/2020 à 13:16, Ybbet SPIP a écrit :

Pour résumer, l’équipe adopte cet ordre de préférence :

 1. Formulation neutre. Exemple : « Les personnes chargées de
    l’administration »
 2. Formulation combinée
    Exemple : « Les administrateurs et administratrices »
 3. Formulation basée sur l’usage du point médian
    Exemple : « Les administrateur·ice·s »


[...]

On avait évoqué d'inscrire ça dans la charte (je suis pour) mais cela 
n'avais pas été fait.
Peut être que c'est une régle plus "technique" que les principes 
généraux, et qu'elle n'y a pas sa place pour garder de la concision, 
mais je pense que l'exemple cité ci dessus est clair et pédagogique.


Pourquoi pas.

Je préciserais bien le point 2 quand même, car 
https://theconversation.com/ecriture-inclusive-un-premier-bilan-de-la-controverse-147630 
indique que le premier terme d'une construction double est considéré 
comme plus important, et donc il convient de ne pas mettre 
systématiquement le masculin en premier dans ce cas !


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

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

2020-12-03 Par sujet Matthieu Marcillaud

Le 03/12/2020 à 14:53, BERTRAND Joël a écrit :

[...]

> Dans ce cas, la grammaire à changé. Et ce n'est pas non plus ce
> qu'indique l'Académie Française

On parle de l’Académie Française ? vraiment ? tu vas pas être déçu...
https://www.youtube.com/watch?v=hfUsGmcr1PI

Sinon on remet au moins ce lien (rappel) :
https://www.haut-conseil-egalite.gouv.fr/IMG/pdf/guide_pour_une_communication_publique_sans_stereotype_de_sexe_vf_2016_11_02.compressed.pdf


Pour revenir au sujet, tu peux te créer un lang/fr_academie.php et 
l’utiliser pour toi, ou même le partager quelque part si c’est important 
pour toi.


Cependant, laisse nous essayer d’apporter des corrections à notre niveau 
sur les chaines de langues de SPIP, avec la disponibilité et énergie de 
chacun·e, pour intégrer plus fréquemment l’usage du féminin dedans ; 
c’est le minimum qu’on puisse faire pour une société un peu plus juste, 
et c’est une revendication des personnes concernées avant tout.


Ça ne sera jamais parfait de toutes façons. Il y a des contraintes 
historiques (le terme "auteur" dans SPIP par exemple), techniques 
(écrire les 2 formes masculin et féminin prend plus de place)...



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

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

2020-11-16 Par sujet Matthieu Marcillaud
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

Re: [spip-dev] Git et twgit

2020-11-12 Par sujet Matthieu Marcillaud

Le 12/11/2020 à 10:48, Ybbet SPIP a écrit :

Bonjour,

Je me permets une petite relance sur le sujet. Avez-vous pu le lire et 
surtout avez-vous une avis, une contre indication ?


[...]

Lors de mes développements, j'ai pris l'habitude d'utiliser Twgit. 


Je ne connaissais pas. Ça n’a pas l’air trop connu d’ailleurs, même si 
ça semble parfois utilisé et que la magie ne fait pas tout 
(https://medium.com/@MarvelousCow/please-stop-saying-that-you-know-how-to-use-git-19200d974b51)


[...]

 L'existence de

la branche "stable" (nécessaire à twgit) casserait ce processus ?


A priori non, ça ne casse pas le processus de tag => zip.

Cela étant dit, pourquoi diable n’ont-ielles pas conservé "master". Elle 
devient quoi cette branche "master" dans tout ça ?


(même si pour le coup, probablement sans le faire exprès, ielles 
éliminent le problème de terminologie master/slave...).


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

Re: [spip-dev] Help : Problème php.ini poids fichier en upload avec dev 3.3.0

2020-11-11 Par sujet Matthieu Marcillaud

Le 11/11/2020 à 14:15, nicod_ a écrit :

Donc plutôt que de fixer une limite, pourquoi ne pas proposer une 
valeur à 0 par défaut, et laisser les webmestres qui souhaitent 
limiter cette valeur le faire de puis la conf ?


0 au sens illimité ?

Je suis moyen chaud. Ça me semblerait un peu trop facile de faire 
remplir le disque dur du coup... Mais 5Mo c’est peu par défaut c’est sûr.


Bref, faites comme vous voulez :)

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

Re: [spip-dev] Help : Problème php.ini poids fichier en upload avec dev 3.3.0

2020-11-10 Par sujet Matthieu Marcillaud

Le 10/11/2020 à 16:34, o2 a écrit :
Merci Matthieu pour la réactivité de votre réponse ! en plus sur une 


On y accède comment par l'interface d'admin (autre qu'avec le ?exec) 


Pour le moment : Gestion des plugins > Verrouillés (ou Tous) > Bigup > 
Configurer


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


Re: [spip-dev] Help : Problème php.ini poids fichier en upload avec dev 3.3.0

2020-11-10 Par sujet Matthieu Marcillaud

Le 10/11/2020 à 16:02, o2 a écrit :

Bonjour

J'ai un souci avec le téléchargement de documents dans la version dev de 
spip 3.3.0 : avant il me suffisait de modifier mon php.ini pour faire 
sauter la clause de 2Mo max par fichier en upload depuis l'interface 
d'admin dans un article ou autre.


Maintenant malgré cela, j'ai un message qui dit : "Le fichier ne doit 
pas dépasser 5 Mo"


Comment peut-on éviter ce désagrément ?  (hors passage par le serveur)


C’est dans la configuration de Bigup (?exec=configurer_bigup)

Faut peut être qu’on améliore l’accès à cette entrée de configuration.

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

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

2020-10-13 Par sujet Matthieu Marcillaud

Le 13/10/2020 à 10:50, Cerdic a écrit :
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’est chouette.

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 ?


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

Re: [spip-dev] Article de présentation de Spip 3.3

2020-10-05 Par sujet Matthieu Marcillaud

Le 05/10/2020 à 11:49, tcharlss a écrit :

Hello tou⋅te⋅s,

Dans la vallée court une rumeur à propos de la sortie d'une version 
alpha de Spip 3.3.

Il reste à finaliser l'article de présentation de cette version.

Si j'ai bien suivi, on est parti du pad suivant : 
https://semestriel.framapad.org/p/spip3.3-alpha


en y réfléchissant je pense que c’était l’article destiné à 
blog.spip.net dans le pad, pas forcément spip.net. L’article de release 
de blog quoi.


Sur spip.net ça rentre plus dans les détails techniques ?

Peut être je me trompe.

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

Re: [spip-dev] redirection de forum et certificat

2020-10-04 Par sujet Matthieu Marcillaud

Le 04/10/2020 à 13:30, Franck a écrit :

Hello 

Juste pour dire que la redirection de 
http://forum.spip.net/fr_184153.html 
 vers 
https://forum.spip.net/fr_184153.html 


Arf. Corrigé pour ça. Thx.

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

Re: [spip-dev] Adresse de distribution du spip_loader ?

2020-10-01 Par sujet Matthieu Marcillaud

Le 01/10/2020 à 07:59, erational a écrit :

Hello

Sur la doc
https://www.spip.net/fr_download
https://www.spip.net/fr_article5705.html

On annonçait que spip_loader est distribué depuis:
https://www.spip.net/spip-dev/INSTALL/spip_loader.php

On y trouve la version 3.0.9 


Ttt. Bouge ton cache mon garçon !

C’était en 4.1.0 ; je viens d’y coller la 4.1.1

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

Re: [spip-dev] Renommages branches & tags SPIP + plugins-dist

2020-09-27 Par sujet Matthieu Marcillaud

Le 26/09/2020 à 13:56, Matthieu Marcillaud a écrit :

Hello everybody !

Il est probable qu’on s’occupe dans le week end (demain?) de renommer 
les branches & tags de SPIP et des plugins-dist, tel que proposé dans un 
thread précédent (Release, Git, Composer - du 14 septembre dernier).


Tout le monde semblait partant (je n’ai pas vu de contre indication en 
tout cas !).


Je pense ajouter également, enfin remplacer plutôt, le fichier 
.gitsvnextmodules par un fichier spip_modules.json ou quelque chose 
comme ça dans les branches 3.1+. 


Voilà, tout est à peu près fait pour ce que j’indiquais (reste plus qu’à 
vérifier tout ça)


- un fichier plugins-dist.json est présent dans les 3 branches master, 
3.2 et 3.1 et est utilisé de préférence par l’outil Checkout (à mettre à 
jour) (lonsqu’on lance 'checkout spip ...')


- un mini script très très à l’arrache http://spip.pastebin.fr/66841 
nettoie les branches et tags supprimées du remote 'origin' ; ça peut 
aider...


/!\ Attention (cher développeureuse de SPIP) à ne pas faire de `git push 
--tags` à un moment après ta mise à jour, sans avoir fait par exemple un 
`git fetch origin --prune --prune-tags` avant sur ton projet pour ne pas 
repusher tous les anciens tags d’un coup (ça serait ballot) ! Note que 
git push a une option --dry-run qui permet de voir et vérifier ce qui va 
être envoyé.


Belle nuit à toutes & tous,

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

Re: [spip-dev] Renommages branches & tags SPIP + plugins-dist

2020-09-27 Par sujet Matthieu Marcillaud

Le 26/09/2020 à 13:56, Matthieu Marcillaud a écrit :

Les outils checkout et spip-cli seront temporairement cassés et devront 
être mis à jour. J’essaierai de m’occuper de checkout.


J’ai envoyé un premier pas avec une version 1.4.0 de checkout.

Ce n’est qu’une première étape (plugins-dist.json n’est pas encore 
introduit), mais ça télécharge ou met à jour un SPIP ce qui est déjà pas 
si mal.


J’ai ajouté un lien aussi sur la commande 'checkout' exécutable, vers 
checkout.php d’avant pour avoir un nom de commande identique entre 
Windows et MacOs/Linux. Et adapté le readme en conséquence.


Cependant checkout ne supprime pas les branches ou tags qui ont été 
supprimé sur le dépot distant.


Pour ça il faut lancer

- git fetch --prune
- git fetch --prune --prune-tags

ou plus spécifiquement avec le nom du remote

- git fetch origin --prune
- git fetch origin --prune --prune-tags

Les branches suivies localement auparavant sont conservées. Typiquement 
si vous étiez en 'spip-3.2' vous aurez une branche '3.2' active (le 
nouveau nom), qui suit origin/3.2, et une branche 'spip-3.2' présente 
d’avant, qui suit origin/spip-3.2 qui n’existe plus (car enlevé avec le 
--prune).


Cette branche locale spip-3.2 peut donc être supprimée.

C’est pareil pour les plugins dist (dans l’autre sens).


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

Re: [spip-dev] Renommages branches & tags SPIP + plugins-dist

2020-09-27 Par sujet Matthieu Marcillaud

Le 26/09/2020 à 13:56, Matthieu Marcillaud a écrit :

Hello everybody !

Il est probable qu’on s’occupe dans le week end (demain?) de renommer 
les branches & tags de SPIP et des plugins-dist, tel que proposé dans un 
thread précédent (Release, Git, Composer - du 14 septembre dernier).


Voilà, c’est fait pour cette partie.

Résumé.

Sur spip/spip :

- Les branches spip-X ont été renommées X (spip-3.2 => 3.2)
- Les tags spip-X ont été renommés vX (spip-3.2.1 => v3.2.1)

Quelques cas particuliers :

- branche 1.9 => 1.9.1
- branche spip-1.9.2 => 1.9.2

Les tags des versions ont été homogénéisés selon semver, avec les 
pre-release séparés par - et éventuellement '.'. Des releases 
spéficiques (a à z sont séparés par +, comme des «build» au sens 
semver). Exemples (j’ai plus les vrais en tête) :


- spip-3.0.0alpha1 => v3.0.0-alpha.1
- spip-3.0.0-beta => v3.0.0-beta
- spip-1.9.2f => v1.9.2+f


Sur spip/{plugins-dist} :

- branche X => branche 'spip-X'

Exemple :

- 3.2 => spip-3.2

On conserve ces branches pour historique des plugins-dist, mais dans le 
futur on évitera d’en créer «pour une version de SPIP particulière».


Voilà, hope it helps.

Je bascule sur la mise à jour des outils.
Et après j’essaie de voir pour indiquer des commandes de migration 
éventuellement.


Bizous.

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

Re: [spip-dev] Renommages branches & tags SPIP + plugins-dist

2020-09-27 Par sujet Matthieu Marcillaud

Le 26/09/2020 à 13:56, Matthieu Marcillaud a écrit :

Hello everybody !

Il est probable qu’on s’occupe dans le week end (demain?) de renommer 
les branches & tags de SPIP et des plugins-dist, tel que proposé dans un 
thread précédent (Release, Git, Composer - du 14 septembre dernier).


On va lancer les hostilités donc.

Attention /!\ : les scripts d’installation (checkout, spip-cli) vont 
casser pendant quelques temps (heures, jours...).


Bisous.

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

[spip-dev] Renommages branches & tags SPIP + plugins-dist

2020-09-26 Par sujet Matthieu Marcillaud

Hello everybody !

Il est probable qu’on s’occupe dans le week end (demain?) de renommer 
les branches & tags de SPIP et des plugins-dist, tel que proposé dans un 
thread précédent (Release, Git, Composer - du 14 septembre dernier).


Tout le monde semblait partant (je n’ai pas vu de contre indication en 
tout cas !).


Je pense ajouter également, enfin remplacer plutôt, le fichier 
.gitsvnextmodules par un fichier spip_modules.json ou quelque chose 
comme ça dans les branches 3.1+. Ce fichier listerait simplement l’url 
des Gits des plugins-dist (sans préciser la branche ou tag) et le 
répertoire destination. Encore une fois ce n’est pas quelque chose (ce 
fichier) qui sera pérennisé (l’idée est tout de même pour les futurs 
développement d’aller vers un composer.json)


Les outils checkout et spip-cli seront temporairement cassés et devront 
être mis à jour. J’essaierai de m’occuper de checkout.


Voilà, j’espère que vous avez la forme !

Tendresse à toutes & tous,

Matthieu.

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

Re: [spip-dev] Citer les branches

2020-09-24 Par sujet Matthieu Marcillaud

Le 24/09/2020 à 13:41, JLuc a écrit :

Mystère : sur la liste des commits on voit passer des commits en double.

C'est parce que la branche est différente !

Alors serait il possible de citer la branche sur laquelle se fait le commit
dans le mail de notification ?


J’ai corrigé en ce sens (à vérifier) (hors master).

Par contre je n’ai manifestement pas réussi à enlever le  qui 
remplace les -- .


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

Re: [spip-dev] Release, Git, Composer

2020-09-16 Par sujet Matthieu Marcillaud

Le 15/09/2020 à 22:07, plac...@roxing.net a écrit :

Le 15/09/2020 à 20:17, nicod_ a écrit :

Pourquoi pas, mais je me pose toujours une question sur la licence
commerciale (dans le cas où on vend un SPIP incluant fancybox 3), j'ai
toujours un doute.


Je pense que ton doute est bien fondé. J'en remets un couche pour
pousser featherlight du coup.

https://github.com/noelboss/featherlight/blob/master/LICENSE



De ce que j’ai compris de Cédric, il pensait plutôt de mettre une box 
light (feather ?) dans le core, et un plugin séparé pour fancybox. Donc 
le problème ne se poserait pas directement pour SPIP.

Enfin ça reste une bonne question en suspens.

Mais pas vraiment le sujet de ce thread SVP :)

Comme je disais sur IRC, si on n’est pas clair sur les fonctionnalités 
de la 3.3 ou qu’il y a encore des soucis gênants dessus, on sortira une 
-alpha (et pas une -bêta) et voilà. C’est pas un drame :)


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

[spip-dev] Release, Git, Composer

2020-09-14 Par sujet Matthieu Marcillaud

# 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 même 
commit que le tag `spip/x.y.z-1` d’avant,
mais il serait plus judicieux de basculer sur une déclaration de 
contraintes / require sur Composer, et
 ça permettrait du coup de décorréler possiblement mieux les mises à 
jour des plugins-dist par rapport à SPIP.


Typiquement :

- spip/spip (le projet) devrait require un spip/sdk ou spip/core tel que 
'^3.2.0' ...

- spip/spip pourrait déclarer require : 'spip/mots': '^1' ou '^1.11'
- spip/mots devrait require une version de 'spip/sdk' ou 'spip/core' 
également


## Actions à trancher

Le nom des tags et branches de spip et plugins dist est à redéfinir.

- On est d’accord ?
- Avant ou après la prochaine release ?
- Quid de .gitsvnetxmodules qui pointe sur les SVN ? On le laisse sur ce 
nom là en changeant son contenu pour les liens git ? On le renomme 
.spip_modules le temps d’avoir un composer.json ? On trouve une autre 
solution pour checkout.php (et spip-cli qui utilise le même code) ?


___
liste: https://listes.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-08 Par sujet Matthieu Marcillaud

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

Re: [spip-dev] Bel_env et debug

2020-08-13 Par sujet Matthieu Marcillaud

Le 11/08/2020 à 21:49, nicod_ a écrit :

Le 11/08/2020 à 18:46, Eric Lupinacci a écrit :

Hello,

Une petite remarque avant la prochaine release 3.3.
Dans le code on a ajouter il y a déjà longtemps le filtre |debug qui 
permet de faire du... debug dans les squelettes.


Pour ma part, j’installe symfony/var_dumper
et j’utilise dump() ou |dump
Et c’est très joli par défaut :)

Mais ça fait pas d’auto unserialize.

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

Re: [spip-dev] Données Exif des images réduites

2020-07-21 Par sujet Matthieu Marcillaud

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.


Bonne nouvelle : ça vient pas de Bigup :)
Autre nouvelle : «medias» indique dans son code :

// permettre aux plugins de faire des modifs a l'ajout initial
// ex EXIF qui tourne les images si necessaire
// Ce plugin ferait quand même mieux de se placer dans metadata/jpg.php

Et ne tourne donc pas les images selon l’exif par défaut. Mais je ne 
trouve pas non plus je crois de plugin qui ferait ça, (j’ai pas trop 
cherché non plus)...


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

Re: [spip-dev] [BUG] Objets_virtuels > sql_showtable()

2020-07-05 Par sujet Matthieu Marcillaud

Le 04/07/2020 à 23:45, Stephane Santon a écrit :

Bonjour,

J'ai trouvé le BUG, (mais pas capable de corriger). Pfio !
Spip 3.2.7 et tables avec préfixe personnalisé : bs4_ au lieu de spip_

Dans le fichier
objets_virtuels\v1.1.3\formulaires\configurer_objets_virtuels.php

function formulaires_configurer_objets_virtuels_traiter_dist() {

L44 : Le nom de table est récupéré sous le format 'spip_articles' et on 
fait un sql_showtable. Celui-ci renvoie un array $desc *VIDE*.



Bonjour Stephane,

C’est très bien vu pour l’appel à sql_showtable().
En fait il faut remplacer `$desc = sql_showtable($table);` par `$desc = 
sql_showtable($table, true);`


Je suis assez étonné que ça ne soit pas le comportement par défaut en 
fait, et il semble que plusieurs plugins ont du coup la même erreur dans 
leur code, notamment :


- champs extras interface,
- couteau suisse (boite privée)
- date_creation
- identifiants
- inscription3 (les appels semblent incorrects)
- isocode
- rang
- saveauto (PHPStorm indique beaucoup d’indéfinis dans la fonction 
inc_saveauto_dist(), pas sûr que ce truc marche de toutes façons)



Même dans SPIP : certaines vieilles maj ne l’utilisent pas
- maj_11778()
- maj_1_938()

Probablement quelques corrections à faire donc.

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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Matthieu Marcillaud

Le 30/06/2020 à 12:07, RealET a écrit :

Matthieu Marcillaud a écrit le 30/06/2020 à 12:03 :

Le 30/06/2020 à 11:55, RealET a écrit :
[...]

Est-ce que  tu pourrais migrer :

champs_extras_import_export


Il sert encore lui ? Dans quelle situation ?

Très honnêtement, je ne sais pas.
Mais il m'a semblé intéressant de par son descriptif.
Mais si tu dis qu'il n'a pas de raison de servir, autant le supprimer.


https://zone.spip.org/trac/spip-zone/changeset/90626

C’est dans Champs Extras interfaces depuis 5 ans en fait il me semble.

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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Matthieu Marcillaud

Le 30/06/2020 à 11:55, RealET a écrit :
[...]

Est-ce que  tu pourrais migrer :

champs_extras_import_export


Il sert encore lui ? Dans quelle situation ?

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


Re: [spip-dev] r125010 - in _core_/plugins/svp

2020-06-06 Par sujet Matthieu Marcillaud

Le 06/06/2020 à 15:00, Eric Lupinacci a écrit :

Ca ne me parait pas une bonne idée.
Je pense que cette taille est aussi utilisée ailleurs.
C'est un préfixe pas une phrase.

Donc je ne suis pas trop pour.


A proprement parler, il n’y a rien qui limite dans SPIP la taille du 
préfixe. C’est «juste» la copie en bdd des plugins dans SVP.


Et va dire ça donc au plugin 
https://git.spip.net/spip-contrib-extensions/paniers_commandes_quantites_decimal 
.


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

Re: [spip-dev] Équivalence des commandes SVN/GIT

2020-06-03 Par sujet Matthieu Marcillaud

Le 03/06/2020 à 18:41, Maïeul Rouquette a écrit :

Le 03/06/2020 à 18:31, teamspipfact...@gmail.com a écrit :
[...]
Quand à citer des sources sur pourquoi genrer dans les deux genre est 
important :
- 
https://www.hepl.ch/files/live/sites/systemsite/files/instance-egalite/manuel-ecriture-inclusive-2016.pdf 


- http://www.ecriture-inclusive.ch/langage-inclusif-ecriture-suisse/

A ceci je t'inviterai à lire l'ouvrage d'Elian Viennot "Non le masculin 
ne l'emporte pas sur le féminin".


Et plus généralement
http://www.haut-conseil-egalite.gouv.fr/IMG/pdf/guide_pour_une_communication_publique_sans_stereotype_de_sexe_vf_2016_11_02.compressed.pdf


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


Re: [spip-dev] Équivalence des commandes SVN/GIT

2020-06-03 Par sujet Matthieu Marcillaud

Le 03/06/2020 à 17:13, teamspipfact...@gmail.com a écrit :

Le 03/06/2020 à 16:05, jeanmarie a écrit :

dans l'idée de faciliter la transition SVN > Git pour tout le monde
(utilisateurs et développeurs de plugins),

Le 03/06/2020 à 16:01, tout...@free.fr a écrit :

Je trouve très regrettable que ce soit toujours à moi qu'il soit échu de
rappeler que l'écriture inclusive est préférable à l'écriture masculine.
... / ...


Juste parce-que vendredi c'est demain


[...]


;-)


Essaie de faire un effort Spipfactory pour rester dans les clous. Ça 
soulagera du monde.


Heureusement, la langue évolue en dehors de la bienséance de l’académie 
française. Pour mémoire récemment, ielles (enfin presque juste ils 
d’ailleurs ce groupe) ont décidé que Covid-19 était féminin (la 
Covid-19) sous des prétextes un peu capilotractés (c’est très facile de 
trouver des contre exemples), quand l’usage courant était à 98% "le 
Covid-19" sous entendu probablement une abréviation de "le virus 
Covid-19". On trouve maintenant un peu plus d’usage de "la Covid" dans 
les médias, mais pas tant que ça 
(https://trends.google.com/trends/explore?geo=FR=%22le%20Covid%22,%22la%20Covid%22). 
L’académie ou le dictionnaire ne fait pas forcément la loi, ni l’usage réel.


Tout ça pour dire qu’on décide collectivement de l’usage de la langue, 
de ses modifications, et on peut inciter d’autres usages. Parfois on 
semble aussi subir (à nos yeux) des modifications de la langue, 
particulièrement à l’écrit, style SMS sans grammaire...


Et on souhaite au maximum que tout le monde (enfin au mieux que l’on 
peut) s’y retrouve, et si ça passe par un détournement du vocabulaire et 
grammaire la langue, de l’orthographe, bah tant pis (ou tant mieux) ;


c’est mieux que de systématiquement en français utiliser le masculin 
alors qu’on veut souvent ne pas spécifier de genre particulier. Donc on 
détourne les mots avec l’écriture inclusive à l’écrit, ou en indiquant 
le masculin et féminin, en réutilisant de «vieux» mots, ou en créant de 
nouveaux mots, … et tant mieux si au fil du temps tout ça passe dans 
l’usage courant. Une langue est vivante.


Tendresse & noisettes à tout·e·s.

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

Re: [spip-dev] [Spip-zone-commit] r124829 - in _plugins_/chartjs/trunk

2020-05-28 Par sujet Matthieu Marcillaud

Le 28/05/2020 à 08:39, tcharlss a écrit :

Le 27/05/2020 à 23:40, Matthieu Marcillaud a écrit :

 mais peu importe, il n'y a pas de raison d'avoir

une branche v2 à part qui ne sera jamais finalisée.
Yep, je savais pas trop. J’ai surtout nommé v3 pour suivre un peu le 
passage en v3 de la lib Chart.js en fait.


Bon, j’ai repassé en v2 et supprimé la branche v2.
[...]
Le texte de release de la lib indique tout de même quelques "breaking 
changes", rien de très compliqué à priori, mais quelques adaptations à 
prévoir : https://github.com/chartjs/Chart.js/releases/tag/v3.0.0-alpha 
et https://www.chartjs.org/docs/next/getting-started/v3-migration/


Je pense avoir fait les modifs qui concernaient le modèle (changement de 
déclaration de options.scales) ; j’ai rien vu d’autre. Mais j’ai pas non 
plus regardé en détail.


Dans la démo, il y a une seule chose qui change (en dehors de la taille 
des graphiques), c’est le type « scatter » qui avait un tracé de ligne 
en plus des points, et n’affiche plus que les points (ce qui semble ce 
qui est attendu d’ailleurs). Le comportement a été changé en 2.7 (#4381 
Scatter chart doesn't anymore display lines by default.)


Voilou.

À toi :)

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

Re: [spip-dev] [Spip-zone-commit] r124829 - in _plugins_/chartjs/trunk

2020-05-27 Par sujet Matthieu Marcillaud

Le 27/05/2020 à 12:44, tcharlss a écrit :

Glop marcimat,


[...]


Au final le master était toujours fonctionnel, mais je l'avais laissé en 
dev car j'avais d'autres évolutions en tête qui sont restées en plan.
Notamment donner la possibilité d'utiliser n'importe quel paramètres de 
la lib dans le modèle, pas juste une sélection réduite de paramètres 
"simplifiés".

Enfin bref, c'était toujours du dev utilisé par personne à priori :)


Bah nous on utilisait cette v2 depuis un moment

Donc je ne sais pas si la v3 de la lib est encore une réécriture qui 
change tout à nouveau,


Non, ça change quasi rien pour les utilisateurs, ni pour le modèle chart 
de SPIP cette v3 de la lib.


 mais peu importe, il n'y a pas de raison d'avoir

une branche v2 à part qui ne sera jamais finalisée.


Yep, je savais pas trop. J’ai surtout nommé v3 pour suivre un peu le 
passage en v3 de la lib Chart.js en fait.




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

Re: [spip-dev] Installation de bigup par SVP en 3.2

2020-05-27 Par sujet Matthieu Marcillaud

Le 27/05/2020 à 11:20, JLuc a écrit :


Peut être faut il plutôt convenir d'un ordre alphabétique simple,
qui regroupera les github, les gitlab et les git.spip ?


Oui, par ordre alpha, mais sur l’URL complète. C’est bien ce que tu 
proposais ?

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

Re: [spip-dev] LEFT join est-ce possible?

2020-04-27 Par sujet Matthieu Marcillaud

Le 27/04/2020 à 10:21, Alexis a écrit :


J'ai trouvé dans composer.php

@param array $from_type qui semblerait permettre de demander une 
jointure d'un type spécifique mais je n'ai pas trouvé comment passer ce 
paramètre.


Y'a-t il une syntaxe particulière de la définition de la boucle pour 
spécifier ce paramètre?



Nope, pas moyen pour le moment.
Cf le succinct https://core.spip.net/issues/3711

Il te faut actuellement créer un critère spécifique pour définir ce type 
de jointure. Quelques exemples :


- https://git.spip.net/spip/forum/src/branch/master/public/forum.php#L94
- 
https://git.spip.net/spip/organiseur/src/branch/master/organiseur_fonctions.php#L29
- 
https://git.spip.net/spip-contrib-extensions/contacts_et_organisations/src/branch/master/contacts_fonctions.php#L139
- 
https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/gis_fonctions.php#L258


Hope it helps,

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


Re: [spip-dev] Recherche dans SVP...

2020-04-10 Par sujet Matthieu Marcillaud

Le 09/04/2020 à 21:53, nicod_ a écrit :

Yop,

je suis perplexe : je cherchais à installer photoswipe par SVP.

Je cherche "photo", je trouve "Outdoor" et "Metadonnées photo"
Je cherche "swipe", je ne trouve rien.
Avec "photoswipe", il apparait bien.

C'est une recherche par mot exact ?


Sqlite ? Mysql ?

Je viens de tester en 3.3-dev à jour sur mysql, et mise à part devoir 
supprimer le dépot principal et le remettre pour avoir les logos des 
plugins, rien de particulier : la recherche fonctionne.


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


Re: [spip-dev] Tous en débardeur !

2020-04-01 Par sujet Matthieu Marcillaud

Le 01/04/2020 à 09:18, Cerdic a écrit :
Justement Maieul a utilisé l’outil sur formidable et saisies et on se 
retrouve avec 600zips à gérer rien que pour ces 2 projets, donc c’est 
pas vraiment génial de le faire tourner sur des projets et on peut pas 
conseiller ça.


Ou alors il faut revoir l’outil pour qu’il soit moins verbeux et ne pose 
que les tags sur les dernières versions majeures par exemple ?

Sur le dernier Y.Z de chaque X.Y.Z ?


Je dirais aussi qu’il faut revoir la notion des numéros de versions des 
plugins (le .z surtout, mais aussi parfois le .y).


Actuellement certain·e·s incrémentent la version à chaque commit, ce qui 
a peu de sens (en tout cas sous git avec des tags possibles).


Une nouvelle version n’a pas lieu d’être créée à chaque commit ; 
seulement quand on juge intéressant de proposer une nouvelle version à 
télécharger, qui peut donc être un ensemble de corrections (.z), ou un 
ensemble d’ajouts fonctionnels (.y).


Et ça sera bien plus facile avec les tags en Git.

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


Re: [spip-dev] API Objet et id_parent

2020-03-31 Par sujet Matthieu Marcillaud

Le 31/03/2020 à 15:01, RastaPopoulos a écrit :

Le 31/03/2020 à 14:41, Eric Lupinacci a écrit :



En tout cas, je ne pense pas que ce soit aussi limpide que tu le prétends.

Moi si. :p


Oui, je comprends ce que dit Eric, même si le cas est peu commun.

Il suffit d’imaginer que les articles soient hiérarchisés aussi avec un 
champ id_parent (et en plus de id_rubrique) pour être un peu perturbé.


Il y a une contrainte à introduire : le id_rubrique doit être le même 
pour tous les articles enfants d’un article, sinon ça sonne bizarre.


Et à ce moment là tu peux dire le parent est :

id_parent > 0 => article / id_parent
id_parent = 0 => rubrique / id_rubrique

Peut être que Eric peut considérer cela comme le parent «principal» ?

Mais si tu peux ranger chaque article enfant dans une rubrique quelle 
quelle soit, c’est plus difficile de déterminer qui est le parent… la 
rubrique parente ou l’article parent ?


Ça me semblerait compliquer beaucoup les choses, de gérer ça (et comment 
?), pour une utilité toute relative, non ?


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

Re: [spip-dev] API Objet et id_parent

2020-03-31 Par sujet Matthieu Marcillaud

Le 31/03/2020 à 09:58, Eric Lupinacci a écrit :

Or dans objet_instituer l'id_parent n'est considéré que si je suis en 
présence d'un objet rubrique. 
Alors c’est tout l’intérêt de la déclaration de parent qui a été ajouté 
dans la déclaration d’objet éditorial.

https://core.spip.net/issues/3844

Cela dit je ne crois pas que ça soit pris en compte nativement dans SPIP 
3.3-dev actuellement, mais peut être uniquement avec 
https://git.spip.net/spip-contrib-extensions/declarerparent


En tout cas c’est quelque chose qu’il faudrait prendre en compte là où 
tu indiques.


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

Re: [spip-dev] code.spip : recherche sensible à la casse

2020-03-31 Par sujet Matthieu Marcillaud

Le 31/03/2020 à 09:30, JLuc a écrit :

Sur code.spip.net je vois que la recherche est sensible à la casse :

https://code.spip.net/spip.php?page=recherche=balise_get
ne donne aucun résultat

il faut
https://code.spip.net/spip.php?page=recherche=balise_GET


Alors justement y a eu une discussion IRC hier à propos de ça.
C’est peut être pour ça que tu réagis. Et aussi parce que ça cherche le 
mot exact si on cherche "balise GET" ça ne trouvera pas.


Comme je disais :

Ça se passe : https://zone.spip.net/trac/spip-zone/browser/spip-zone/_galaxie_/code.spip.net/spip-zora/squelettes/liste/autodoc-recherche.html#L34 et https://zone.spip.net/trac/spip-zone/browser/spip-zone/_galaxie_/code.spip.net/autodoc/trunk/templates/zora/content/recherche.twig#L40 


Mais en gros le $q est conservé pour la recherche (pas explosé sur les espaces 
pour chercher chaque mot), et on teste sur :contains() en jquery qui est 
sensible à la casse

Donc faudrait déclarer un :icontains() insensible à jQuery (en faisant des strtolower de part et d’autre), exploser $q ... 


Ça me parait un peu relou (et en plus ça va faire ramer la recherche encore 
plus)



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

Re: [spip-dev] erreur maj Bootstrap 4 SPIPr-dist LESS

2020-03-31 Par sujet Matthieu Marcillaud

Le 31/03/2020 à 00:06, dd a écrit :

Bonsoir,

J'ai voulu mettre à jour le plugin spipr sur un site en 3.2.7 mais me 
retrouve avec des erreurs.

[...]

Mais erreur coté site public :
1 LESS : Echec compilation fichier squelettes/css/spipr_dist.less
File `css/variables.less` not found. in spipr_dist.less



Boostrap 4 nécessite SCSSPHP et il faut désactiver le plugin LESS (ou du 
moins ne pas avoir de CSS .less qui surchargent les .scss utilisées dans 
le nouveau spipr-dist). Autrement dit là squelettes/css/spipr_dist.less 
est une surcharge d’une version ancienne de spipr. Maintenant c’est 
spipr_dist.scss



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

Re: [spip-dev] [Agenda vs Compositions] Erreur SQL 1052 en SPIP 3.3

2020-03-25 Par sujet Matthieu Marcillaud

Le 26/03/2020 à 00:32, Matthieu Marcillaud a écrit :

La solution simple semble être de modifier 
prive/squelettes/extra/article.html la ligne :


https://git.spip.net/spip/spip/commit/eccd3c8d1e700c3979e0a6aa861432c88e2e3006

Bon, ça c’était pas compliqué.

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

Re: [spip-dev] [Agenda vs Compositions] Erreur SQL 1052 en SPIP 3.3

2020-03-25 Par sujet Matthieu Marcillaud

Le 25/03/2020 à 17:48, Jean Marie Grall a écrit :


*Erreur SQL 1052*
Champ: 'id_article' dans where clause est ambigu
*SELECT articles.id_article, 0 as points, '', articles.titre, 
articles.lang, articles.statut, articles.id_rubrique, 
articles.surtitre, articles.titre AS titre_rang, articles.soustitre, 
articles.date FROM spip_articles AS `articles` INNER JOIN 
spip_evenements AS L4 ON ( L4.id_article = articles.id_article ) WHERE 
(articles.id_rubrique = 3) AND (L4.id_evenement = 1) AND 
id_article!=17 AND (articles.statut IN ('publie')) GROUP BY 
articles.id_article ORDER BY articles.date DESC, articles.titre*


Capture d'écran : https://pic.infini.fr/gallery#PEImzDWT/HIzuWQcR.png

L'erreur apparait sur l'url 
*/?exec=article_article=17_evenement=1/* mais pas 
*/?exec=article_article=17/* et si je passe par le menu Édition > 
Événement > Créer un événement, je n'ai pas cette erreur car je suis 
l'url */?exec=evenement_evenement=5/*.


Ok.

Alors, pas besoin de compositions.

Le problème semble venir de prive/liste/articles.html, utilisé sur le 
bloc "Dans la même rubrique". Il liste les articles avec le critère 
{id_?} et {where?} ; id_ développe plusieurs identifiants, dont 
{id_evenement?} et le {where?} contient 'id_article!=1'.


Le where n’indiquant pas l’alias de table (article.id_article!=1), cela 
crée pour mysql un champ ambigu.


La solution simple semble être de modifier 
prive/squelettes/extra/article.html la ligne :


- #SET{where,#VAL{id_article!=}|concat{#ID_ARTICLE}}
+ #SET{where,#VAL{articles.id_article!=}|concat{#ID_ARTICLE}}


Cela dit, le cadre des articles "dans la même rubrique", qui filtre la 
liste d’articles sur d’autres ids que id_rubrique, je sais pas si c’est 
une bonne idée en soit.


Et effectivement avant l’introduction du critère `{id_?}` on ne voyait 
pas entrer `{id_evenement?}` dans cette liste d’articles, donc le bug ne 
se produit qu’à partir de SPIP 3.3.


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

Re: [spip-dev] noiZetier - disparition de l'icone "édition d'une noisette" avec SPIP 3.3

2020-03-09 Par sujet Matthieu Marcillaud

Le 09/03/2020 à 14:53, Eric Lupinacci a écrit :


[(#CHEMIN_IMAGE{edit-24}|balise_img)]


Je ne me rappelle pas d’une quelconque écriture où on aurait omis 
l’extension ici ; je suppose que ça marchait par hasard du coup :)


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

Re: [spip-dev] Proposition pour la génération de archivelist

2020-03-06 Par sujet Matthieu Marcillaud

Le 06/03/2020 à 20:21, Maïeul Rouquette a écrit :

Si je comprend bien ta perspective, toi tu envisage une amélioration 
drastique du système de distribution/d'install de paquet pour une future 
version de SPIP. Avec possibilité de choisir précisement la version du 
plugin qu'on veut installer, et en s'appuyant sur composer.


Oui (si tu parles de Composer directement), et non.

Non parce que l’idée dans un premier temps surtout était bien de faire 
générer par l’outil un équivalent du dépot xml de SPIP, pour que ça 
fonctionne avec SVP justement.


Moi j'ai un problème concret : avec la version actuelle de SPIP, comment 
est-ce que j'installe automatiquement via SVP un plugin qui est déposé 
sut git.spip.net ? Pour cela il faut qu'il soit dans le depot.xml standard.


Oui, on est d’accord. J’ajoute pourquoi uniquement git.spip.net ?

Parce que là en gros on me dit : il faut pas mettre ton plugin sur svn, 
uniquement sur git. Mais pas moyen pour autant de l'installer. Ca veut 
dire qu'on fait quoi en attendant ?


C’est un problème qu’on sait arriver depuis longtemps.

Bref, je ne dis pas que ton travail est inutile, et je pense même le 
contraire. Mais c'est un travail sur du moyen terme.


Ma démarche était

- soit de repartir de smart-paquet, mais il faut intégrer tout le machin 
Git dedans, et ça ne marchera que pour SPIP et son depot.xml à terme 
(pas du tout adapté à Composer)
- soit de partir de Satis (qui fait tout ce qui faut pour Composer déjà, 
est documenté et testé), en tentant de l’utiliser en attendant pour le 
format SPIP. Mais c’est aussi un chantier.


Tu peux bien tenter d’améliorer smart paquet si tu veux.
Mais construire de toute pièce un nouvel outil me semble inapproprié.


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

Re: [spip-dev] Proposition pour la génération de archivelist

2020-03-06 Par sujet Matthieu Marcillaud

Hello,

> J'ai donc produit une v2 du cahier des charges suite aux différentes
> remarques.
>
> 
https://git.spip.net/spip-contrib-outils/archives_from_gitea/src/branch/master/README.md 



Alors, moi je ne partage pas entièrement ce cahier des charges déjà

- ça serait bien de s’approcher de ce que font Packagist ou Satis : tu 
donnes l’URL du dépot GIT, il se débrouille avec ça pour créer la liste 
des paquets / versions possibles, stocke les zips des tags, permet de 
récupérer quand même les branches à jour (@dev-master) si besoin, etc...


- ça limite à Gitea, alors que d’autres projets peuvent être ailleurs, 
de façon temporaire ou non. Et je trouve ça assez dommage de s’en priver 
; non ?



## Satis

J’avais commencé à regarder / détourner Satis

Satis sert à générer des dépots Composer, c’est à dire un fichier .json 
(enfin plusieurs, mais bref) un peu comme notre 
https://plugins.spip.net/depots/principal.xml qui liste des paquets et 
leurs versions, avec les chemins pour les télécharger.


Si on va réellement vers l’idée d’utiliser Composer à terme, tout en 
restant sur git.spip.net (donc pas Packagist.org directement), il faudra 
faire générer un dépot Composer adéquat, il faudra utiliser Satis, ou un 
packagist à nous, ou réécrire la roue...


Si on arrivait à avoir un outil, pour notre problème actuel, qui 
s’appuie sur Satis, avec à peu près la même configuration, la transition 
serait peut être plus simple (une fois que SPIP utilise Composer, on 
bascule sur Satis sans surcharge...). À vrai dire j’y crois moyennement 
car ça va hurler (pas de traduction, pas de logo dans les composer.json 
...) ; mais c’était l’idée.



### Fonctionnement Satis

À Satis, on lui donne une liste de dépots git (github, gitlab) (il ne 
sait pas bien faire avec Gitea par défaut), il les analyse en cherchant 
leurs fichiers composer.json dans chaque branche / tag et s’il en trouve 
décrit alors le paquet, et si c’est un tag, télécharge ou crée le zip 
localement (selon les possibilités du driver (github, gitlab, ...) / api 
utilisée)


Bref, Satis :
- ne fonctionne qu’avec des fichiers composer.json.
- collecte localement les zips des tags (mais pas des branches)

### Détournement Satis

Ce que j’ai commencé, début janvier (puis j’ai fait d’autres choses donc 
c’est stand by) c’est un outil qui s’appuie sur Satis (qui lui même 
s’appuie sur Composer), mais qui surcharge certains de ses comportements.


1) j’ai ajouté un driver Gitea (partiel) ; au moins il sait récupérer 
des fichiers et des zip en passant par son API


2) je «fake» un fichier composer.json virtuel s’il n’en existe pas dans 
la branche / tag ... Actuellement c’est très rudimentaire, mais l’idée 
était d’analyser paquet.xml / plugin.xml / lang/ pour obtenir quelques 
infos en plus)


Avec cela déjà ça stocke localement les zips des tags des dépots 
concernés. (et ça crée le fichier de dépot composer, totalement inutile 
pour nous).


C’est là où j’en étais.

Mon idée était donc pour continuer :

- d’analyser paquet.xml (etc.) pour améliorer le faux composer.json
- d’ajouter un export «principal.xml» qui génèrerait l’équivalent, si 
c’est possible, de ce qu’on avait auparavant.


Mais déjà dans mes tests, j’ai vu quelques problèmes :


- Satis fait appel aux APIs des drivers pour obtenir le fichier 
composer.json de chaque tag (déjà c’était long), mais s’il le trouve 
pas, il va falloir analyser paquet.xml, plugin.xml, lang/ ce qui va 
faire beaucoup d’appels et risque d’être encore plus long. Composer (et 
consœurs) ne s’appuient que sur 1 seul fichier, c’est peut être pas pour 
rien.


- Pour dire à Satis de ne réanalyser que "spip/medias" par exemple, ça 
sous-entend que :
-- soit on a déclaré en amont "spip/medias" dans la liste des dépots git 
à traiter (donc son "name" en plus de l’url de GIT),
-- soit Satis doit analyser l’ensemble des dépots listés (via leurs 
composer.json) pour déterminer lesquels ont "spip/medias" dedans ce qui 
est aussi très long.


Du coup, il semble judicieux de déclarer systématiquement la déclaration 
"name" en plus de l’url, ce qui ressemble à :


{
"type": "vcs",
"name": "spip/medias",
"url": "https://git.spip.net/spip/medias;
},

Et on ne peut pas alors déclarer 2 fois le même "name".

Voilà, j’étais là… puis j’avais regardé la tête d’un fichier d’un dépot 
xml chez SPIP, et vu des balises ``… je m’étais demandé 
pourquoi parbleu ces trucs étaient dedans alors que ça sert nul part… et…


Puis je suis allé faire de la musique…

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

Re: [spip-dev] https://syntaxe.spip.net/

2020-02-25 Par sujet Matthieu Marcillaud

Le 25/02/2020 à 18:00, JLuc a écrit :

Le 25/02/2020 à 15:41, Eric Lupinacci a écrit :

Avec Vivaldi ça dépend pas de la saison ?


L’autre jour on a croisé une police de caractère dont le gras se voyait 
très mal sur chrome / safari, bien que réellement présent. C’est peut 
être le même souci ici ?


Firefox me dit que j’utilise Palatino Bold sur ce site. Et je vois bien 
les graisses sur Safari / Chrome.


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

Re: [spip-dev] repo dans l'orga spip ?

2020-02-04 Par sujet Matthieu Marcillaud

Le 04/02/2020 à 08:39, Eric Lupinacci a écrit :

Je ne suis pas un spécialiste et je me trompe peut-être mais ce n'est 
pas une préfiguration de l'organisation pour Composer ?


C’était tout à fait pour cela.

Composer remplace des répertoires lorsqu’il met à jour quelque chose. Et 
remplacer la racine, ça marche moyen :) Du coup, il y a ce découpage en 
éléments distincts.


Avec un plugin Composer, on peut dire «ce paquet de type spip-ecrire» va 
ici (ecrire/), celui là de type spip-prive va là (prive/). Et Composer 
peut gérer les mises à jour (dès lors qu’il peut écrire à cet endroit).


Sous entendu que les fichiers racines ne sont jamais mis à jour 
directement (et sont chargés la première fois via un `composer 
create-project`).


Sous entendu aussi qu’idéalement c’est une solution temporaire 
(probablement de longue durée), mais il faudrait tendre vers une 
structure plus conventionnelle (vendor/ public/ config/ src/ ...).



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

Re: [spip-dev] gitea validation PR dans spip-contrib-extension

2020-01-21 Par sujet Matthieu Marcillaud

Le 21/01/2020 à 15:14, Maïeul Rouquette a écrit :

Le 21/01/2020 à 13:44, chanka...@choc0.net a écrit :

hello,
comment ça devrait se passer à partir de celle-ci par exemple ?
https://git.spip.net/spip-contrib-extensions/spip-pmb/pulls


la personne qui "suit" le projet devrait recevoir une notification et 
pourrait décider d'un merge. Sinon toute personne qui a le droit sur le 
repos, sans forcément suivre le projet, peut décider le merge aussi :)


Comme personne ne suit encore réellement les projets… Si y a pas de 
mail, ça va passer à la trappe :p


J’ai validé celui là pour sûr.

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

Re: [spip-dev] Organisation de la forge Git de SPIP

2020-01-21 Par sujet Matthieu Marcillaud

Salutations,

Je prends enfin un petit temps pour répondre :)

Tout d’abord, merci d’avoir pris le temps de ces changements et d’écrire 
toutes ces informations et résumés.


Je vais rebondir un petit point.

Le 19/01/2020 à 19:29, Eric Lupinacci a écrit :

[...] à savoir :
- spip
- spip-contrib-extensions
- spip-contrib-squelettes
- spip-contrib-themes
- spip-contrib-outils
- galaxie


[...]

L'organisation "galaxie" contient l'ensemble des sites de la galaxie. 
Elle est publique mais accessible en écriture uniquement par une *équipe 
nommée "galaxie"* qui correspond à l'équipe noyau de SPIP et de quelques 
contributeurs additionnels assurant le développement de certains sites.


Merci d’avoir préfixé les éléments de la zone par un nom d’organisation 
(spip-contrib) ;


J’aurais préféré cependant pour «Galaxie» qu’également il y ait un 
préfixe «spip-» ; donc «spip-galaxie», cette organisation pourrait alors 
être utilisée en vendor d’éventuel composer.json futur sur ces projets là.


Pour l’organisation «spip» vs «spip-core», cela me semble bien moins 
gênant ; «spip» convient, me semble-t’il très bien en tant 
qu’organisation du core.


En tout cas, merci.

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

Re: [spip-dev] GMANE

2020-01-16 Par sujet Matthieu Marcillaud

Le 16/01/2020 à 10:35, contact a écrit :
Je n'arrive pas à lire les listes via newsgroup avec Thunderbird. C'est 
moi le seul ou quelqu'un a des problèmes aussi ?


Il faut passer par news.gmane.io (à la place de news.gmane.org) en 
reconfigurant.


Clic droit sur news.gmane.org > renommer le titre
PUIS (surtout)
> paramètres du serveur > nom du serveur > news.gmane.io
il va te retélécharger les entêtes de chaque abonnement que tu avais 
(lorsque tu cliques dessus la première fois).


https://lars.ingebrigtsen.no/2020/01/15/news-gmane-org-is-now-news-gmane-io/

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


Re: [spip-dev] Contrib et spip 3.3

2020-01-06 Par sujet Matthieu Marcillaud

Le 05/01/2020 à 22:53, Maïeul a écrit :
Pour info, je viens de modifier le script de synchro des plugins sur 
contrib pour que cela ajoute l'étiquette 3.3. automatiquement aux 
plugins concernés.


OK.

--
(simple petit test en mettant juste la liste gmane)

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


Re: [spip-dev] Commits de Salvatore bloqués depuis vendredi

2020-01-06 Par sujet Matthieu Marcillaud

Le 06/01/2020 à 10:02, Jacques B a écrit :

Bonjour Kent1,
Les commits de Salvatore ne sont plus générés depuis vendredi matin. 
Est-ce que tu peux arranger ça ?


C’est peut être en relation avec le travail de Cédric sur cet outil ; il 
va peut être falloir attendre 1 semaine pour la correction si c’est cela.


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

Re: [spip-dev] Git des plugins SPIP - Plugins/squelettes à intégrer

2019-12-26 Par sujet Matthieu Marcillaud

Le 26/12/2019 à 09:34, Cerdic a écrit :

  - permettre d’exclure des éléments du zip comme composer.json le 
permet, cf 
https://github.com/scssphp/scssphp/blob/master/composer.json#L41 

[...]
Et -il faut vérifier- je suppose que gitea doit supporter la syntaxe du 
composer.json et donc la possibilité d’exclure du contenu du zip, donc 
je pense que la première solution est celle vers laquelle il faudrait 
aller...


J’ai comme un doute sur cette déclaration "archive" qui semble utilisée 
uniquement si c’est Composer lui-même qui crée les archives (via Satis 
par exemple). Mais pas lorsque ça utilise donc des zips de forges 
(github, ...). En tout cas c’est ce que semble dire 
https://stackoverflow.com/a/48869735


C’est utilisé (quasiment) uniquement dans 
https://github.com/composer/composer/blob/master/src/Composer/Package/Archiver/ArchiveManager.php


Satis l’appelle là : 
https://github.com/composer/satis/blob/master/src/Builder/ArchiveBuilder.php#L45


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


Re: [spip-dev] BigUpload pourrait accepter les vidéos ?

2019-12-19 Par sujet Matthieu Marcillaud

Le 19/12/2019 à 20:18, bibi a écrit :

On 19/12/2019 10:09, Matthieu Marcillaud wrote:


Heu… tu as testé le plugin ?
Tu peux bien uploader 3 kilos de patates que ça pourrait marcher ; 
tant que c’est un fichier numérique :p


Bon j'avance mais là je donne ma langue aux chats :)
Je veux faire un formulaire de up pour un plugin pour mettre une vidéo 
dans un background.


Avec ce code

[(#SAISIE{
 bigup,
 head_bg_img,
 token=#BIGUP_TOKEN{head_bg_img,multiple=non},
 label=Vidéo de fond,
 previsualiser=oui,
 accept=.mp4})
]


Tu pourrais utiliser la #SAISIE_FICHIER, un rien plus pratique,
mais ton problème est surtout que tu as mal compris ce que fait bigup, 
en tout cas ce que permet cette saisie : ça uploade un fichier dans tmp/ 
(supprimé s’il n’est pas utilisé), ça peuple $_FILES avec ce fichier, 
comme si tu utilisais un input de type file tout à fait normalement.


Tu en fais ensuite ce que tu veux, dans le traiter de ton formulaire. 
Par exemple en utilisant une fonction d’ajout de document à la 
médiathèque si c’est ce que tu veux.


Donc, imagine (ou fait fonctionner ton CVT) avec un input de type file, 
et une fois que ça marche, ajoute bigup par dessus.


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

Re: [spip-dev] BigUpload pourrait accepter les vidéos ?

2019-12-19 Par sujet Matthieu Marcillaud

Le 16/12/2019 à 14:15, bibi a écrit :
Voilà, tout est dans le titre, peut-on faire en sorte que big accepte 
les vidéos mp4, par exemple ?


Heu… tu as testé le plugin ?
Tu peux bien uploader 3 kilos de patates que ça pourrait marcher ; tant 
que c’est un fichier numérique :p


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

Re: [spip-dev] r119102 - in _plugins_/couleur_objet/trunk

2019-12-17 Par sujet Matthieu Marcillaud

Le 17/12/2019 à 17:24, Eric Lupinacci a écrit :

Oui mais non.
Objet_couleur_lire indique que la notion lue est couleur_objet ce qui me 
paraît être le cas.


Objet_lire_couleur indique que l’on lit la couleur de l’objet mais bon. 


La théorie de Rasta est de dire "ça concerne un objet", ça concerne sa 
couleur => objet_lire_couleur() quelque soit le comment on gère 
l’information de couleur derrière. Ça se tient aussi, mais ça cache 
effectivement l’implémentation technique derrière.


Enfin bataillez maintenant, je suivrais ! :)

MM.


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

  1   2   3   4   5   6   7   8   9   10   >