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

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

2019-12-17 Par sujet Matthieu Marcillaud

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

Hello,

Quand je définis une API je prend toujours l'ordre "anglais" pour le 
nommage à savoir :

objet_fonction().

[...]

On m’a fait un procès («il faut "objet_" en premier»), alors j’ai changé 
pour :

- objet_lire_couleur()
- objet_modifier_couleur()
- objet_supprimer_couleur()

J’espère que ça ira :)

Mais techniquement derrière ça tape dans une table de liens 
spip_couleur_objet_liens, sur un champ "couleur_objet".



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] Contrib - Gros souci depuis quelques minutes

2019-12-08 Par sujet Matthieu Marcillaud

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

Re,

Bon j'ai viré les dépôts et je les ai recréé.


Il manquait juste un petit up sur SVP :)

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] SPIP 3.3 et #LOGO_ARTICLE/RUBRIQUE

2019-12-04 Par sujet Matthieu Marcillaud

Le 16/10/2019 à 13:21, Jean Marie Grall a écrit :

Salut,

j'ai un changement de comportement en 3.3 avec les logos article et 
rubrique.


En 3.2, j'utilise le filtre |image_responsive (du plugin du même nom) 
comme ça :


[(#LOGO_ARTICLE|image_recadre{300:100, -, focus}|image_responsive{300})]

En 3.3, ça ne fonctionne plus car #LOGO_ARTICLE inclut désormais 
plugins-dist/medias/modeles/logo.html qui prend bien en compte 
|image_recadre mais pas |image_responsive.


Pour corriger ça, j'utilise |extraire_attribut{src} qui évite de passer 
par l’inclure :


[(#LOGO_ARTICLE|extraire_attribut{src}|image_recadre{300:100, -, 
focus}|image_responsive{300})]


Je ne vois pas trop ce que ça «éviterait». Juste que le filtre 
|image_recadre tente de trouver une image qui n’est peut être pas la 
bonne maintenant que le modèle n’est plus le même, alors que 
|extraire_attribut{src} y arriverait mieux ?


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] Plugin "Archivage de contenus" - feedback utilisation lister_champs_selection_conditionnelle

2019-11-22 Par sujet Matthieu Marcillaud

Le 20/11/2019 à 11:08, Eric Lupinacci a écrit :
[...]
Pour cela j'ai utilisé le critère {id_?} et le pipeline 
lister_champs_selection_conditionnelle.

Voilà mon feedback et quelques idées d'évolutions à discuter.


Ce que je voulais exprimer en indiquant que ce pipeline n’était peut 
être pas une bonne idée, c’est justement un cas comme tu présentes, qui 
appelles un autre champ que "id_qqc" (il y a déjà "objet" parfois aussi 
de mémoire). C’est pour cela que je pense que {id_?} ou {id_*?} est 
correctement nommé, pour l’usage que je lui supposais.


Peut être qu’il faut alors un autre critère, et peut être pas de 
pipeline sur le premier d’ailleurs) pour ton/cet autre usage.


Ou sinon, comme tu dis, il faut renommer le critère pour quelque chose 
de plus général, mais les noms que tu proposes me laissent plutôt 
perplexe, notamment car ça n’a rien à voir techniquement avec le critère 
{where}.



_Le fonctionnement recherché pour les listes d'objets :_
1- si aucun critère d'archivage n'est précisé (explicite ou implicite 
via id_?) je n'affiche pas les objets archivés

2- on doit pouvoir afficher que les objets archivés
3- on doit pouvoir afficher tous les objets archivés ou pas


Il y a également un problème d’ordre dans les critères ; pour que {id_?} 
et l’appel de ton pipeline puisse détecter que le critère "archive" est 
utilisé, cet appel à archive doit arriver avant le critère id. ie.: 
{archive=1}{id_?} et pas {id_?}{archive=1} ;


Ce qui est déjà en soit une limitation sur {id_?} .

[...]

Après, lors de la discussion qui a mené à cette implémentation, il avait 
été proposé d'appeler une fonction de calcul du critère si elle existe : 


Tu peux rafraichir nos mémoires parce que je ne vois pas à quoi ça 
pourrait faire allusion ?


ce n'est pas le cas actuellement et ça serait bien de l'introduire car 
dans mon cas je suis obligé de capturer a posteriori , via le pipeline 
post_boucle, le where calculé par le critère id_ pour le modifier étant 
donné qu'il n'introduit pas la valeur par défaut (tout sauf les 
archives) si aucune variable "est_archive" n'est définie dans 
l'environnement.


C’est bien ce qui me fait dire que ce n’est pas le même besoin, et donc 
probablement pas le même critère ou le même mécanisme à utiliser.


[...]

Il faut en discuter donc :)

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] Plugin "Archivage de contenus"

2019-11-18 Par sujet Matthieu Marcillaud

Le 18/11/2019 à 09:05, Eric Lupinacci a écrit :

Re,


Le lun. 18 nov. 2019 à 08:16, Eric Lupinacci > a écrit :


Relancer le chantier qu'avait commencé James d'ajouter un
pipeline pre_compilation permettant de modifier la demande même
d'une boucle précise d'un squelette précis avant même que ce
soit compilé ?

Pour au contraire pouvoir VIRER {id_mot?} du core, et pouvoir
l'ajouter par le plugin, et pareil pour tnt d'autres
besoins. Déjà qu'on voudrait virer pour les mots, ça serait pas
pour se rajouter des nouvelles dépendances dans le core. :)


Oui j'ai pensé à un truc comme ça qui avait été envisagé il me
semble lors de la discussion sur id_mot non ?
Mais quand même pratiquement injecté id_mot? ou est_archive? dans
une boucle c'est bien mais comment on détermine la "bonne" boucle ?
On a encore le thread de cette discussion ?


Tiens j'ai relu le thread suite au commit de Touti sur id_mot (j'ai pas 
retrouvé la discussion de James).
Et je me dis que l'on balance pas mal de conditions en plus et qui sont 
uniquement dédiées à un id_xxx.
On ne pourrait pas configurer dans la déclaration d'un objet cette liste 
de possibilité, ce qui permettrait de mettre autre chose que des id_xx ?


Regarde déjà en 3.3-dev cela : critere_id__dist()

https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/criteres.php#L1598

Critere {id_?} et pipeline `lister_champs_selection_conditionnelle`

Je sais pas si c’est une bonne idée, mais c’est en tout cas possible.

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] Composer, Packagist, gitea, gitlab et github sont dans un bateau

2019-10-21 Par sujet Matthieu Marcillaud

Le 21/10/2019 à 10:06, RealET a écrit :


Donc, pour ces cas d'usage, j'aurais besoin :

huhu, vas-y, fais tes courses !


- d'un script qui transforme une installation pure SVN en pure Git
- d'un script de mise à jour des plugins (on ne peut pas faire git pull 
*, il est nécessaire de le faire dossier par dossier)

Un exemple (bash)

for i in $(ls); do if [ -d $i ]; then cd $i; git pull --autostash; cd 
..; fi; done



- de comprendre comment remonter à n commit en arrière


Remonte 2 commits de là où tu es :
git co HEAD~2

Retourner quelque part après :
git co master
git co v1.2.0
...


- de comprendre comment changer de branche (svn sw)

git co branche
git co tag

Mais ça ne concerne que le GIT en cours (pas les plugins-dist dans spip 
par exemple)

Sinon, faut utiliser un des outils mentionnés.


Variante : si j'ai bien compris, composer pourrait faire le boulot.
Mais seulement sur des versions stables, pas possible de récupérer une 
version en dev ?

Si. Tu peux même être très précis (indiquer le numéro de commit par exemple)


En attendant, la synchro git<->svn est une nécessité.
Une nécessité pour toi peut être. C’est aussi ton boulot de migrer de 
l’un à l’autre...


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] Paquet.xml et pipelines en dernière position : DTD ?

2019-10-02 Par sujet Matthieu Marcillaud

Le 02/10/2019 à 15:34, Cerdic a écrit :
[...]
- soit un attribut homonyme de sa valeur genre « last » qui peut prendre 
la valeur « last »  uniquement
- soit carrément on améliore pour un attribut plus générique genre 
« position » ou « priorite » qui pourrait prendre les valeurs « first » 
ou « last » avec la possibilité peut-être un jour d’accepter des 
positions numériques ?


Priorité, ou position semble plus indiqué quitte à ajouter quelque 
chose, non ?


Je ne pense pas corriger le bug en 3.2, c’est pas fondamental, et en 3.3 
on a l’avantage de s’être débarrassé du plugin.xml, donc plus 
d’équivalence à gérer…
Mais par contre est-ce qu’on pourra éviter une erreur si ce même 
paquet.xml est utilisé en 3.2 ou 3.1 (même sans prise en compte de 
l’attribut) ?


J’ai une belle erreur dans l’admin des plugins de 3.3 ou 3.2 dès qu’on 
ajoute un attribut qui n’est pas censé exister.


Du coup je doute qu’on puisse éviter le problème sur les installations 
existantes, sans mise à jour de SPIP ou sans branche dédiée pour les 
plugins...


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] Fiche auteur : ajouter un champ "prenom"

2019-09-17 Par sujet Matthieu Marcillaud

Le 17/09/2019 à 16:13, Manu a écrit :


Ah, cool, il a l'air très bien ce plugin...
Comment peut-on faire un svn co pour le récupérer ? D
'une manière plus générale, comment faut-il faire pour "SVNiser"


Si tu veux une équivalence rapide (et fausse) :

git clone https://github.com/nd-/auteur_nom_prenom.git
~= svn checkout https://github.com/nd-/auteur_nom_prenom

Ensuite, cd auteur_nom_prenom
git pull
~= svn up



projets qui sont sur github (et apparentés) ?


Github fournit une passerelle SVN directement, aucun autre ne fait cela.
Tu devrais apprendre de préférence les bases de Git (clone / pull / 
checkout ; puis push / rebase / stash / log / diff ...) . Ça te sera 
plus utile :)


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] Compatibilité SPIP et PHP

2019-09-16 Par sujet Matthieu Marcillaud

Le 16/09/2019 à 18:43, Bruno Bergot a écrit :

Hop,

Le 16/09/2019 à 18:40, Eric Lupinacci a écrit :

Est-on sur de la compatibilité PHP 7.2 du groupe SPIP+plugins-dist ?

Oui, on a plein de SPIP 3.2 qui tournent sans pb en PHP 7.2.22-1 chez 
Infini :)


Alors pour SPIP 3.2 + plugins-dist, avec cette toute nouvelle version, 
je pense qu’il y a plus aucune erreur à ma connaissance (pas de warnings 
disgracieux) ;


Il reste cependant des deprecated avec PHP 7.3 par contre en 3.2.
Ils ont été tous soigneusement corrigés (à ma connaissance) en SPIP 
3.3-dev + plugins-dist.


De même l’essentiel des deprecated php 7.4 sont corrigées en SPIP 
3.3-dev + plugins-dist


On voit cependant passer en 7.2 encore parfois quelques warnings sur des 
count() dans certains autres plugins / squelettes qu’il faut corriger. 
(cf. en bas de https://www.php.net/manual/fr/migration72.incompatible.php)


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] [BigUP/SPIP 3.3] Non intégré dans ecrire/?exec=document_edit_document=NNN

2019-08-21 Par sujet Matthieu Marcillaud

Le 20/08/2019 à 21:45, RealET a écrit :

Matthieu Marcillaud a écrit le 20/08/2019 à 16:46 :
Bon, bah une version 1.0.1 est à tester avec la vignette et le 
changement de document. Je n’ai pas vu de collision particulière (mais 
je n’utilise pas de zone étendue pour recevoir les fichiers)

J'ai mis des commentaires dans le commits
https://github.com/marcimat/bigup/commit/cf62d9d53855854d7be024ac837fb1ae04ee7282#diff-7b05575547d02f8a569140f32bcc3eadR234 


Est-ce que c'est une bonne méthode ?

Probablement, mais ça ne garantit pas de réponse hein !

J’ai envoyé une version 1.0.2

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] [BigUP/SPIP 3.3] Non intégré dans ecrire/?exec=document_edit_document=NNN

2019-08-20 Par sujet Matthieu Marcillaud

Le 20/08/2019 à 11:24, RealET a écrit :

Cerdic a écrit le 20/08/2019 à 10:59 :

Sur la vignette ça doit être gérable sans trop de difficulté.

Sur le « changer » j’avais vu et c’est volontairement que je n’ai pas 
essayé de le mettre car je pressens qu’il va y avoir collision (mais 
peut-être pas, à vérifier), entre les formulaires et conteneurs 
target, notamment quand l’edition de document s’ouvre en popin sur une 
page d’article qui a elle même déjà un ou deux formulaire d’upload 
d’ajout de document/logo


Bon, bah une version 1.0.1 est à tester avec la vignette et le 
changement de document. Je n’ai pas vu de collision particulière (mais 
je n’utilise pas de zone étendue pour recevoir les fichiers)


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] [BigUP/SPIP 3.3] Non intégré dans ecrire/?exec=document_edit_document=NNN

2019-08-20 Par sujet Matthieu Marcillaud

Le 20/08/2019 à 09:51, RealET a écrit :

Bonjour,

C'est que du bonheur BigUP !
Mais il reste un endroit de SPIP où il n'est pas intégré : la 
médiathèque quand on *change* un fichier.


J’ai vu un autre endroit aussi : lorsqu’on ajoute une vignette de 
document (ou la modifie)

___
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] Nombre et noms des organisations Git

2019-08-12 Par sujet Matthieu Marcillaud

Le 11/08/2019 à 01:56, RastaPopoulos a écrit :



En fait le nombre est fonction de quoi exactement ?
D'une stratégie Composer ou d'une stratégie d'autorisation de
modification ou les deux ou autres ?


Uniquement de qui s'en occupe. Donc le nom ne doit pas avoir trop de
rapport avec qu'est-ce qu'on met dedans, c'est vraiment qui s'en occupe.


Oui, l’organisation, ça correspond en gros à «qui» a en charge les 
choses qui sont dedans», pas forcément donc à quoi est dedans.


Idéalement, et par convention, l’organisation est la même que le 
"vendor" utilisé dans composer (comme l’a déjà indiqué azertyu, ça n’a 
rien d’obligatoire, c’est juste plus pratique pour tout le monde, et 
c’est ce qui est fait à peu près partout). Donc si "spip/spip" => 
organisation "spip".


Et je rejoindrais Rasta (je crois du moins) sur le fait que 
l’organisation c’est "qui" détiens le droit. Si y a plusieurs noms 
d’organisations, mais avec le même ensemble de personnes qui ont les 
droits, il me semble qu’il vaut mieux 1 seule organisation pour ça.


Ceci étant dit, il faut quand même dire aussi que suivre l’ensemble des 
modifications sur les projets GIT d’une organisation (disons spip-zone 
où il risque d’y avoir le plus d’activité) sera plus difficile 
qu’actuellement en SVN.


Je ne trouvais pas notamment comment voir l’activité des commits de 
l’organisation _plugins_ entière (https://git.spip.net/_plugins_) [ 
aparté : gitlab le permet depuis un bouton "Activité" bien visible. 
Finalement c’est faisable avec Gitea aussi (si on fait partie de 
l’organisation) https://git.spip.net/org/_plugins_/dashboard en cliquant 
(comme sur github d’ailleurs) le logo en haut à gauche (sous Tableau de 
bord).


J’appréhende quand même un poil l’ouverture en 'push' de tous les 
plugins à tout le monde, vu déjà les erreurs sous SVN, me disant que 
c’est peut être pas la meilleure idée dans le monde GIT (on peut forker 
si on veut améliorer un plugin, ou éditer en ligne et proposer des PR).


Ça tendrait plus à avoir des rôles plus fins au niveau de chaque ou 
certains projets / plugin, ou les autrices et auteurs mainteneurs 
pourraient décider ou non d’ouvrir l’accès en écriture à tous les 
membres, ou seulement à certaines personnes. Mais je conçois que c’est 
pas très cool de brider comme ça.


Mais dans ma caboche, j’imagine plus facilement une organisation 
"SarkaSpip" avec son squelette, ses thèmes, ses mainteneurs, qu’une orga 
"spip-zone" qui les contiendrait, par exemple.


Bon, après il suffit de dire que celleux qui veulent ça ont qu’à aller 
ailleurs que sur la zone...


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] [SPIP Zone] Mise à jour git.spip.net

2019-08-10 Par sujet Matthieu Marcillaud

Le 10/08/2019 à 11:42, Cerdic a écrit :
Oui alors, va quand même falloir arrêter avec cet argument de « si on 
est pas sur github on sera pas sur packagist et du coup les gens 
pourront pas installer leur package depuis composer sans faire des 
manips compliquées »


1/ on est d’accord sur le point 1 qu’il suffit d’avoir spip/spip sur 
packagist > pour que tout le « composer create spip/spip » fonctionne et
qu’ensuite sur un projet SPIP tu peux installer tous les packages que tu 
veux depuis packages.spip.net, sans aucune manip supplémentaire


Oui, enfin, il me semble que si packages.spip.net est un repository de 
type packagist ou gitlab, bitbucket, github, il pourra récupérer les 
zip, sinon il ne pourra récupérer que les sources git (ce qui est plus 
long pour les installations). Cf méthode getDist() des VCS là 
https://github.com/composer/composer/tree/master/src/Composer/Repository/Vcs


Si Gitea est parfaitement compatible avec l’Api Github, peut être que ça 
fonctionne.


[...]


et pouf on a un package sur packagist à jour automatiquement.
Passer à Github pour éviter un curl, c’est quand même un peu le comble…

Et je rappelle que dans tous les cas, github ou pas, il faut aller 
soumettre chaque projet sur Packagist manuellement la première fois.
On ne trouvera donc que les packages qui auront été publié là-bas, dans 
une démarche volontaire et consciente (pas de magie)


Oui. Tout à fait.
Enfin s’ils sont déclarés sur Packagist, déclarer notre "repository" 
dans spip/spip ne sert plus à grand chose je crois.


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] [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet Matthieu Marcillaud

Le 07/08/2019 à 14:12, cam.la...@azerttyu.net a écrit :

Salut



du point de vue utilisateur :
* la page d'accueil peut être personnalisée (pendant longtemps c'était
uniquement dans l'offre payant de gitlab)
* le support multilangue
* la personnalisation du theme (boussole qui sert à naviguer dans notre galaxie)
* le suivi/disponibilité des mainteneurs du projet (oui je me répete
car cela impacte aussi l'usage quotidien)


Je ne suis pas certain qu’on parle tout à fait de la même chose en terme 
d’ergonomie et d’utilisation ; cependant j’ai quand même le sentiment 
que ça s’améliore au fil des versions de Gitea.


Il reste néanmoins un souci de lenteur d’affichage, sur certaines pages 
particulièrement. Juste pour un petit exemple :


- https://github.com/spip/SPIP/tree/master/ecrire (affichage 
relativement instantané)
- https://git.spip.net/SPIP/spip/src/branch/master/ecrire (Page: 
26262ms) (j’ai pas eu moins de 18s ici)


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] r24351 - in spip: . ecrire ecrire/action ecrire/inc ecrire/maj

2019-07-30 Par sujet Matthieu Marcillaud

Le 30/07/2019 à 16:09, Luis Speciale a écrit :

Le 30/07/2019 à 16:01, Matthieu Marcillaud a écrit :

 Si j’exécute une

par une je n'arrive pas à reproduire, ce n'est que quand je réinitialise
tout


Tentes 'Optimiser', très efficace :)

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] r24351 - in spip: . ecrire ecrire/action ecrire/inc ecrire/maj

2019-07-30 Par sujet Matthieu Marcillaud

Le 30/07/2019 à 15:44, Bruno Bergot a écrit :

Hop,

Le 30/07/2019 à 14:53, Luis Speciale a écrit :

Le 30/07/2019 à 14:17, Cerdic a écrit :

En effet comme tu l’as fait remarqué sur IRC il restait un cas de test
sur id_objet qui excluait siteon0
Ça devrait être bon maintenant :)


Est-ce que chez vous ça résiste une réinitialisation de la liste des
travaux ? Si je réinitialise je perds le logo site


Aucun problème de mon côté, mon logo de site reste bien en place.


Oué, sisi je reproduis : réinit travaux > admin plugins > identité > 
plus de logo de site.


Et en fait le cron de nettoyage des liens morts doit passer par là 
certainement :) Oui un lien vers site-0 c’est un lien mort :)


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] Formulaire générique d'édition d'un objet et Saisies

2019-07-22 Par sujet Matthieu Marcillaud

Le 22/07/2019 à 18:14, Matthieu Marcillaud a écrit :

Le 22/07/2019 à 17:42, Eric Lupinacci a écrit :

C'est sur que de toute façon il aurait fallu éviter d'utiliser id dans 
Saisies pour désigner l'attribut id et lui préférer attribut_id par 
exemple car cette variable est assez commune dans SPIP mais c'est plus 
facile à dire aujourd'hui.


L’archéologie indique que 'id' est arrivé par ici sur Saisies :
https://zone.spip.net/trac/spip-zone/changeset/80006


Quand à celui sur formulaire_.php du core, c’est arrivé plus tôt avec 
https://core.spip.net/projects/spip/repository/revisions/15772


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] Formulaire générique d'édition d'un objet et Saisies

2019-07-22 Par sujet Matthieu Marcillaud

Le 22/07/2019 à 17:42, Eric Lupinacci a écrit :

C'est sur que de toute façon il aurait fallu éviter d'utiliser id dans 
Saisies pour désigner l'attribut id et lui préférer attribut_id par 
exemple car cette variable est assez commune dans SPIP mais c'est plus 
facile à dire aujourd'hui.


L’archéologie indique que 'id' est arrivé par ici sur Saisies :
https://zone.spip.net/trac/spip-zone/changeset/80006


___
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] [Spip-zone-commit] r115947 - in _dev_/univers_spip

2019-07-15 Par sujet Matthieu Marcillaud

Le 14/07/2019 à 20:55, James a écrit :

D'ailleurs, marcimat, si tu as une minute pour jeter un oeil et faire un 
svn up ... ;-)


That’s up !
___
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] Refonte Contrib - SVP et les catégories/tags

2019-06-17 Par sujet Matthieu Marcillaud

Le 17/06/2019 à 10:13, Eric Lupinacci a écrit :


A vous lire


Bah, merci de ce résumé.

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] Exec admin_plugin et appels bizarres

2019-06-17 Par sujet Matthieu Marcillaud

Le 16/06/2019 à 20:28, Eric Lupinacci a écrit :

Hello,

En faisant des modifications sur SVP j'ai trouvé des appels à 
gros_titre(), debut_gauche() et debut_droite() qui me renvoient une 
erreur dans phpstorm.


Ah oui, ce 3è paramètre avait été ajouté pour que ces fonction ne 
fassent pas d’echo directement. Elles ont été nettoyées entre temps 
(https://core.spip.net/projects/spip/repository/revisions/17532).


On peut effectivement virer ce 3è paramètre des appels :)

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

[spip-dev] [HS] Re: Changer la gestion des catégories de plugin

2019-05-22 Par sujet Matthieu Marcillaud

Le 19/05/2019 à 11:51, Eric Lupinacci a écrit :


Oui, c'est bien mais je trouve que la lecture sous github est cette fois 
plus difficile.

Je pense que c'est du à la police et à la présentation.
Mais oui, y a surement de la doc bien faite, le problème c'est la 
statistique sur le sujet...


Tiens, autre doc en markdown, celle de Project Fluent : là 
https://github.com/projectfluent/fluent/tree/master/guide

Qui se retrouve sur GitBook là : https://projectfluent.org/fluent/guide/

Mais… GitBook, qui semble être fait par une équipe lyonnaise, dans sa 
version 2 a un éditeur en ligne (tout beau, avec édition en place, et a 
priori propriétaire ? En tout cas ça ne semble plus là 
https://github.com/GitbookIO) qui stocke maintenant les données en JSON 
et plus en Markdown. Avec les explications du pourquoi (limitations) là 
https://docs.gitbook.com/v2-changes/important-differences#editing-markdown-source 
; Je n’ai pas trouvé à quoi ressemble le JSON derrière…


Ce qui je trouve est intéressant vis-à-vis de la discussion markdown de 
l’autre côté. L’inconvénient clair pour moi du JSON est qu’il faut alors 
absolument un éditeur par dessus pour rédiger le contenu.





Monolog c'est le premier module qui rentrera dans le SPIP-git-composer ? ;-)
Ca a l'air très bien.


Pourquoi pas :)

Une des possibilités est d’utiliser un conteneur de services. Le service 
'log' (ou équivalent) retournerait un logger compatible avec la 
l’interface fournie de psr/log. Probablement Monolog s’il y en a un à 
choisir. Ou une implémentation SPIP qui reprendrait le fonctionnement 
historique qu’à spip_log. Est configurable quelque part la relation 
entre le service 'log' et l’implémentation utilisée.


Ceci fait, spip_log() elle même peut devenir dépréciée (ou pas) et 
utiliser alors le service de log directement.


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] [SPIPRemix] SPIP, Composer, Git

2019-05-19 Par sujet Matthieu Marcillaud

Bonjour,

Pas mal donc : SPIP et tous les plugins-dist (et quelques autres) sont 
transformés en Git, envoyés sur Github via un script à lancer. Et on les 
retrouve sur le Packagist.


Comme déjà signalé par James, il y a quelques petites différences entre 
spip 3.2.3 obtenu sur le tag SVN et la version qu’on obtient avec 
Composer. Probablement quelques commits manquants.


Les plugins-dist ne sont plus rangés à la racine (plugins-dist/spip/xxx) 
et certains sont renommés selon leur préfixe (textwheel en tw, 
urls_etendues en urls). Ça ne semble pas dérangeant.


Par contre il y a encore quelques soucis sur la version dev qui ne 
semble pas à jour pour tout.


Est-ce que quelqu’un d’autre a testé du coup ?

MM.


Le 13/05/2019 à 16:16, James a écrit :

Salut,

J'ai complété la collection de plugins SPIP installables via composer :

https://packagist.org/?query=spip=spip-plugin
https://github.com/spipremix/

La doc sur le site du rebooteux n'est pas à jour. Mais voilà, l'idée 
générale reste la même et tous les plugins dist sont dans la maquette 
SpipRemix, sur github et sur packagist.org 


Alors attention, j'insiste, c'est une maquette, une démo. et c'est 
peut-être pas pile-poil pareil entre le truc officiel et la maqiuette. 
Vos retours sont les bienvenus.


Du coup il est possible de jouer avec "spip/spip" et composer :

Installer la dernière version stable (une 3.2.4) :

composer create-project spip/spip

(mise à jour avec la commande composer update)

Installer la version de dev et faire du git après :

composer create-project -s dev --prefer-source --keep-vcs spip/spip 
spip-dev dev-master


Bref, essayez, faites des tests, prenez le temps d'apprendre à manipuler 
composer...


Il me reste à faire un empaqueteur qui fait le gros zip à partir des 
dépôts github et plus à partir de subversion. Pour ça, et comme il y a 
aussi besoin de faire mieux en ce qui concerne les perfs et les rapports 
entre git et ce script d'un autre âge..., je suis en train d'en réécrire 
un nouveau, "from scratch" comme on dit, voilà :-)


Pour la bascule définitive, j'ai pas d'infos. ça pourrait aller vite, 
mais on sait aussi prendre notre temps, donc ... en tout cas, c'est la 
raison pour laquelle il n'y a que les versions 3.1, 3.2 et dev qui ont 
été maquettées. Pas de versions 3.0 et antérieures.


Amitiés,
--
James



___
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] Changer la gestion des catégories de plugin

2019-05-19 Par sujet Matthieu Marcillaud

Le 19/05/2019 à 10:46, Eric Lupinacci a écrit :

[...]

Faut juste penser que smart-paquets ne fait pas que compiler les données 
contenues dans un paquet.xml ou un plugin.xml. Il construit des données 
incluses dans le archives.xml comme les traductions.


Il me semble que l’idée est bien de continuer à générer ce fichier (et 
donc à un moment il y a une phase d’analyse du code source, notamment de 
paquet.xml).


Donc je ne sais pas comment une API sur un outil qui nous est externe et 
sur lequel nous n'avons pas prise peut arriver à rendre un service 
équivalent. C'est à étudier, je le répète depuis des semaines sans être 
audible il semblerait, Composer me parait indolore dans l'étape initiale 
sauf pour le référencement des plugins et c'est pour cela que j'ai lancé 
les deux derniers fils.


Heu, oui, enfin nous aussi on se répète…

Ca serait donc bien que cette réflexion se fasse plus ouvertement 


Je vois pas en quoi ce n’est pas ouvert. C’est pas les mails qui 
manquent, ni les résumés des réflexions...


car je
sais par expérience que les fonctions de SVP, ses modules connexes et 
smart-paquets sont mal connues.


Certes, mais on est peut être pas obligé de reproduire le fonctionnement 
à l’identique.



Je comprends pas le "sans révision spécifique".


Dans archivelist, tu déclares la … ah non… Lol… pardon, c’est moi qui 
ait confondu avec un autre outil… donc tu déclares juste le chemin du 
répertoire.


Si je comprends bien c'est une autre façon de construire le 
archivelist.txt non ?
Oui, enfin ça ne le reconstruit pas à proprement parler, mais oui, ça 
crée une liste d’urls sources de plugins.


[...]
et de qualité, ce qui n'est pas le cas des readme que j'ai pu 
lire, loin de là...


Alors peut être chez SPIP, mais sur d’autres projets le readme est un 
très bon point d’entrée, qui me semble à encourager au contraire (parce 
que standard justement).


Un petit exemple : https://github.com/Seldaek/monolog
Le readme et la doc/ correspond à la branche du plugin que tu regardes.
Tu fais une nouvelle version dans une nouvelle branche ? tu adaptes ta 
doc à côté, elle est à jour pour cette branche. Il y a un côté à la fois 
pratique et simple, et la doc est associée au code. Par contre, il n’y a 
pas de traductions (en tout cas dans cet exemple là).


Ce qui n’empêche pas d’avoir une doc collective éditoriale à côté 
heureusement, mais en tout cas comme base, c’est ce qui me parait le 
plus sain.


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] Changer la gestion des catégories de plugin

2019-05-19 Par sujet Matthieu Marcillaud

Le 18/05/2019 à 16:47, Maïeul Rouquette a écrit :
(...)

oui c'est ma proposition, de faire une suite. En gros le workflow pour
moi serait
1. On déclare un plugins au référentiel
-> ca demande la catégorisation  
-> ca enclenche le zippage (pour ca faut fournir une source de
versionnement)
-> ca crée automatiquement une rubrique et un article, et cela
propose le choix entre :
-> je rédige moi même la documentation
-> je demande à d'autres de le faire, et dans ce cas on un
statut "appel à documentation" et cela apparait dans l'espace privé de
contrib
2. Sur l'espace privé du réferentiel, des gens qui ne sont pas
nécessairement les auteurs du plugins peuvent compléter la documentation
pour les articles "appel à documentation".
3. In fine, dans tous les cas ca repasse par "proposer à l'évaluation",
et par une validation editoriale.


Hop,

Par rapport aux référentiel
---

Je m’incruste dans la conversation, et en relation avec Composer, et 
aussi suite à causerie avec James en aparté hier soir.


On se place dans un moment charnière où il y aurait des plugins SPIP 
«composerisés», mais pas tous. L’idée (de ce que j’ai compris) qu’il 
avait en tête en refaisant Smart Paquets est de changer à terme la 
méthode de déclaration des paquets (actuellement archivelist*) pour :


- un automatisme pour les plugins Composerisés (présents sur Packagist) 
: une API publique à Packagist permet de lister l’ensemble des paquets 
de type "spip-plugin" par exemple 
(https://packagist.org/packages/list.json?type=spip-plugin). À partir de 
cela il est possible de récupérer une description de chaque paquet (dont 
le nom, la source, l’url de documentation, le zip ...) 
(https://repo.packagist.org/p/spipremix/saisies.json). Donc, de notre 
côté, avec un petit cron, il semble possible de découvrir 
automatiquement ces plugins SPIP pour les lister dans cet annuaire.


- pour les autres plugins, l’idée serait d’avoir sur plugins.spip.net un 
formulaire où l’on saisit l’url du projet (plutôt que de donner l’url du 
répertoire à zipper avec le n° de commit) : de donner l’url racine du 
projet (le git), ou sur la zone, le svn au niveau de la racine d’un 
plugin (_plugins_/saisies) en standard layout (tags / branches / trunk) 
et c’est l’outil qui génère alors un zip pour chaque tag, branche, trunk 
(lorsque la forge ne fournit pas d’api pour obtenir le zip) ; Donc sans 
indication de révision spécifique.


- en allant (beaucoup) plus loin, dans ce cadre de la zone, cet outil 
pourrait servir à transformer des plugins non standard layout sur la 
zone en standard layout, voire faire la migration svn > git, pour les 
personnes donc qui ne sont pas à l’aise avec ces migrations.


Par rapport aux documentations
--

Je pense qu’il faut aussi tenir compte des fichiers 'Readme.md' qui est 
relativement standard lorsqu’un code source est mis sur github. Assez 
souvent aussi un répertoire doc/ ou docs/ est présent. Mais dans la 
mesure du possible, s’il y a un composer.json, l’url de documentation 
est indiquée (de même que s’il y a un paquet.xml).


Pourquoi demander (lorsqu’on déclare un plugin) de rédiger autre chose 
si une telle url est renseignée ? Enfin ça mange pas de pain, mais à mon 
avis il manque "La documentation existe déjà" dans les choix.


--

Beaucoup de  et de 
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] Catégorie de plugins, SVP, SPIP et Composer

2019-05-17 Par sujet Matthieu Marcillaud

Le 17/05/2019 à 11:03, Eric Lupinacci a écrit :

Je suis étonné que les tenants de Composer n'ait pas plus d'avis sur le 
sujet car je pensais que ça pourrait faciliter le travail futur mais je 
dois me tromper.


La seule chose que je peux dire vite fait en passant (sans avoir encore 
pu trouver le temps de comprendre et réfléchir en détail à ce qui est 
proposé) c’est que les paquets Composer proposent une clé de 
configuration pour tagguer les paquets. Tags libres et multiples. Ils 
n’ont pas de catégories figées. Je suppose que peut être qu’il est trop 
difficile de prévoir tous les cas. Je suppose aussi que le "tag" 
augmente le score des résultats sur les recherches qui contiennent ce 
tag (sans garantie).


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] SPIP Zone et Git

2019-05-07 Par sujet Matthieu Marcillaud

Le 06/05/2019 à 23:32, RealET a écrit :

Bruno Bergot a écrit le 06/05/2019 à 18:11 :


Les plugins en question sont toujours disponibles en zip et donc par 
le biais de SVP :)

Justement non !
Pas si SVP est en mode d'installation par SVN.
Et c'est bien là le problème.


- Il me semble me rappeler que cette fonctionnalité 
(SVP_PREFERER_TELECHARGEMENT_PAR_VCS) était arrivée suite à ta demande à 
l’origine.

- Il me semble qu’il n’y a quasiment que toi qui l’utilise actuellement.
- Ça ne fonctionne pas avec les externals github...

-> Propose des solutions pour améliorer la situation

Pour ma part je préfèrerais trouver des solutions pour passer à Composer 
(qui lui gère correctement ces changements de VCS lorsqu’on utilise son 
option --prefer-source).



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] [Outil de traduction] Fluent de Mozilla

2019-04-18 Par sujet Matthieu Marcillaud

Le 18/04/2019 à 11:44, Bruno Bergot a écrit :


Mozilla vient d'annoncer ceci
https://blog.mozilla.org/press-fr/2019/04/17/mozilla-lance-fluent-1-0-pour-revolutionner-la-localisation-des-logiciels/ 


Ouep, ils ont l'air de bien gérer le cas des pluriels, 


Je viens de regarder un peu en détail, et je trouve ça vraiment, 
vraiment, vraiment très bien ! Si on doit aller quelque part avec les 
traductions, j’ai vraiment l’impression qu’il faut aller vers ça (peut 
être plus que vers des .PO finalement ou autres).


Ça répond à de nombreuses problématiques (pluriels, genre, grammaire) en 
restant et en donnant plus de liberté aux traductrices/traducteurs.

Je suis assez enthousiasmé. https://projectfluent.org/fluent/guide/

mais bon je pense qu'on risque d'attendre longtemps avant de voir une implémentation PHP 


Il y a JS, Python, Rust pour le moment. Vu le potentiel, je ne doute pas 
qu’une implémentation arrivera (je m’étonne surtout qu’elle ne soit pas 
déjà là en fait)


du bouzin... Et puis j'imagine même pas le stack nécessaire pour faire 
tourner la plateforme de trad.


Il y en aura peut être de proposées aux communautés du libre ?


Au final, ce qu'on a est tout de même "plus que pas mal", merci kent1...


- Oui (pour l’interface / traduire.spip.net)
- mais non, pour la gestion des chaines de langues, nous sommes assez 
incomplets malheureusement : ne serait-ce déjà sur les pluriels qu’il 
n’est pas possible de définir correctement pour chaque langue.


Mais là, y a quand même un côté sympa dans l’écriture de Fluent / FTL : 
la clé de langue est la même quelque soit le genre ou le pluriel, et 
c’est le traducteur qui gère en fonction de la variable reçue ; et tu 
peux appeler directement le texte d’autres chaines de langue à 
l’intérieur d’une chaine de langue…


Y a du potentiel !

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] Gouvernance/mandat du projet git

2019-04-08 Par sujet Matthieu Marcillaud

Yop !

Le 04/04/2019 à 09:56, cam.la...@azerttyu.net a écrit :

Dans le cas d'une expérimentation pratique je veux bien essayer de
mettre en place les suggestions proposées pour mettre en place une
gouvernance autour du projet git.


Tu parles des suggestions de gouvernance, ou des suggestions pour Git ? 
et dans ce dernier cas, à quelles suggestions fais tu référence du coup ?


Belle journée,
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] ssl et blog.spip.net

2019-04-08 Par sujet Matthieu Marcillaud

Le 08/04/2019 à 08:51, JLuc a écrit :

Le 08/04/2019 à 08:48, placido a écrit :

Pour info, le problème de certificat expiré concerne aussi
boussole.spip.net il me semble.


Il faudra s'en souvenir : au 1er avril, c'est pas une blague, il faut 
renouveler les certificats.


Pec pour la boussole.

En fait c’est totomatique ces renouvellemenents, sauf quand 
l’automatisme plante bêtement :)


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] ssl et blog.spip.net

2019-04-07 Par sujet Matthieu Marcillaud

Le 06/04/2019 à 23:35, nicod_ a écrit :

Le 06/04/2019 à 19:57, Bruno Bergot a écrit :
Ça semble bon maintenant, merci pour le signalement et merci à la 
personne qui a réglé le problème :)


Idem sur party.spip.net, si la personne en question a encore cinq 
minutes :)


Arf. Fait pour lui aussi.
Merci :)

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] Piste de conception d'interface SPIP-Composer

2019-04-01 Par sujet Matthieu Marcillaud

Le 30/03/2019 à 13:05, RastaPopoulos a écrit :


Quand on parle "interface" pour Composer [...]
L'idée serait donc de développer un logiciel (libre), sans rapport avec
SPIP, qui fournirait ce service sur "composer.spip.net". Pour l'instant
il serait basique et tourné vers nos besoins prioritaires, mais ça peut
intéresser potentiellement beaucoup de monde dans PHP, et d'autres
personnes pourraient l'améliorer. Il se peut aussi que des gens aient
déjà commencé des projets similaires (en libre !) : il faut regarder
pour ne pas partir de zéro.


Pour rappel c’est exactement ce qu’à fait l’équipe Contao :

- https://medium.com/@yanick.witschi/composer-cloud-resolver-e64254f5728e
- 
https://medium.com/@yanick.witschi/welcome-composer-resolver-cloud-30ebd4cb59fa

- https://composer-resolver.cloud/

Pas en libre ; du moins pour le moment. Et extensible dans les nuages 
(docker + kumbernetes)


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] Composer et SPIP sont dans un bateau

2019-03-20 Par sujet Matthieu Marcillaud

Le 20/03/2019 à 12:31, RastaPopoulos a écrit :

Je suis assez d’accord avec tes remarques. Du coup, je vais couper pas 
mal de morceaux.



1) Historiquement
[...] font que de l'intégration
classique de base, et qui utilisent SPIP depuis des années uniquement en
interface pour l'installer et le maintenir chez leurs clients.
(M'est-avis que ce public se réduit d'année en année tout de même.)


C’est une quasi-certitude même au vu des évolutions de la liste spip-user

[En plus, les pages Facebook (hic) sont souvent utilisées pour la 
plupart des petites structures, au moins au début].



2) Quand on parle d'interface pour Composer, il s'agit d'un chantier
purement de devs [...]


Et de temps à y consacrer


3) [...] les plugins DOIVENT pouvoir être cherchés et installés par une 
interface


Des plugins ou tous les plugins ?

C’est un des sens de la distinction qui était faite ; les plugins vont 
utiliser des librairies aussi issues de Composer (ils le font déjà en 
plus certains, vilainement en envoyant un répertoire vendor/) ; Comment 
pourrait-il en être autrement vu que toutes les libs partout sont 
passées à des dépendances via Composer ?



Bref, mon avis général est que pour noyau, on est bon. Mais que pour les
plugins, on ne doit pas aller vers Composer tant qu'on n'a pas déjà une
interface utilisable sous la main. Pour *aucun plugin*, car de toute
façon ils se nécessitent tous les uns les autres, et les squelettes
génériques partagés nécessitent tous aussi des plugins fonctionnels.


C’est là où on n’est moins d’accord. Surtout par le fait que c’est 
absurde de pas pouvoir profiter de Composer dans nos plugins, vu qu’on 
est déjà bridé par cette absence. Attendre d’avoir une interface 
graphique de remplacement fonctionnelle (pour tous les plugins), c’est 
repousser encore des évolutions de code et de fonctionnalités pour 
longtemps…



On ne peut pas perdre de manière certaines N% des utilisateurices pour
un gain qui lui est seulement hypothétique.
[...]


Tout est hypothétique… même le fait de perdre N% des utilisateurices… 
qui seraient déjà partis de toutes façon pour plein d’autres bonnes raisons…

Si on dit "SPIP doit *permettre* de ne pas avoir d'interface pour
installer et mettre à jour", je suis totalement d'accord ! Sauf que si
on dit que pour l'instant on part là-dessus sans en avoir et que c'est
aux gens qui en ont besoin de le développer plus tard, ça n'a rien à
voir ! Là ce n'est plus permettre, c'est *obliger* à ne pas avoir
d'interface, et rendre hypothétique l'arrivée d'une interface plus tard.
Ça n'a donc rien à avoir avec la phrase de départ. (Et je suis contre.)


J’entends bien. Soit. L’interface graphique à disposer *pour tous les 
plugins*, tu le contraints aussi aux développeureuses comme pré-requis 
pour aller plus loin.


Mais je sais pas si on peut aller très loin comme ça :)

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] Composer et SPIP sont dans un bateau

2019-03-19 Par sujet Matthieu Marcillaud

Le 19/03/2019 à 14:58, cam.la...@azerttyu.net a écrit :

Salut

Merci pour ce retour.
Je me permets 1 remarque et 1 question :
La première personnelle, c'est ce choix de SASS avec github/gitlab par
défaut. Je pense toujours que c'est une bêtise mais celui qui code qui
a raison.


Il y avait plusieurs raisons discutées à cela, entre autres et avant 
tout car c’est plus simple pour Composer avec Packagist.org, et aussi le 
fait de s’éviter de la maintenance.



La seconde si je comprends bien l'idée on aurait 2 zones de
téléchargement distinctes une pour SVP et l'autre pour composer.


Distinguons d’abord la première partie du plan (core + plugins-dist). 
Celle-ci ne pose pas trop de problème il semblerait.
On aurait le zip habituel (avec peut être un vendor/ en plus selon ce 
qu’on utiliserait comme librairie de base), et le reste serait géré par 
SVP comme actuellement.


C’est la suite logique (mais un peu plus lointaine) qui est plus 
discutable (utiliser Composer aussi pour les autres plugins).
Effectivement, pendant un temps on se retrouverait avec 2 sortes de 
plugins,

- une capable d’être utilisée avec Composer,
- l’autre capable d’être utilisée avec SVP,
- et des plugins à l’intersection des deux


Comment va se gérer la maintenance d'un plugin ? Un plugin installé
par composer serait hors écosystème SVP (et pas réciproquement)
Assez probablement un plugin installé par composer (en terminal) ne 
pourrait pas être mis à jour par interface graphique (SVP ou un 
descendant de SVP utilisant une interface graphique avec Composer), quoi 
que je ne suis pas sûr que ça soit impossible.

  cela
me semble un coût important sans avancée notable. En l'état un plugin
SVP n'a pas de vraie raison de passer en plugin Composer. Et un plugin
composer sera restreint aux terminaux serveurs.


Oui, mais ce raisonnement se base sur les plugins actuels qui ne peuvent 
pas utiliser Composer actuellement ! (Ou qui tentent de le faire 
difficilement en fournissant eux-même un répertoire vendor/ ce qui a 
toutes les chances de péter… il y en a 3 comme ça sur la zone déjà). 
L’avancée, me semble-t-il, c’est justement de pouvoir récupérer et 
utiliser des librairies externes facilement. Et de faire évoluer nos 
plugins.



[...]
Là où je coince c'est le principe de la transition, à moyen/long terme
je vois toujours 2 solutions à maintenir et non un remplacement, et
cela du fait des contraintes propres à composer.

Oui. Et cette transition n’est pas encore très claire.

Et donc je
m'interroge sur l'intérêt de la bascule tant pour les développements
que pour les usages des plugins .


Bah, on peut aussi apprendre à se contenter de ce qu’on a, après tout, 
ça fonctionne encore :)
Mais personnellement, ce grand écart en SPIP et le reste du monde PHP 
commence à me taper grave sur le système, alors je suis plutôt content 
de cette direction vers Composer.
Mais ça n’a pas l’air de satisfaire tellement ici au final. Peut être 
qu’on fait fausse route.


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] Composer et SPIP sont dans un bateau

2019-03-18 Par sujet Matthieu Marcillaud

Le 18/03/2019 à 18:23, Maïeul Rouquette a écri

ca pose des soucis politiques / editorial, de devoir avoir composer sur
n'importe quel serveur qui hébergement


Je te retourne ton «c’est à dire ?».

Composer n’a pas besoin de permissions d’administrateur du serveur pour 
fonctionner (c’est un fichier php… enfin une archive .phar) ; si c’est 
la question ?



Mais c’est aussi parce que Composer fait un poil plus que ce qu’on a
dit
(résolution de dépendances & téléchargements).
Notamment il calcule aussi un «autoloader», basé sur les différentes
déclarations des fichiers composer.json. Et assez certainement, on en
aura besoin dans l’avenir dans les plugins.


c'est à dire?


Ok, détaillons (rapidement).

Un autoloader en PHP, c’est une déclaration qui permet de dire :

- si j’appelle telle classe `new Toto()` ou `new Auto\Mobile()`,
- que je la connais pas encore en mémoire,
- alors, elle se trouve dans tel fichier ; vas-y : charge ce fichier 
automatiquement !


En gros ça pourrait remplacer potentiellement certains include() ou 
include_spip().


Un intérêt, c’est que tu vas déclarer en tête de fichiers toutes les 
classes que tu pourrais utiliser dans ton fichier (ce n’est pas une 
obligation non plus) avec l’instruction `use` :
Ici, tu pourrais avoir `use Auto\Mobile;` ou `use Auto\Mobile as 
Automobile;`, et plus loin quelque part dans ton code `$auto = new 
Mobile();` ou `$auto = new Automobile();` (ou toute autre instruction 
indiquant une classe quelque part)


Le fichier contenant la description de la classe Auto\Mobile ne serait 
chargé (si besoin) que si la ligne new Mobile() est réellement exécutée.


Autrement dit, les `use` ne sont pas comme des include ou des require. 
Ça dit juste, j’aurais probablement besoin de ça — fais-moi en un 
raccourci ; grosso modo.


Et pour savoir la correspondance entre le nom de la classe, et le 
fichier à rechercher, il n’y a pas de mystère : cela s’appuie sur, 
maintenant essentiellement PSR-4 (https://www.php-fig.org/psr/psr-4/), 
et une déclaration dans les fichiers composer.json.


Ainsi tu pourrais avoir `autoload: { "psr-4": { "Auto\\": "src/" } }` 
dans le composer.json du plugin… disons "Auto"… :


Ça dit en gros, cherche ce qui concerne le namespace "Auto/" dans le 
répertoire src/ ici présent…. Ça sous-entendrait qu’il existe le fichier 
"src/Mobile.php" avec la classe Auto/Mobile dedans.


Note que toutes les librairies PHP utilisent ça maintenant et déjà 
depuis quelques temps quand même.


Il me semble (mais là encore ce n’est qu’un avis perso) que nous aurions 
intérêt à nous harmoniser avec les autres un peu :)


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] Composer et SPIP sont dans un bateau

2019-03-18 Par sujet Matthieu Marcillaud

Le 18/03/2019 à 18:04, Maïeul Rouquette a écrit :

Ce que je comprend moyen, c'est la nécessité de composer pour gérer les
dépendances interne au monde SPIP. Pour une dépendance externe, oui, ca
a du sens. Mais pour une dépendance interne...

C’est pour éviter de maintenir notre propre système de gestion de 
dépendances de notre côté (qui est loin d’être aussi robuste). Ce n’est 
pas spécialement une obligation effectivement. En tout cas dans un 
premier temps.


Mais c’est aussi parce que Composer fait un poil plus que ce qu’on a dit 
(résolution de dépendances & téléchargements).
Notamment il calcule aussi un «autoloader», basé sur les différentes 
déclarations des fichiers composer.json. Et assez certainement, on en 
aura besoin dans l’avenir dans les plugins.


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] Composer et SPIP sont dans un bateau

2019-03-18 Par sujet Matthieu Marcillaud

Le 18/03/2019 à 17:00, Maïeul a écrit :

Le 18/03/2019 à 16:48, Matthieu Marcillaud a écrit :


Évidemment certains outils (CMS) se sont quand même penchés sur la 
question, que nous citons dans l’article. A minima cela revient à 
calculer A sans dépasser le memory-limit (en le sous-traitant à un 
autre serveur par exemple), à appliquer B) et à désactiver C) 
totalement.


ok, je comprend mieux. Mais du coup cela voudrait dire qu'on pourrait 
utiliser composer pour par ex generer des distributions SPIP depuis un 
serveur, gérer des dépendances à des lib externes pour un plugin, mais 
pas forcément pour installer des plugins sur un site, car cela serait 
trop gourmand. 


En terminal ce n’est pas un problème (on peut faire installer les 
plugins dans le répertoire plugins/ ou plugins-dist/ même).
On peut même packager des zips tout prêts de distributions SPIP 
alternatives pour les utiliser ensuite avec spip-loader éventuellement.


C’est effectivement l’ajout depuis une interface graphique qui est 
ensuite délicate. La suggestion de séparer des paquets «graphiques» sans 
dépendances est une possibilité (des thèmes, des squelettes par exemple) 
en continuant d’utiliser SVP pour eux (à mon avis on sera très limité 
quand même car quantité de plugins ont des dépendances) (et aussi parce 
qu’il faudrait que les gens puissent télécharger graphiquement 
«Formidable» par exemple qui a tout un tas de dépendances lui-même) ; 
mais il faudrait que ça soit transitoire pour ne pas avoir à terme à 
gérer 2 systèmes.


C’est aussi pour cela la suggestion de la conclusion. Il pourrait y 
avoir une distribution SPIP «mature» qui continue de fonctionner comme 
actuellement, pendant qu’un autre morceau (le noyau) explore de 
nouvelles possibilités. Mais bon, on le voit bien aussi encore 
aujourd’hui, les plugins de la zone ont besoin de Composer (pas que le 
core ni les plugins-dist).


Et là on resterait sur du SVP traditionnel, qui irait chercher des 
"packs" tout fait de plugins et de dépendance, qui eux seraient gérés 
par composer sur le serveur distant?


Non. Du tout. En tout cas on ne pourrait pas intégrer des packs qui 
auraient aussi un répertoire vendor/ dedans. Ça risquerait de créer des 
conflits et en plus on ne saurait pas faire le merge.


Il faut laisser Composer gérer le calcul et le téléchargement des 
dépendances (il est vraiment fait et optimisé pour ça).


Je suis pas forcément très clair dans ce que j’exprime, mais tout n’est 
pas encore clair dans comment faire après :)


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] Composer et SPIP sont dans un bateau

2019-03-18 Par sujet Matthieu Marcillaud

Le 18/03/2019 à 15:54, Maïeul a écrit :

Il y a un truc que je ne comprend pas très bien, c'est la distinction 
entre les deux types de plugins "Composer" et "interface".  Pourquoi 
est-ce qu'on ne pourrait pas avoir une interface graphique pour composer ?


C’est vrai que j’ai omis de détailler cela, mais Composer fait 3 choses :

- A) à partir d’une liste de dépendances racines, de contraintes, il 
calcule l’ensemble de toutes les dépendances qui sont nécessaires au 
projet. Il en écrit un composer.lock
- B) à partir de ça il va comparer ce que tu as en local avec le 
composer.lock et mettre à jour ou télécharger (en zip ou sources) ce 
dont tu as besoin.
- C) des plugins composer peuvent exécuter des actions sur certains 
événements (déplacement de fichiers, vidage de cache, etc...)


La partie A) (le SAT https://fr.wikipedia.org/wiki/Probl%C3%A8me_SAT) 
est très gourmande en ressources, notamment en mémoire PHP


La partie B) peut prendre du temps (notamment si ça télécharge des 
sources GIT), mais n’a pas besoin de beaucoup de mémoire (mais a besoin 
de droits d’écriture sur certains répertoires).


La partie C) peut nécessiter des droits spécifiques.

Utiliser Composer avec une interface graphique revient à résoudre ces 3 
points ; sachant que l’équipe Composer ne souhaite pas d’interface 
graphique pour des questions de sécurités (permettre de télécharger 
n’importe quoi facilement sur un hébergement est rarement bien vu en 
terme de sécurité).


Évidemment certains outils (CMS) se sont quand même penchés sur la 
question, que nous citons dans l’article. A minima cela revient à 
calculer A sans dépasser le memory-limit (en le sous-traitant à un autre 
serveur par exemple), à appliquer B) et à désactiver C) totalement.




Une remarque aussi, plus politique. Pourquoi entre Gitlab (libre, 
ouvert) et Github (propriétaire), choisir le second?


Ça a été un grand débat déjà de suggérer de préférer Github.com ou 
Gitlab.com pour faciliter l’utilisation de Composer.


Mais pour cette question spécifique, il me semble que c’est la mémoire 
collective qui a jouée en considérant que Github incarne (ou incarnait) 
le plus l’esprit Open source et que la plupart des gens y ont un compte.


Après, Gitlab est aussi une grosse entreprise. Au moins le logiciel 
Gitlab existe pour le moment en version communautaire open source.


(et donc pour ma part, peut importe, tant qu’on va quelque part…)

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] Patch styliser_par_z pour des dist-composition

2019-03-04 Par sujet Matthieu Marcillaud

Le 04/03/2019 à 22:20, nicod_ a écrit :

Le 04/03/2019 à 21:47, nicod_ a écrit :
Le top serait en plus que ça ne nécessite pas la création d'un 
footer/article.html et footer/rubrique.html, qui ne sont pas utiles 
non plus, mais le patch serait un peu plus gros.




J’aime beaucoup l’idée… mais… il y a un poil de fourberie non ?

Ça sous-entend que tu sais que 'compo1' de article et de rubrique est 
équivalent, mais il me semble qu’il pourrait exister des cas où le nom 
de la composition de signifie pas la même chose ; du coup dist-compo1 
deviendrait un peu ambigu.


Je n’ai pas d’exemple qui me viennent en tête cependant. Peut être que 
c’est juste fictif. Un artefact mathématique !


En même temps les compositions sont spécifiques au projet (je ne crois 
pas qu’un plugin fournisse de "content/article-galerie.html" par 
exemple) (et qu’un autre fournirait un content/rubrique-galerie.html) et 
donc, la responsabilité du nommage incombe à la personne qui gère les 
squelettes du site, et donc, dans ce cas, c’est une super feature :)


Voilà pour moi.
___
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] [Spip-zone-commit] r114271 - in _core_/plugins/mots

2019-03-04 Par sujet Matthieu Marcillaud

Le 04/03/2019 à 15:18, Cerdic a écrit :

Ah oui pas mal :
{id_xx?} ou {id_tous?} ou {id_all?}
Mais du coup {id_?} est peut être le mieux car évitant tout risque de 
collision ?


J’ai envoyé avec {id_?}.
Y a pu ka tester que ça va bien.

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] [Spip-zone-commit] r114271 - in _core_/plugins/mots

2019-03-03 Par sujet Matthieu Marcillaud

Le 03/03/2019 à 09:35, Matthieu Marcillaud a écrit :

Ce que tu proposes là me parait aussi intéressant et plus générique, 
quoi que plus difficile à coder. J’essaierai d’y jeter un œil tout de même.


Oui, donc j’ai proposé un patch là https://core.spip.net/issues/4300 
pour ton idée de critère selection_conditionnelle.


Tel que proposé actuellement, (ARTICLES){selection_conditionnelle}...
va ajouter sur la boucle :

- tous les {id_xx?} présents sur spip_articles (id_article, id_rubrique, 
id_secteur, id_trad)


- tous les {id_xx?} correspondants à des clés primaires des objets 
éditoriaux éditables (id_auteur, id_mot, id_groupe, id_message, 
id_syndic, id_breve, id_document) avec les plugins dist par défaut.


Ça fait quand même beaucoup de conditions théoriques et de calculs de 
jointures potentielles, même si elles ne sont finalement pas utilisées.


En tout cas ça répond à la problématique pour 
prive/objets/liste/{objet}.html et son usage il me semble.


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] [Spip-zone-commit] r114271 - in _core_/plugins/mots

2019-03-03 Par sujet Matthieu Marcillaud

Hello :)

Je réponds aussi, puisqu’on en a un peu parlé IRL en même temps, et 
cette solution était le plus simple à mettre en œuvre. Mais 
effectivement c’est embêtant.


Il y a 2 ans, James proposait de passer par un pipeline permettant 
d’étendre le contenu du texte des critères (au niveau du phraseur) pour 
insérer "{id_mot?}", mais cela a aussi des problématiques.


Ce que tu proposes là me parait aussi intéressant et plus générique, 
quoi que plus difficile à coder. J’essaierai d’y jeter un œil tout de même.


MM.



Le 03/03/2019 à 02:48, Cerdic a écrit :

Hello Touti,

je comprend bien l’objectif poursuivi, mais ça semble un peu brutal et 
pas très satisfaisant de forker les squelettes listes 
articles/rubriques, car du coup ceux qui les ont personnalisés perdent 
des morceaux, et cela pose aussi plusieurs questions de généricité :


Ce que tu fais ici pour les mots, faut il le faire pour tout objet qui 
vient enrichir les articles ?
Et dans l’autre sens tu as changé le nommage générique en demandant donc 
une liste {table}-mot pour les autres objets ne faisant pas partie du core.
Donc on casse plein de compat sur les objets perso, mais au delà est il 
raisonnable de se retrouver à dupliquer des listes ad-nauseam partout ?


Pour le moment c’était resté comme ça car il n’a jamais été considéré 
comme critique de se débarasser de ce {id_mot?} dans ces listes, mais si 
on veut vraiment se débarasser de la dépendance je pense qu’on doit 
faire mieux que ça en évitant tous ces dédoublement.


Une solution à laquelle je pense serait de faire un critère spécifique 
genre {selection_conditionnelle} (nomenklatura si tu as mieux on prend 
!) qui regarderait les id_xxx connus dans l’environnement et pour chaque 
chercherait une fonction du type 
inc_generer_condition_selection_{id_xx}_dist qu’on appelerait sur le mode
$generer_condition_selection = 
charger_fonction(‘generer_condition_selection_’.$primary,’inc’);
$boucle->where[] = 
$generer_condition_selection($type_boucle,champ_sql($primary));


a charge pour chaque plugin de déclarer la fonction de selection 
correspondante et d’y gerer tous les cas (ici si pas de 
$_PILE[0][‘id_mot’] ça renvoie un 1=1)


Bref, c’est juste les grandes lignes, il y a surement des problèmes à 
résoudre et de la mise au point à faire, mais ça me semble une direction 
plus générique et souhaitable pour à la fois résoudre la dépendance de 
ces listes d’un plugin en particulier et éviter de faire 36 copies dans 
tous les coins de la zone…
(en évitant de la rupture de compat, puisque les surcharges 
continueraient de fonctionner, de même que les listes existantes 
d'autres objets éditoriaux)


Bises

--
Cédric
Le 2 mars 2019 à 19:21 +0100, spip-zone-com...@rezo.net, a écrit :

Author: tout...@free.fr
Date: 2019-03-02 18:21:41 + (Sat, 02 Mar 2019)
New Revision: 114271

Added:
_core_/plugins/mots/prive/objets/liste/articles-mot.html
_core_/plugins/mots/prive/objets/liste/articles-mot_fonctions.php
_core_/plugins/mots/prive/objets/liste/rubriques-mot.html
Modified:
_core_/plugins/mots/paquet.xml
_core_/plugins/mots/prive/squelettes/contenu/mot.html
Log:
Création des fichiers qui listent les articles et les rubriques d'un mot
dans l'espace privé.

Duplication de ceux du core, deviennent articles-mot et rubriques-mot.


Details: https://zone.spip.org/trac/spip-zone/changeset/114271

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




___
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] spip 3.0.28 Notice PHP

2019-02-15 Par sujet Matthieu Marcillaud

Le 15/02/2019 à 14:17, Bruno Bergot a écrit :



On décide d'une date de fin de vie pour SPIP 3.0. Par exemple, le 30 juin
prochain, arbitrairement.


Il parait qu’il faut plussoyer pour être dans le move ! Alors je +1 aussi !


+1, je me demande même si le 30 juin c'est pas trop loin, étant donné 
qu'on ne release pas très souvent.


Les jours défilent tellement vite que cela ne m’inquiète pas :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

[spip-dev] Mise à jour de sécurité : sortie de SPIP 3.2.2, SPIP 3.1.9, SPIP 3.0.28

2019-01-19 Par sujet Matthieu Marcillaud
Pour débuter cette nouvelle année, nous publions une version de 
maintenance qui corrige aussi quelques failles de sécurité.


L'écran de sécurité ne couvre pas ces failles, il est donc vivement 
conseillé de mettre à jour votre site internet.


Ces nouvelles versions comprennent les correctifs de bugs identifiés ces 
derniers mois :


  - 6 tickets pour la branche 3.1
  - 34 tickets pour la branche 3.2

Parmi les bugs corrigés, on notera :

  - correction de plusieurs failles XSS et d'une faille critique 
permettant à un rédacteur d'accéder aux documents locaux. Nous 
remercions vivement Guillaume Fahrner pour ces signalements

  - support des connexions TLSv1.2
  - amélioration de la compatibilité PHP 7.2
  - optimisation du compresseur javascript qui respecte maintenant les 
librairies externes déjà minifiées et correction d'un bug sur CSSTidy

  - réparation de la fonction restaurer une version
  - mise à jour de la bibliothèque SafeHTML pour le support de HTML5
  - mise à jour de la bibliothèque getID en version 1.9.16
  - ajout d'une constante _COUPER_SUITE pour définir les caractères de 
césure

  - refonte graphique des écrans de connexion
  - filtres images : les jpg sont maintenant progressif par défaut
  - de nouvelles traductions notamment dans néerlandais et japonais
  - …

Annonce complète et détails :
https://blog.spip.net/829

— L’équipe


___
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] Refonte des sites et logos SPIP

2019-01-11 Par sujet Matthieu Marcillaud

Le 11/01/2019 à 17:53, nicod_ a écrit :

Le 11/01/2019 à 13:58, Matthieu Marcillaud a écrit :

J’ai envoyé la correction qui semble fonctionner chez moi en local.


Tu l'avais oubliée dans le footer :)

Effectivement !


J'ai ajouté id_article et id_rubrique (pas tout l'env), et j'ai mis à jour.

Je me demande si c’est suffisant :)

J'ai modifié dans les squelettes galactic et galactic-forum aussi, qui 
ont le même bug dans le footer.


Il faudrait mettre à jour spip.net, forum et programmer du coup.

Fait partout. J’ai mis à jour precode & coloration aussi.

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] Refonte des sites et logos SPIP

2019-01-11 Par sujet Matthieu Marcillaud

Le 11/01/2019 à 13:18, Matthieu Marcillaud a écrit :


Oui, on a remarqué ça, il y a un ticket.
Ça me le fait pas du tout sur ma copie locale, et on comprend pas d'où 
ça vient.


Heu, comme je le signalais dans le ticket Nicod, je pense qu’il manque 
un env effectivement sur les inclusions aside/article et consœur. Tu 
veux que je commite ?


J’ai envoyé la correction qui semble fonctionner chez moi en local. J’ai 
pas vidé le cache de Contrib par contre, ça mettra peut être du temps à 
se déployer. On verra.


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] Refonte des sites et logos SPIP

2019-01-11 Par sujet Matthieu Marcillaud

Le 11/01/2019 à 12:16, nicod_ a écrit :

Le 10/01/2019 à 14:15, Jean Marie Grall a écrit :
Lien "Se connecter" > une fois identifié, on est redirigé vers 
l'accueil au lieu de la page au lieu de la page sur laquelle on était.


Oui, on a remarqué ça, il y a un ticket.
Ça me le fait pas du tout sur ma copie locale, et on comprend pas d'où 
ça vient.


Heu, comme je le signalais dans le ticket Nicod, je pense qu’il manque 
un env effectivement sur les inclusions aside/article et consœur. Tu 
veux que je commite ?


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] Refonte des sites et logos SPIP

2019-01-02 Par sujet Matthieu Marcillaud

Le 02/01/2019 à 11:53, Eric Lupinacci a écrit :

Hello les amis,

[...]
mais je ne suis pas convaincu par la refonte de 
Contrib qui a perdu son poulpe mais surtout qui a perdu en lisibilité (à 
mon avis) : rien ne saute aux yeux dans les pages, j'ai du mal à 
distinguer les blocs les uns des autres tout semble trop "plat", trop 
"uniforme".


Ça s’améliore avec le temps, c’est déjà ça :)


Mais ce n'est pas le propos du mail.
Le sujet de ce mail c'est le choix des couleurs, la logique si il y en a 
et les logos.


La première question est y a-t-il un logo SPIP aujourd'hui ? Peut-on 
considérer que le petit logo rose de SPIP.net remplit cet office ou pas 
en remplaçant le polatouche ? 


Je pense qu’on peut dire ça oui.

[...]

Le seconde question porte sur les couleurs.
SPIP.net a inauguré les refontes avec un look rosé à souhait.
Puis Forums a continué en choisissant un bleu plutôt pétrole (pas très 
durable ça :p) 


Et Programmer est en violet.

et maintenant Contrib a abandonné son vert pour un autre 
bleu plutôt fade.
Pourquoi ces couleurs ? Y a-t-il une logique ou pas ? 


Pour répondre «grosso modo»
- la couleur de SPIP.net reprend celle de la couleur du logo proposé,
- les autres sites tentaient de reprendre plus ou moins les couleurs des 
sites respectifs qu’ils ont remplacé. Puis ont évolués parfois pour se 
distinguer les uns des autres (Programmer en violet),
- les couleurs ont été choisies pour être lisibles en couleur de texte 
ou en couleur de fond de texte, avec une teinte au doigt mouillé qui 
plaisait,


Sinon, ne 
devrait-il pas en avoir une sachant que nous avons une boussole avec des 
catégories (Documentation, Contributions, Entraide, Découverte et 
Actualités). On pourrait peut-être décliner des nuances à partir d'une 
couleur de base pour une catégorie voir autre chose.


Il y a certainement des choses à réfléchir et améliorer de ce côté là 
tout à fait.


Ou alors, si on considère que le logo de base est la queue du polatouche 
n'aurait-il pas été intéressant de lui rajouter un élément pour 
caractériser chaque site sauf SPIP.net (par exemple un # pour le code...).


Pas trop d’avis là dessus, mais j’aime bien la simplicité de juste le 
nom du site.


Mais j’aimerais aussi qu’on puisse mieux discriminer sur quel site on 
est rien qu’avec l’entête ; mais c’est aussi peut être simplement une 
question d’habitudes.


Belle année,

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] Spip Contrib : section 'Vos commentaires' bloquée

2018-09-21 Par sujet Matthieu Marcillaud

En fait cela vient d’une modification dans la librairie GD utilisée.
On trouve https://stackoverflow.com/a/42899281 qui amène à 
https://github.com/libgd/libgd/issues/338


Ils ont re-modifié le comportement en version 2.2.5 (pour repasser à un 
warning au lieu d’une erreur fatale). Mais les versions GD inférieures, 
notamment 2.2.4 sont impactées.


Une solution qui me paraitrait plus correcte serait de dire :

if (!$srcImage = @$fonction_imagecreatefrom($image)) {
$srcImage = imagecreatefromstring(file_get_contents($image));
}

Sauf que le @ ne fait rien avant 2.2.5 (et après je ne sais quelle 
version d’ailleurs), donc dans ce cas le problème fatal serait toujours 
présent.


On pourrait aussi tenter d’améliorer l’analyse du format source 
($term_fonction) avec

$mime = finfo_file(finfo_open(FILEINFO_MIME_TYPE), $path);
Comme le fait Imagine.

MM.

Le 07/09/2018 à 12:32, Fil a écrit :

Je pense que c'est le bug que j'ai signalé récemment sur #spip

En traçant un peu je suis remonté à https://bugs.php.net/bug.php?id=73116

j'ai déjà eu le cas deux fois, il suffit qu'un fichier image soit mal 
passé pour que SPIP crashe, sans possibilité de catcher l'erreur… une 
solution est de remplacer, dans ecrire/inc/filtres_images_lib_mini.php


$srcImage = @$fonction_imagecreatefrom($image);

par

$srcImage = imagecreatefromstring(file_get_contents($image));

-- Fil




___
liste: http://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] Spip Contrib : section 'Vos commentaires' bloquée

2018-09-07 Par sujet Matthieu Marcillaud

Le 07/09/2018 à 12:32, Fil a écrit :

Je pense que c'est le bug que j'ai signalé récemment sur #spip

En traçant un peu je suis remonté à https://bugs.php.net/bug.php?id=73116

j'ai déjà eu le cas deux fois, il suffit qu'un fichier image soit mal 
passé pour que SPIP crashe, sans possibilité de catcher l'erreur… une 
solution est de remplacer, dans ecrire/inc/filtres_images_lib_mini.php


$srcImage = @$fonction_imagecreatefrom($image);

par

$srcImage = imagecreatefromstring(file_get_contents($image));


Oui, tout à fait, c’est ce problème là je pense.
Cependant, cette solution tente de charger toute l’image en mémoire, ce 
qui risque de ne va pas fonctionner non plus dans d’autres cas ?


Cela dit, c’est aussi ce qu’ielles font :

A) dans la librairie Imagine :

- 
https://github.com/avalanche123/Imagine/blob/develop/src/Gd/Imagine.php#L84
- le ->getData() faisant aussi un file_get_contents() sur les fichiers 
locaux


B) dans la librairie Intervention/Image :

- 
https://github.com/Intervention/image/blob/master/src/Intervention/Image/Gd/Decoder.php#L15 
où si imagecreatefromjpeg() ne fonctionne pas, ielles se rabattent sur 
imagecreatefromstring(file_get_contents($path))



MM.
___
liste: http://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] r24046 - spip/ecrire/inc

2018-09-05 Par sujet Matthieu Marcillaud

Le 05/09/2018 à 12:15, RastaPopoulos a écrit :

Le 05/09/2018 à 11:53, Matthieu Marcillaud a écrit :

Mais que de toutes façons je ne pense pas que ça soit pertinent : cette
constante était fausse pour tout plugin 'procure' et n’avait aucun sens
(ça n’indique pas de répertoire réellement).


Ah bé c'est bien de le savoir et de documenter la manière propre de le
faire, parce que yen a un sacré paquet des tests de ce genre pour savoir
si un plugin est bien là et faire des choses en plus en conséquence, me
semble-t-il.


Heu, je ne lançais pas de troll hein…

Et je pense que le point d’entrée correct est peut être 
test_plugin_actif() comme signale Real3t pour ces tests. L’intérêt est 
de passer par une fonction commune qu’on peut modifier ensuite plutôt 
que chacun tester une implémentation. Mais bref.


Comprends bien que les constantes en questions déclaraient des

define('_DIR_PLUGIN_ITERATEURS',_DIR_RESTREINT.'procure:iterateurs/');

ou encore

define('_DIR_PLUGIN_PHP_CURL',_DIR_RESTREINT.'procure:php:curl/');

Ce qui est totalement aberrant et trompeur.

On peut améliorer le test_plugin_actif() pour tester les procure au 
besoin, mais se baser sur ce genre de truc me semble incohérent.


MM.
___
liste: http://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] r24046 - spip/ecrire/inc

2018-09-05 Par sujet Matthieu Marcillaud



Je crains que ça casse des codes qui font :
if(defined('_DIR_PLUGIN_PREFIX')) {
pour vérifier la présence d'un plugin.


Je dirais que… déjà cette méthode serait à revoir via 
(filtre_info_plugin_dist).


Mais que de toutes façons je ne pense pas que ça soit pertinent : cette 
constante était fausse pour tout plugin 'procure' et n’avait aucun sens 
(ça n’indique pas de répertoire réellement).


MM.
___
liste: http://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] r24046 - spip/ecrire/inc

2018-09-05 Par sujet Matthieu Marcillaud

Le 04/09/2018 à 14:14, Bruno Bergot a écrit :


Details: http://core.spip.org/projects/spip/repository/revisions/24046

C'est voulu le commentaire sur #spip_attend_invalidation_opcode_cache(); ?


C’était pas du tout voulu à la base (une modification locale, sinon j’ai 
60s d’attente sur la page des plugins sans raison valable !)


Cependant je me dis qu’il faut re-réfléchir à ce truc.

On pourrait le conditionner son utilisation à une option/constante, de 
sorte que si le problème est encore rencontré sur certains sites, ils 
l’activent, mais que ça n’enquiquine pas tous les autres où ça 
fonctionne correctement même avec ces options d’opcache.


Rappel du ticket : https://core.spip.net/issues/3418

MM.
___
liste: http://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] Spip Contrib : section 'Vos commentaires' bloquée

2018-09-03 Par sujet Matthieu Marcillaud

Le 03/09/2018 à 16:45, Bruno Bergot a écrit :

Hop,

Le 03/09/2018 à 16:41, peetdu a écrit :

Hop,

Juste pour signaler que sur la page 
https://contrib.spip.net/Plugin-Inserer-Modeles, la section 'Vos 
commentaires" reste bloquée sur "Chargement en cours…"


Sur les autres pages ça marche.


Une image .jpg qui était une TIFF à l’intérieur, dans un commentaire. Je 
l’ai supprimée. Un bug à corriger accessoirement.


MM.
___
liste: http://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] [SPIPremix] Une distribution SPIP alternative

2018-07-04 Par sujet Matthieu Marcillaud

Le 04/07/2018 à 19:39, Jacques a écrit :


[...]
J'avais compris que la création des dossiers dépendait de SPIP (quelque 
soit son mode d'installation) et non pas de spip_loader ?


Oui et non. Le spip-loader déballe le fichier zip qui contient les 
fichiers de SPIP. Ce zip là n’a pas de répertoire plugins, lib ou 
squelettes (ce n’est pas nécessaire à SPIP directement, ils ne sont pas 
dans le dépot svn).


Mais le spip-loader est un script qui fait différentes actions (pas que 
déballer et copier ce zip). Il pourrait faire des actions en plus… comme 
tester si certains répertoires sont présents ou non et les créer le cas 
échant.


MM.
___
liste: http://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] [SPIPremix] Une distribution SPIP alternative

2018-07-04 Par sujet Matthieu Marcillaud

Le 03/07/2018 à 23:25, spipfactory a écrit :

Bonsoir,

[...]

Donc ne changer rien et ce qui est a la mode aujourd'hui passera demain.


Bon OK ;
On ne change rien ; ça on sait déjà bien faire :)

Les dernières versions du loader sont visiblement bien appréciées 
(auto-congratulons-nous). Je vous rappelle que son code est sur la zone 
si vous voulez qu’il crée les répertoires plugins/auto, lib, squelettes 
manquants…). Y a pas d’obstruction…


Ceci étant dit, deux points :


1) sur la mode.

Je pense que non, cela n’a rien d’une mode ! Désolé ; la communauté PHP 
a mis un temps fou à s’organiser pour trouver une solution acceptable et 
acceptée d’organisation des librairies partagées pour dire «tatata, 
c’est une mode» …


Tu n’as pas un seul nouveau projet qui se dirait : tiens nous on va 
faire du code pas objet, sans réutiliser de librairies packagées, sans 
utiliser Composer, sans suivre quelques suggestions PSR.


L’histoire personnelle de SPIP est comme cela, certes, mais faut-il 
continuer ?


Je vais tenter de faire une relation avec les plugins de SPIP. En tant 
qu’utilisateurices, on est content·e·s de voir des supers plugins naître 
ou évoluer.


Savez-vous que régulièrement, un plugin va utiliser, en sous-jacent, des 
librairies php existantes. Figurez-vous qu’actuellement on est 
profondément embêtés quand on veut utiliser une librairie récente de la 
communauté PHP : celle-ci déclare quelques fichiers à elle, et ses 
dépendances (à d’autres librairies), comme le feraient nos propres 
plugins. Du coup comment intègre t-on cette librairie dans notre plugin 
? on copiant la lib + toutes ses dépendances. Qui sont probablement les 
mêmes que les dépendances d’un autre plugin SPIP intégrant une autre 
librairie… On se retrouve avec possiblement plein de fichiers en 
doubles, de multiples autoloaders à éventuellement charger, du code 
dupliqué, des mises à jour compliquées.


Quelques exemples dans la zone :
- 
https://zone.spip.org/trac/spip-zone/browser/_plugins_/extraire_documents/trunk/lib
- 
https://zone.spip.org/trac/spip-zone/browser/_plugins_/geoip/trunk/lib/vendor

- https://zone.spip.org/trac/spip-zone/browser/_plugins_/http/trunk/vendor
- 
https://zone.spip.org/trac/spip-zone/browser/_plugins_/owncloud/trunk/lib/SabreDAV/vendor


On cherche aussi une solution à ce problème. (c’est ce que faisait la 
déclaration de librairie à télécharger dans nos paquets.xml, sauf que ça 
ne marche plus avec les libs récentes, c’est pour ça qu’on est obligé de 
les «inclure» dans un répertoire lib/ ou pas des plugins ; et c’est pas 
vraiment génial).



2) sur Composer vs Loader

Je vois difficilement comment concilier les deux.

On peut évidemment faire un loader qui chargerait un zip de SPIP (issu 
d’une installation composer). Mais ensuite ? L’intérêt de composer c’est 
qu’un plugin (spip) puisse dire dans son composer.json qu’il nécessite 
telle ou telle librairie PHP. Et installer ce plugin, via composer, 
installerait toutes les librairies manquantes dans le répertoire vendor/.


Et ça c’est difficilement compatible avec SVP (qui télécharge les 
plugins depuis une interface graphique) ou avec le Loader, qui si on 
fournit un zip de SPIP aurait déjà un répertoire "vendor" avec un 
certain contenu, un fichier composer.json racine différent, et ça 
pourrait écraser du coup nos modifications…


Il n’existe pas de méthode pour utiliser Composer depuis des interfaces 
graphiques (sans fichier composer.lock, le calcul des dépendances prend 
trop de mémoire entre autres choses) et ajouter un plugin nécessite 
forcément de recalculer ce fichier composer.lock)


Alors du coup ?

Faut-il abandonner l’idée ?
Faut-il poursuivre dans cette voie (avec les conséquences) ?
Faut-il faire une fourchette ? (ie: faut aller jouer ailleurs ?)

Chaleureusement,

MM.




___
liste: http://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] [SPIPremix] Une distribution SPIP alternative

2018-06-30 Par sujet Matthieu Marcillaud

Le 14/06/2018 à 22:29, James a écrit :

Pour tester son installation, tapez : composer create-project 
geodiv/geodiv ;)


Hello :)

Si je comprends bien, le create-project met à la racine les fichiers du 
paquet spip/spip ou geodiv/geodiv.


On est d’accord que du coup, un composer update ne mettra pas à jour ces 
fichiers racine ? En général on n’y touche effectivement pas, mais ça 
sera à préciser quand même probablement.


J’aimerais bien faire un petit point pour savoir ce qu’il reste à faire, 
à réfléchir, quels sont les décisions à prendre, etc.



Sur Composer


Déjà, pour rappeler mon avis, je pense qu’il faut déléguer dans SPIP le 
système de gestion de dépendances et d’installation (ce que fait 
Composer), pour différentes raisons (entre autres pour être un peu plus 
en phase avec la communauté PHP) ; et plus tard réutiliser des 
librairies existantes pour certains de nos besoins.


Comme SpipRemix le montre, cela soulève tout de même certaines 
problématiques d’organisation (des dépots), et modifie les usages, sans 
être bloquant non plus.



Organisation des dépots
---

Pour que le Packagist (idéalement) ou Satis (avec un peu d’huile de 
coude) puisse fournir les versions correctes des paquets (requis dans 
composer.json), il faut des dépots Git ou Svn carrés.
Carrés sur l’organisation trunk/branche/tags et sur la numérotation des 
versions Semver.


Ça veut dire qu’il faut réorganiser un certain nombre de choses sur le 
SVN (ou Git), notamment les plugins-dist sur la Zone. Ce n’est pas 
infaisable comme l’a montré James. Par contre il faudra qu’on soit 
attentifs à fournir correctement des tags/x.y.z des versions que l’on 
sort sur chaque paquet, si je comprends bien.



Cas des dépots du core
--

Le dépot du core sera aussi découpé en 3 paquets (spip, ecrire, prive).
Ce découpage, surtout ecrire/privé n’est pas très pratique pour commiter 
des modifications (les 2 vont quand même un peu de pair). Est-ce que 
c’est quelque chose de temporaire ? Est-ce qu’ils peuvent être des 
subtree d’un dépot Git plus gros ? (c’est peut être pas une bonne idée 
non plus). Est-ce qu’ils ont des versions indépendantes les uns des autres ?



Zips des plugins (smart paquets)


Dans cette nouvelle organisation, l’outil smart_paquets (qui crée les 
zips des plugins actuels) et le fichier archivelist.txt deviennent 
caduques.


Cependant cela crée aussi deux problèmes :

1) SVP (avec composer)
--

SVP ne saurait plus installer de nouveaux plugins de lui-même (juste 
gérer leur activation / désactivation).


Ceci dit une solution toute Composer voudrait qu’on "require" sur le 
site seulement les plugins nécessaires à celui-ci, et ces plugins 
pourraient être actifs par défaut dans SPIP. Ou on garde le principe de 
pouvoir activer / installer / désactiver / désinstaller un plugin depuis 
la page des plugins (mais plus le téléchargement / suppression des 
fichiers). En prenant note quand même qu’à partir du moment où un plugin 
est requis par composer, leurs chemins d’autoloading seront déclarés 
(que le plugin soit actif ou pas dans SPIP)


2) SVP (anciens sites)
--

L’autre problème qui se pose… est la gestion des plugins des sites qui 
n’ont pas migrés à Composer. Ça serait bête qu’ils ne puissent d’un coup 
plus faire fonctionner le téléchargement de SVP. Ça sous-entendrait 
qu’il faudrait continuer à faire tourner l’outil smart paquets (et les 
fichiers archivelist) quelques années encore (combien de temps ? ...)
Ou trouver une méthodologie pour que ça puisse encore fonctionner, mais 
en s’appuyant sur les paquets du packagist (et là c’est pas gagné)



Sur GIT
---

A) Core

Est-ce qu’on est d’accord pour passer le svn du core en Git ?
Est-ce gênant d’abonner l’URL svn du core ? ou est-ce que ça peut 
devenir un dépot
-- en lecture seule bloqué (mais les utilisateurs n’auront alors pas 
d’erreur indiquant que ce n’est plus à jour en faisant svn up)

-- en lecture seule synchronisé (unidirectionnel) sur le git (faisabilité ?)
-- en lecture/écriture synchronisé avec le git (comme déjà dit cette 
solution me paraît trop hasardeuse) (ce que propose azerttyu)


B) Plugins

Est-ce gênant de migrer des plugins sur Git ? (par exemple les 
plugins-dist du core ?), avec un peu les mêmes questions…


Si on déplace un plugin de svn à git (ce qui me parait plus facile que 
de tenter de synchroniser les deux), on obtient possiblement un autre 
problème pour générer les zips via smart_paquets (il faut au moins 
modifier les archivelist).



Sur les usages
--

Composer et Git modifieraient grandement les usages en basculant dessus.
Est-ce que notre petite communauté d’utilisateurs de la zone est prête à 
basculer ? J’ai le vague sentiment que oui (composer et git se sont 
largement démocratisés).


Ça nécessite tout de même de revoir grandement le Spip Loader pour 
l’installation facile 

Re: [spip-dev] Dromen 2018

2018-06-30 Par sujet Matthieu Marcillaud


C’est cool, merci les gens de l’organisation.
Y a du monde alors ? Ça va être la fête ?
Faut composer quelques morceaux ?

MM.


Le 01/06/2018 à 09:02, Ben. a écrit :

Bonjour,

alors voilà on y est : les inscriptions pour la prochaine SPIP-party 
sont ouvertes.


Cela se passera dans la drôme du *jeudi 27 septembre* au *dimanche 30 
septembre*


C'est ouvert à tous et à toutes ( dans la limite des places disponibles 
:) ) , alors n'hésites pas à t'inscrire, c'est par ici : 
https://party.spip.net/Dromen-2018


Ben & Nicod


___
liste: http://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] Comportement étrange

2018-06-22 Par sujet Matthieu Marcillaud

Le 22/06/2018 à 10:37, Manu a écrit :

Le 22/06/2018 à 10:07, Matthieu Marcillaud a écrit :



Tes domaines habituels pointent donc vers public_html/spip
Ton domaineA pointe sur public_html/domaineA


Donc… si c’est bien comme ça, tu comprendras que ça n’a rien à voir avec 
SPIP.


Autres pistes :
- public_html/domaineA n’est pas un lien symbolique (genre vers 
public_html/sites/domaineA !) ? "ls -lah" pour le voir

- tu as un public_html/.htaccess qui ferait quelque chose ?

Sinon, il y a quelque chose dans les vhosts qui n’est pas correct.

MM.
___
liste: http://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   >