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

2020-09-26 Par sujet Charles Razack

go go go !

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

Hello everybody !

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


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


Je pense ajouter également, enfin remplacer plutôt, le fichier 
.gitsvnextmodules par un fichier spip_modules.json ou quelque chose 
comme ça dans les branches 3.1+. 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

___
liste: https://listes.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-29 Par sujet Charles Razack
Je vote pour migrer le plugin chats, même s'il est plus ou moins
obsolète depuis la fabrique.
C'est un repère historique majeur ^^

Le 29/06/2020 à 19:25, Eric Lupinacci a écrit :
> Hello,
>
> Avec quelques regex sur _plugins_ j'ai identifié des plugins
> compatibles spip 3 mais non migrés.
> Il y a en environ 150.
> La liste est ici : http://spip.pastebin.fr/63331
>
> J'ai mis un commentaire sur certains qui me paraissent obsolètes.
> Pour le reste il faut décider mais au moins on a une liste.
>
> ++
> Eric


pEpkey.asc
Description: application/pgp-keys
___
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] spam, spam, lovely spam

2020-06-11 Par sujet Charles Razack
Nouvelle collection printemps/été 2020 pour les spams sur forum.spip.net
: des comptes factices copient un message existant, le traduisent dans
une autre langue, et insèrent quelques liens en plein milieu. Ainsi on a
presque l'impression qu'il s'agit d'un message légitime : malin.
Heureusement nospam veille au grain, ils sont toujours détectés comme
spams potentiels.



pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Plugin pour gérer des livraisons en points relais

2020-06-03 Par sujet Charles Razack
Le 03/06/2020 à 20:21, cy_altern a écrit :
> très bonne idée! Tu envisage un plugin sur la zone et ouvert à tous les
> contributeurs ou une formule à la "bank" sur une forge "externe" où
> toutes les contributions passent par PR ?

Je pense le mettre sur la zone pour encourager les contributions. En ce
qui me concerne ça va être fait sur mon temps libre, dans l'immédiat
c'est pour dépanner des amis. Et donc le temps disponible étant limité,
autant ouvrir les contributions :)

> vu comme ça c'est séduisant mais pas certain qu'essayer de faire une
> base générique complètement intégrable avec le prestataire ne soit pas
> une embuscade à moyen terme : pour avoir fait de l'intégration de
> modules de livraisons sur un outil de e-commerce, j'ai pu constater que
> certains d'entre eux ne se gênent pas pour faire des mise à jour de
> sauvages avec rupture complète de compatibilité sans se poser de questions!
> => peut être qu'une base "livraison" la plus agnostique possible serait
> suffisante, la connexion avec un prestataire étant limité à une liaison ?

Oui je crois que n'aurais pas dû rentrer si tôt dans le détail pour le
cdc, surtout avant d'avoir fini de poser les specs.
Mais dans l'idée je pense que ça rejoint ce que tu dis : pour
reformuler, il s'agirait bien d'avoir une base fonctionnelle toute
simple, et par dessus chaque presta pourra ajouter des fonctionnalités
afin d'avoir une intégration plus ou moins poussée.

La base fonctionnelle me semble être ça : un widget pour choisir un
point relai sur une carte, et l'enregistrement de ce choix sur le site.

Et ensuite chaque presta pourrait ajouter des fonctionnalités
supplémentaires de cet ordre : faire le suivi d'une livraison, récupérer
les étiquettes à imprimer, etc.
Mais tu as raison, il faudra limiter les fonctionnalités  pour ne pas se
perdre en maintenance.

Mondial Relay permet une intégration relativement complète (des
webservices basés sur du xml, youpi), mais pour Relais Colis il semble
n'y avoir aucune API donc l'intégration se résumerait à un lien vers
leur BO et basta.

Merci pour les retours :)


>
> ++
> cy_altern
>


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Une astuce CSS pour l'internationalisation

2020-05-20 Par sujet Charles Razack
Très intéressant, merci pour l'info.

On retrouve la même logique que flexbox avec start/end.
La syntaxe est finalement assez naturelle, comme d'habitude la
difficulté c'est le support des vieux navs qui oblige à avoir des CSS
plus verbeuses.

Le 19/05/2020 à 09:49, RealET a écrit :
> RealET a écrit le 23/04/2020 à 23:13 :
>> Hello,
>>
>> Je suis tombé sur https://piccalil.li/tutorial/css-logical-properties/
>> qui présente margin-inline-start: 1em;
>> qui met une marge au début d'un texte en tenant compte de son
>> orientation (selon la langue).
>>
>> Et y'en a plein d'autres :
>> https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Logical_Properties
>>
>> Si ça peut être utile ;-)
>>
> Et j'en rajoute une couche :
> https://medium.com/@elad/new-css-logical-properties-bc6945311ce7
>


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] checkout.php intégré dans spip-cli

2020-04-30 Par sujet Charles Razack
Bonne nouvelle !

Qu'en est-il pour les mises à jour ? La commande core:mettreajour
détecte automatiquement si c'est une installation en git, svn ou ftp ?

Le 30/04/2020 à 03:25, RastaPopoulos a écrit :
> Comme expliqué dans ce commit, checkout.php est intégré à 99% dans spip-cli :
> https://git.spip.net/spip-contrib-outils/spip-cli/commit/f8c6ac694c46591f19db008998c301b4bd0407d0
>
> Comme d'hab avec Console : "spip help dl" ou "spip dl -h" pour avoir la jolie 
> aide
>
> spip-cli, avec sa commande "spip dl" est donc désormais parfaitement à jour 
> de notre architecture, et fait même bien plus (n'importe quel dépôt SVN, Git, 
> FTP).
>
> À vos tests ! (sachant que ça va encore bouger un peu, cf ci-dessous)
>
>
> ## Différence avec l'ancienne version
>
> Avant l'option raccourcie -r correspondait à --release (pour demander une 
> version exacte stable, un tag), mais désormais ça correspond à --revision 
> pour suivre checkout.php.
> La version raccourcie de --release devient -R (majuscule), mais n'est plus 
> utilisée pour le moment.
>
> Pour le mode "SPIP complet", c'est désormais en Git, et plus en SVN, puisque 
> repris de checkout.php.
>
>
> ## Différences mais qui doivent revenir comme avant
>
> Pour le moment checkout.php a été intégré tel quel, et du coup comme dit dans 
> le log, pour le mode "SPIP complet" ça télécharge du DEV par défaut. Ce que 
> je ne trouve pas super. Je pense que je vais refaire un passage dessus pour 
> retrouver l'ancien comportement et toujours avoir du stable par défaut. 
> Celleux qui veulent du dev savent manipuler les options.
>
> En lien avec le point précédent, pouvoir demander du stable d'une branche 
> donnée X ou X.Y (la dernière stable de 3, la dernière stable de 3.1…) comme 
> avant, avec --release. Ce mode a complètement disparu pour l'instant (puisque 
> n'existe pas dans checkout.php).
>
> Si on arrive à remettre ces deux points, il n'y aura quasiment pas de 
> différence avec avant.
>
>
> ## Différence avec checkout.php
>
> Pour l'instant je n'ai pas (encore ?) repris le mode "force" qui supprime 
> tout et refait, un truc dans ce genre. Mais c'est la seule chose pas reprise 
> il me semble.
>
> Et "spip dl" sait télécharger dans le dossier courant, alors que checkout.php 
> demande toujours d'être ailleurs (dans le dossier parent ou complètement 
> ailleurs)
>


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.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://git.spip.net/explore/organizations

2020-04-24 Par sujet Charles Razack

Le 24/04/2020 à 18:17, teamspipfact...@gmail.com a écrit :
> Hello
>
> j'ai récupéré un plugin ici :
> https://github.com/cariagency/spip-pseudo-hasard

"Récupéré" mais comment, avec la commande git clone ? Un script ? Autre ?



pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Maintenance git.spip.net - 17 avril 2020

2020-04-17 Par sujet Charles Razack

Super merci Camille.

Il y a 5mn ça avait l'air reparti comme en 40, mais à l'instant ça 
abouti à une erreur 503.


Le 17/04/2020 à 15:19, cam.lafit a écrit :

Bonjour

Le second disque est en place. Le service git est à nouveau disponible.

Il sera encore ralenti pour environnement  1h le temps que les disques 
se synchronisent.


Km

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


Re: [spip-dev] Pusher un tag

2020-04-17 Par sujet Charles Razack

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

Non, malheureusement.
Il y a la possibilité de créer une "release", mais c'est trompeur, ce 
n'est pas un tag au sens Git.
Je crois que c'est un peu entre les deux : en créant une version gitea 
propose de créer en même temps le tag s'il n'exite pas.

Mais on ne peut pas juste créer un tag tout seul semble-t-il.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] oups ? vs ’

2020-04-14 Par sujet Charles Razack
Bizarrement dans l'explorateur de fichiers de gitea le problème n'est
pas présent :
https://git.spip.net/spip-contrib-extensions/facteur/src/branch/master/inc/Facteur/FacteurMail.php#L107
geany, gedit et vscode donnent aussi le bon charset sans problème d'accent.

Fausse alerte juste sur l'affichage du diff dans gitea ?

Le 15/04/2020 à 00:32, JLuc a écrit :
> Voulant corriger un problème de charset dans la v4 (test) de facteur,
> j'ai peut être introduit des problèmes bien pires de charset.
>
> Il fallait simplement corriger un ? en ’
> pour régler https://git.spip.net/spip-contrib-extensions/facteur/issues/3
> J'ai donc corrigé via l'éditeur interactif de gitea...
> et ça a donné des saletés sur ce caractère
> mais aussi sur d'autres caractères accentués des commentaires
> https://git.spip.net/spip-contrib-extensions/facteur/commit/503ca152f1b3b55ffc576a1efba084602aa8c36d
>
>
> Oups.
>
> J'ai alors cloné localement le repo pour mieux y voir et corriger la
> correction,
> mais tout à l'air bon dans la version locale du fichier après mon fix :
> geany détecte un fichier utf8 et il n'y a aucun pataquès cacaoteux à
> la place des ’ dans le code
> ou des ê dans les commentaires.
>
> Du coup qu'est-ce donc qui ne va pas ?
> l'UI gitea s'égare dans les charset ? ou le fichier est marabouté ?
> Je sèche là.
>
> JL
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.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] r124144 - in _plugins_/coordonnees/trunk

2020-04-10 Par sujet Charles Razack
clap clap clap 

Le 10/04/2020 à 22:09, spip-zone-com...@rezo.net a écrit :
> Author: RastaPopoulos
> Date: 2020-04-10 20:09:13 + (Fri, 10 Apr 2020)
> New Revision: 124144
>
> Modified:
>_plugins_/coordonnees/trunk/
>_plugins_/coordonnees/trunk/action/api_adresses_par_pays.php
>_plugins_/coordonnees/trunk/coordonnees_pipelines.php
>_plugins_/coordonnees/trunk/formulaires/editer_adresse.php
>_plugins_/coordonnees/trunk/paquet.xml
> Log:
> Pfiou, normalement enfin finalisation de la refonte des adresses dont on peut 
> changer le pays et que ca change les champs demandes. Car il manquait un GROS 
> truc oublie : si on change le pays, c'est plus les memes champs, et DONC... 
> 1) c'est plus les memes verifications a faire, et 2) si ca s'arrete dans 
> verifier() et donc qu'on reaffiche le formulaire, ca ne doit pas afficher les 
> champs du pays de depart, mais bien ceux du pays modifie ! Et donc pas en JS 
> cette fois mais en PHP. Du coup il faut faire un travail similaire a ce qu'on 
> avait fait en JS, mais dans un pipeline PHP (formulaire_saisies en 
> l'occurence) et c'est pas aussi facile qu'avec jquery sous la main evidemment 
> ! Mais quand meme plus facile en saisies que s'il fallait le faire avec du 
> html... Ah et du coup tout comme le JS, cette solution fonctionne donc pour 
> n'importe quel formulaire qui contiendrait des adresses, pas juste 
> editer_adresse, et pas juste Profils.
>
>
> Details: https://zone.spip.org/trac/spip-zone/changeset/124144
>
> ___
> spip-zone-com...@rezo.net - 
> https://listes.rezo.net/mailman/listinfo/spip-zone-commit


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Squelettes et thèmes sur contrib

2020-04-07 Par sujet Charles Razack

Merci pour le récap, j'y vois plus clair.

Du coup oui, à continuer sur le loomio.

Le 07/04/2020 à 10:40, RastaPopoulos a écrit :

Le 07/04/2020 à 09:33, Eric Lupinacci a écrit :

Néanmoins, il y a pas mal de choses de faites sauf la refonte ergo mais qui ne 
doit pas juste se limiter aux squelettes et aux thèmes.

+1, reprenons donc là où ça en était, il y a déjà un gros historique des tâches 
et arguments pour chacune sur le framavox, pas de raison de se ré-éparpiller 
ailleurs.

On reprend les actions commencée, on en crée de nouvelles s'il faut (l'ergo 
générale, l'accueil, etc), et on prend en groupe les décisions pour chacune, 
bien rangée et retrouvable facilement (toujours le même soin de rangement et 
d'histo, pas dans 50 fils emails croisés donc :p).


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


Re: [spip-dev] Squelettes et thèmes sur contrib

2020-04-06 Par sujet Charles Razack
Et pour illustrer simplement la proposition, quelques exemples assez
proches :

  * https://getgrav.org/downloads/themes
  * https://ghost.org/marketplace/
  * https://jekyllthemes.io/

On pourrait faire aussi bien, voir mieux :)


Le 07/04/2020 à 00:03, Charles Razack a écrit :
> Le 06/04/2020 à 23:54, RastaPopoulos a écrit :
>> Je crois que la réponse rapide c'est :
>> - au départ on a commencé une refonte de Contrib
>> - puis ça a dérivé sur une refonte-fusion avec plugins.spip, et donc avant 
>> tout sur un rangement correct des contenus suivant les catégories
>> - puis les efforts se sont concentrés sur la migration en Git de tout, et 
>> non plus seulement du core
>> - et du coup en fait la refonte *ergonomique* de Contrib, qui était le 
>> projet de tout départ, s'est en fait arrêté pour l'instant
>> - mais donc personne n'a voulu spécialement la navigation actuelle, c'est 
>> juste le rangement brut, sans refonte ergo
>>
>> Et donc bah oui, go go, faut continuer la conception *ergo* ! :)
>> (et pas que pour squelettes et thème hein, ya plein de choses à voir pour 
>> l'accueil général, l'accueil d'un projet, etc)
>> => https://framavox.org/g/HWIQ0bwl/spip-ga-refonte-de-contrib-spip-net
>>
> Ah mais oui, la fameuse action 6, j'avais oublié depuis le temps :p
>
> https://framavox.org/d/Bi4WPago/action-6-o-mettre-en-valeur-les-th-mes-et-squelettes-
>
> Oui il est temps de passer à l'ergo, aux maquettes filaires et tout ça.
>
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Squelettes et thèmes sur contrib

2020-04-06 Par sujet Charles Razack
Le 06/04/2020 à 23:54, RastaPopoulos a écrit :
> Je crois que la réponse rapide c'est :
> - au départ on a commencé une refonte de Contrib
> - puis ça a dérivé sur une refonte-fusion avec plugins.spip, et donc avant 
> tout sur un rangement correct des contenus suivant les catégories
> - puis les efforts se sont concentrés sur la migration en Git de tout, et non 
> plus seulement du core
> - et du coup en fait la refonte *ergonomique* de Contrib, qui était le projet 
> de tout départ, s'est en fait arrêté pour l'instant
> - mais donc personne n'a voulu spécialement la navigation actuelle, c'est 
> juste le rangement brut, sans refonte ergo
>
> Et donc bah oui, go go, faut continuer la conception *ergo* ! :)
> (et pas que pour squelettes et thème hein, ya plein de choses à voir pour 
> l'accueil général, l'accueil d'un projet, etc)
> => https://framavox.org/g/HWIQ0bwl/spip-ga-refonte-de-contrib-spip-net
>
Ah mais oui, la fameuse action 6, j'avais oublié depuis le temps :p

https://framavox.org/d/Bi4WPago/action-6-o-mettre-en-valeur-les-th-mes-et-squelettes-

Oui il est temps de passer à l'ergo, aux maquettes filaires et tout ça.



pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Squelettes et thèmes sur contrib

2020-04-06 Par sujet Charles Razack
Ps : et oui je dis beaucoup « il faudrait ci » et « il faudrait ça »
dans le message, mais c'est sous-entendu que ça me dit fortement de m'y
coller avec celleux que ça intéresse, pourvu qu'il y ait un feu vert
bien sûr.



pEpkey.asc
Description: application/pgp-keys
___
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] Squelettes et thèmes sur contrib

2020-04-06 Par sujet Charles Razack
Anecdote du soir : en voulant dépanner un⋅e primo arrivant⋅e qui
cherchait des squelettes et des thèmes, j'ai voulu l'aiguiller sur la
bonne page dans contrib et là je me suis retrouvé pris au dépourvu,
depuis la page d'accueil je n'ai pas retrouvé où ils étaient non plus.
Un petite recherche et j'ai fini par voir que c'était dans l'entrée de
menu « interface publique ».

Attention je ne viens pas remettre en question l'énorme travail de
classement fait par eric :)
Cette discussion ne porte pas spécifiquement sur les catégories et le
classement des articles.

Si techniquement ces articles relèvent effectivement de l'« interface
publique », par contre sur le site public personne ne va penser à aller
chercher ces contenus là-dedans.
Ceux qui découvrent SPIP cherchent tout simplement des « thèmes » ou des
« templates » – ou des squelettes s'ils ont commencé à se documenter sur
spip.net.
C'est même valable pour les ancien⋅nes aussi :)

Ensuite une fois arrivé dans ce secteur, on a l'arborescence classique
de rubriques et d'articles, avec parfois plusieurs niveaux de
sous-rubriques : il faut aller tout au bout de la navigation jusqu'à
l'article final pour enfin avoir éventuellement une capture d'écran et
voir à quoi ressemble tel squelette ou tel thème. Ça doit en décourager
pas mal.

Je pense qu'au-delà de donner accès à la documentation, cette partie de
contrib a un rôle de vitrine et devrait se rapprocher de l'herbier.
Bref il s'agirait de mettre les thèmes et squelettes en avant et
permettre de les retrouver de façon intuitive. Pas exactement un mini
site dans le site, mais quelque chose entre les 2.

Quelques premières pistes de réflexion :

*1) Navigation*

La navigation sur le site public n'a pas a refléter systématiquement le
rangement dans le privé. C'est une bonne règle générale, mais on peut y
déroger selon les cas.
Il pourrait par exemple y avoir une limite à 2 niveaux de profondeur :

  * Niveau 0 : en page d'accueil, 2 entrées « Thèmes » et « Squelettes »
à la racine dans le menu de navigation (à la place de « Interface
publique » donc).
  * Niveau 1 : ces liens mènent directement à une liste filtrable de
tous les thèmes ou squelettes.
  * Niveau 2 : enfin en cliquant sur un thème/squelette on arrive à
l'article de documentation.

*2) Présentation / UX
*

Liste des squelettes / thèmes : il s'agirait d'une liste identique à
l'herbier. Une liste de vignettes avec des captures d'écran qui montrent
en 1 coup d'oeil à quoi ressemble tel squelette ou thème.
Cette liste serait filtrable par catégories / famille de squelettes,
c'est à dire les sous-rubriques « squelettes généralistes », «
squelettes éditoriaux » etc.
Les liens/filtres n'ont pas à amener forcément vers la sous-rubrique,
mais pourraient laisser sur la même page avec la liste filtrée.

Sur la page d'accueil, je me dis aussi qu'il pourrait y avoir une
section à part pour les squelettes et thèmes. Pas forcément les plus
"chauds", mais les derniers publiés, sous la mise en avant des articles
"normaux".
Et présentés sous la même forme : une liste de vignettes.



Bon, ce sont juste des 1ères réflexions, sans s'engager sur comment
faire techniquement. Ça implique forcément une composition spéciale pour
ce secteur, et sans doute d'autres choses et problématiques auxquelles
je n'ai pas pensé.

Chaque chose en son temps, là c'est avant tout pour recueillir les avis
sur le principe général.




pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Mysql 8

2020-04-04 Par sujet Charles Razack
Mysql 8.0.19 en local et aucun problème constaté non plus.

Cela dit la plupart de mes bases en local sont en sqlite, donc j'ai pas
testé assidument en mysql.

Le 04/04/2020 à 20:04, nicod_ a écrit :
> Le 02/04/2020 à 17:59, nicod_ a écrit :
>> Hello,
>>
>> quelqu'un peut me confirmer que SPIP 3.2+ est bien compatible Mysql 8 ?
>>
>> Chez moi MariaDB 10.1, aucun problème.
>
> Personne n'est sur Mysql 8 avec SPIP ?
>
> Même en local ?
>


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.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 Charles Razack


Le 01/04/2020 à 12:59, Cerdic a écrit :
On parlait de l’outil que Camille propose pour taguer a posteriori 
tous les projets qu’on a importé sur la zone, mais qui est trop verbeux


Oups j'avais zappé le changement de sujet au cours de la discussion. Je 
me suis pas encore fait au changement d'heures, c'est dur le matin.

Ok si les remarques concernait l'outil de tag, c'est plus clair.


La méthode pour poser des tags n'a rien de propre à SPIP, c'est 
totalement la même convention qui est utilisé sur github, dans 
l'univers composer etc...


Oui mais je me demandais si le débardeur induisait une "restriction" à 
l'utilisation des tags justement. Donc à priori pas spécialement, joie.


Et bien c'est cool tout ça, incidemment ça va permettre de mettre les 
choses à plat pour l'utilisation branches et le versionnage des plugins.


J'avoue que j'avais tendance à me forcer à faire au minimum un +z à 
chaque commit pour je sais plus quelle raison au juste (force de 
l'habitude sur la zone ? légende urbaine pour la génération des zip ?). 
Mais du coup plus besoin de faire ainsi, ça peut attendre qu'il y ait un 
ensemble cohérents de commits qui correspondent vraiment à une montée de 
version avant de poser un tag.



___
liste: https://listes.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 Charles Razack
Après relecture de toutes les réponses sur la partie tag, j'avoue que 
c'est toujours pas très clair pour moi sur ce que ça implique 
concrètement quand on maintient un plugin.


Je crois que la confusion pour ma part vient du fait qu'à la base un tag 
sert juste à signaler une version (le truc de base de git, et c'est 
normal qu'il y en ait moults), mais donc là ça pourrait amener à flooder 
le débardeur, même s'il se retreint au dernier tag d'une branche X.Y, 
c'est ça ?


Dans ce cas quelle est la bonne pratique pour taguer les dépôts ?

Des questions plus précises :

1) « il faut revoir l’outil pour qu’il [...] ne pose que les tags sur 
les dernières versions » : un truc m'échappe, ça n'est pas toujours aux 
mainteneurs de poser les tags ? Ça veut dire que le débardeur en pose 
lui-même ?


2) Pour que le débardeur reconnaisse la version x.y.z à partir d'un tag, 
est-ce qu'il faut respecter une certaine nomenclature ? "v1.2.3", ou 
juste "1.2.3", ou autre ?


3) Mettons que pour un plugin, je ne veuille proposer qu'un seul zip par 
branche X : je fais comment ?
Exemple : il y a déjà des tags v1.0.x et j'ajoute un tag v1.1.0 suite à 
une nouvelle fonctionnalité → je supprime tous les anciens tag v1.1.x ?


Comme la méthode pour poser les tags semble propre à l'écosystème de 
SPIP, amha il faudrait bien documenter et clarifier avant de basculer, 
avec des exemples etc.


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 ?

Charge au mainteneur d’ajouter les autres tags importants à la main ?

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

Re: [spip-dev] Incident sur git.spip.net

2020-03-27 Par sujet Charles Razack
merci pour l'info, doigts croisés

Le 27/03/2020 à 19:32, cam.la...@azerttyu.net a écrit :
> Bonjour
>
> Depuis 18h les services ne sont plus disponibles.
> Un des disques a à nouveau posé problème. Lors du reboot le disque a
> été corrompu et a décidé de ne plus vouloir rebooter.
>
> Une opération est en cours pour restaurer l'état du disque, j'espère
> que cela se passera bien.
> Pour le moment aucune idée avant rétablissement du service.
>
> Km
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Role liaison gis

2020-03-19 Par sujet Charles Razack

Le 19/03/2020 à 16:16, Bruno Bergot a écrit :

Juste par curiosité, il est où ce plugin gis_role ?



Bien au chaud sur le git : 
https://git.spip.net/spip-contrib-extensions/roles_gis


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


Re: [spip-dev] Validation des PR sur le core

2020-03-17 Par sujet Charles Razack
Et j'en profite pour faire de la pub sur ce PR qui traine depuis 3 mois,
histoire de savoir si ça peut passer dans la 3.3 ou après ou pas du tout
: https://git.spip.net/spip/porte_plume/pulls/1

Nb : ça peut être déplacé dans une branche de dev de la dist si besoin,
à l'époque c'était pas encore bien calé tout ça.

Le 17/03/2020 à 21:30, nicod_ a écrit :
> Le 17/03/2020 à 20:56, tofulm a écrit :
>> Après cela demande à s'abonner à tous les plugins, et la c'est plus
>> compliqué
>
> On parle bien du core uniquement hein (SPIP + plugins-dist) :
> https://git.spip.net/spip
>
> >>> Camille signalait qu'il a appliqué une modif pour que tous les
> >>> membres du core suivent tous les projets de l'orga SPIP, c'est
> donc bon.
> >>
> >> Rasta disait que c'était pas le cas, à vérifier ?
>
> Et on parle donc de l'équipe SPIP :
> https://git.spip.net/org/spip/teams/spip
>
> Est ce que tout le monde reçoit bien les notifications de PR ?
>


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Validation des PR sur le core

2020-03-17 Par sujet Charles Razack
Ahoy, merci nicod_ de relancer le sujet :)

2 à 3 validations à base de +1 me semble un nombre raisonnable aussi au
regard du nombre de personnes actives et des disponibilités. J'ai envie
d'ajouter quand même : sous réserve qu'il n'y ait pas discussion non
résolue en cours sur le PR en question, puisque l'idée reste d'acter un
consensus.
Et aussi que lâcher un +1 suppose dans la mesure du possible que le PR a
été testé, c'est pas juste l'équivalent de dire "ah ouais bonne idée".

Voilà sinon moi je reçois bien toutes les notifs pour l'orga spip, mais
je ne sais plus si c'est suite à l'abonnement automatisé en masse ou si
je m'étais abonné manuellement à tous les dépôts. Ce qui ne nous avance
pas sur la question j'en conviens.


Le 17/03/2020 à 21:30, nicod_ a écrit :
> Le 17/03/2020 à 20:56, tofulm a écrit :
>> Après cela demande à s'abonner à tous les plugins, et la c'est plus
>> compliqué
>
> On parle bien du core uniquement hein (SPIP + plugins-dist) :
> https://git.spip.net/spip
>
> >>> Camille signalait qu'il a appliqué une modif pour que tous les
> >>> membres du core suivent tous les projets de l'orga SPIP, c'est
> donc bon.
> >>
> >> Rasta disait que c'était pas le cas, à vérifier ?
>
> Et on parle donc de l'équipe SPIP :
> https://git.spip.net/org/spip/teams/spip
>
> Est ce que tout le monde reçoit bien les notifications de PR ?
>


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Espace au début d'un code

2020-03-17 Par sujet Charles Razack

Le 17/03/2020 à 07:43, Gildas Cotomale a écrit :


Quand j'écris la balise  suivie d'une espace, je ne pense
pas que celle-ci devrait être supprimée.
Bug ou feature ?


(...) Si avec tout ça, ça persiste, alors t'auras identifié un bogue 
(le traitement de SPIP n'est pas supposé virer les espaces mais juste 
transformer les signes supérieur-à et inférieur-à en leur entité)


Calomnies, SPIP ne supprime aucun espace :p
C'est un comportement navigateur.
Pour forcer à garder tous les espaces, il faut soit utiliser la balise 
, soit le faire en CSS avec white-space:pre; par exemple.


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

Re: [spip-dev] Espace au début d'un code

2020-03-16 Par sujet Charles Razack
Ouii :  :screen-follow-mouse :
screen-mouse-image=C:\mouse.png

Le 17/03/2020 à 00:16, Stephane Santon a écrit :
> Le 17/03/2020 à 00:06, Gildas Cotomale a écrit :
>>  >  ?
>>     Ben non, je ne veux pas écrire le code html d'une espace
>> insécable...
>>
>>     Je désire écrire *le caractère* 'espace', de code %20.
>>
>> 
>
> NAAANN !! Je veux écrire *le caractère*, /PAS son code/ !
>
> Quand j'écris la balise  suivie d'une espace, je ne pense pas
> que celle-ci devrait être supprimée.
> Bug ou feature ?
>


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.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 Charles Razack

Le 09/03/2020 à 16:34, Matthieu Marcillaud 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.


La doc donne pourtant ceci comme 1er exemple : 
https://www.spip.net/fr_article6372.html


#CHEMIN_IMAGE{article}

retournera
prive/themes/spip/images/article-24.png

C'est certes un cas un peu différent de #CHEMIN_IMAGE{article-24}, mais 
ça laisse à penser que l'extension est optionnelle.


___
liste: https://listes.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 Charles Razack

J'ai justement remarqué ça hier.

C'est bien l'absence d'extension qui fait merder, ceci fonctionne : 
#CHEMIN_IMAGE{edit-24.png}


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

Hello,

Depuis quelques jours je me suis aperçu que l'icone d'édition d'une 
noisette dans la liste des noisettes d'un bloc de page a disparu.
Le code de l'inclusion formulaires/inclure/inc-resume_noisette.html 
qui affiche cette liste est le suivant :
data-action="modifier" 
title="<:noizetier:formulaire_modifier_noisette|attribut_html:>">

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

Je gage que cela vienne des évolutions sur les SVG car ce code n'a pas 
changé depuis pas mal de mois (icone_renomme() renvoie un chemin avec 
une truc ?24px à la fin).
Je ne sais pas si c'est l'absence de .png dans le nom de l'icone ou 
autre chose qui fait merder mais en tout cas la balise  est vide in 
fine.
J'ai pas trop suivi les évolutions sur les icones et le SVG donc si 
quelqu'un a une idée je suis preneur.


++
Eric

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

Re: [spip-dev] Inscription ouverte des contributeurices (choses à résoudre)

2020-03-02 Par sujet Charles Razack

Le 02/03/2020 à 10:07, Gildas Cotomale a écrit :


C'est un peu un non sens de vouloir fermer aux gens mais la
majorité à raison :)


Ce n'est pas fermé aux vrais gens (les bots oui) ;  c'est juste soumis 
à une procédure humaine (je ne vois pas le lien vers la page qui 
devait être rajoutée) et chaleureuse :-)


Personne n'est vraiment contre le fait que les gens puissent 
s'inscrire, sous réserve qu'ielles acceptent la charte et s'inscrivent 
à la liste dans la foulée...



+1
À minima reste à ajouter ce lien vers la charte et un court texte 
d'explication/bienvenue.
Et même, le contenu de cette page d'accueil devrait être discuté dans un 
ticket dans un ticket dédié amha (on met quoi, dans quel ordre, etc.).


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

Re: [spip-dev] Mise à jour git.spip.net

2020-02-25 Par sujet Charles Razack



Le 25/02/2020 à 12:23, Charles Razack a écrit :
Quand on "watch" un dépôt sur gitea, on est notifié de certaines 
activités (tickets, prs, ...), mais pas des commits.
C'est juste un constat de l'actuel, sans préjuger de ce qu'il est 
possible de faire/configurer.

En lien avec ce ticket : https://github.com/go-gitea/gitea/issues/145
Toujours pas de « E-Mail notifications for pushes »
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] Mise à jour git.spip.net

2020-02-25 Par sujet Charles Razack

Le 25/02/2020 à 12:16, nicod_ a écrit :

Ah.

Quelle est le fonctionnement que tu as observé, et que faudrait il 
mettre en place alors ?
Quand on "watch" un dépôt sur gitea, on est notifié de certaines 
activités (tickets, prs, ...), mais pas des commits.
C'est juste un constat de l'actuel, sans préjuger de ce qu'il est 
possible de faire/configurer.

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


Re: [spip-dev] Changer les label saisie oui non

2020-02-21 Par sujet Charles Razack

Il n'y a pas d'option pour ça dans la saisie oui_non.

À la place tu peux utiliser une "vraie" saisie radio :

[(#SAISIE{radio,disposition,
   label=<:zbox:disposition:>,
   data=#ARRAY{oui,"bla bla bla", non,"bli bli bli"},
})]


Le 21/02/2020 à 10:52, Luis a écrit :

Comment fait pour changer les labels d'un oui_non ?


[(#SAISIE{oui_non,disposition}{label=<:zbox:disposition:>}
{CASOUI=yesyes}
{CASNON=nono})]

Merci

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

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


Re: [spip-dev] [Spip-zone-commit] r122565 - _plugins_/devise/trunk

2020-02-19 Par sujet Charles Razack

Hum, oui ok.
Est-ce qu'on pourrait pas exclure les plugins en dev de ces vérifs, là ?
Une montée de version peut être prévue d'avance après un ensemble de 
commits. Sauf que là t'es passé au milieu.


Le 19/02/2020 à 10:47, spip-zone-com...@rezo.net a écrit :

Author: spip.fra...@lien-d-amis.net
Date: 2020-02-19 09:47:02 + (Wed, 19 Feb 2020)
New Revision: 122565

Modified:
_plugins_/devise/trunk/paquet.xml
Log:
Quand il y a changement de borne de compatibilite, il faut faire un z+1 mini 
pour que les sites utilisant le plug le sachent


Details: https://zone.spip.net/trac/spip-zone/changeset/122565

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

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


Re: [spip-dev] Mise à jour git.spip.net

2020-02-17 Par sujet Charles Razack

Le 17/02/2020 à 16:22, nicod_ a écrit :

Dans le même temps la configuration du serveur a évolué :
* tout commit sur un dépôt activera le mode observateur pour le compte
concerné (ce qui aménera les notifications pour les nouvelles PR,
demandes, )

Super tout ça, merci !


* toute création d'un dépôt forcera le mode observateur pour
l'ensemble des comptes associé à l'organisation (ce qui s'approche
d'un abonnement à la liste spip-zone-commit)
Ça veut dire que la création d'un dépot sur spip-contrib-extensions va 
abonner 481 contacts aux notifications de ce dépot ?


Il me semble qu'avec ces 2 ajouts, on arrive à reproduire le 
fonctionnement actuel des notifs de la zone, me trompe-je ?
En gros dès qu'il y a un commit, ça notifie toutes les personnes 
concernées (celles de l'orga et/ou celles qui ont participé au dépôt sur 
lequel porte le commit).

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


Re: [spip-dev] [Spip-zone-commit] r122490 - in _plugins_/prive_fluide/trunk

2020-02-17 Par sujet Charles Razack

Hoy,

C'est sur le PR indiqué par rasta + mentionné dans un des derniers 
commentaires du ticket 4148.


Ça ne reprend que la base minimale du plugin : uniquement largeur 
étendue + du responsive, pas de remaniement du body.html (juste 
supression du mode écran large). Les autres choses à ajuster 
éventuellement sont en discussion.


Je peux déplacer le dépôt ailleurs si besoin (ça va pas casser le PR ? 
), mais je préfèrerais que ça ne reste accessible en écriture qu'à 
l'équipe du noyau : dedans il y a pleins de branches expérimentales, des 
choses en cours... Du coup, l'orga contrib, je sais pas trop. Je peux 
aussi ajouter manuellement tout le monde en collaborateur dessus et voilà.



Le 16/02/2020 à 11:56, Cerdic a écrit :

Salut Charles,

dis moi c’est quoi la référence pour le projet d’intégration au core ?
Je ne retrouve pas la branche dans le core, il me semble que tu en 
avais créé une, non ?


Et sur le plugin il y a un certain nombre de petites choses qui me 
semble améliorables :
 - il y a toujours aucune largeur maxi aux contenus, ce qui sur un 
grand écran est totalement contreproductif (je préfère encore la 
largeur étroite de l’interface par défaut que cette interface qui fait 
des kilomètres de large chez moi)
 - je pense pas qu’on font face soit une bonne idée, en tout cas pour 
le core : il faut garder des font natives

 - sur les formulaires il y a des choses qui ne vont pas

Donc je voudrais bien me mettre ce projet d’interface par défaut chez 
moi quand je dev pour pouvoir la tester en conditions réelles et 
l’affiner, mais là je sais pas d’où il faut partir...



___
liste: https://listes.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] r122281 - in _plugins_/prive_fluide/trunk

2020-02-08 Par sujet Charles Razack
Alors je sais pas qui ou quoi l'a ajoutée à quel moment, en tout cas pas
la mienne.
C'est du vaudou tout ça :)

Le 08/02/2020 à 15:13, Pierre KUHN a écrit :
> du répondre à tous dans le mail de commit ;)
> -- 
> Pierre KUHN


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.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] r122281 - in _plugins_/prive_fluide/trunk

2020-02-08 Par sujet Charles Razack
Le 08/02/2020 à 15:14, Eric Lupinacci a écrit :
> Sinon je viens de t'ajouter dans les équipes spip et galaxie sur le git.
> Désolé je t'avais oublié.

Top, merci.

Sinon pour revenir au sujet, n'hésite pas à faire des retours sur le PR.
Pour résumer, il ne s'occupe "que" d'aggrandir la largeur, ça occasionne
peut-être des désagréments ou des déséquilibres par-ci par -là, ça
dépend des points de vue (et des habitudes aussi). Faudrait arriver à se
mettre d'accord sur les angles à arrondir pour arriver à quelque chose
qui convienne à tout le monde.


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.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] r122281 - in _plugins_/prive_fluide/trunk

2020-02-08 Par sujet Charles Razack
Hs mais d'où sort l'adresse charles.raz...@varonne.webelys.net (dans le
cc de ta réponse) ?


Le 08/02/2020 à 15:08, Eric Lupinacci a écrit :
> Ah ok c'est trop cool.
> Donc ça ne sera pas un plugin-dist mais direct dans spip.
> Chouette tout ça.
>
>
> ++
> Eric
>


pEpkey.asc
Description: application/pgp-keys
___
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] [git] observateurs des dépôts de l'orga spip

2020-02-06 Par sujet Charles Razack

Holà,

Bon ça avance sur le git, c'est chouette.
Il commence à y avoir des PRs faits sur le core et les plugins de la 
dist, mais je crois que peu de gens reçoivent des notifications, et donc 
il y a peu de retours.
Par exemple sur le dépôt spip, il n'y a que 7 observateurs actuellement 
: https://git.spip.net/spip/spip/watchers

Et sur les dépôts des plugins de la dist, quasiment personne.

Actuellement il faut se mettre manuellement en observateur de chaque 
dépôt un-par-un, et répéter donc l'opération une trentaine de fois : on 
comprend que ça décourage un peu :) (c'est l'icône « suivre » en haut à 
droite pour celleux qui n'auraient pas vu).


Camille, est-ce qu'il y aurait un moyen de mettre automatiquement tout 
l'équipe du core en observateurs de tous les dépôts de l'orga spip ? 
Comme ça c'est fait une bonne fois pour toute et on n'en parle plus.


___
liste: https://listes.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] r121578 - in _plugins_/contacts_et_organisations/trunk

2020-02-04 Par sujet Charles Razack

Il y a un test en amont

Le 04/02/2020 à 16:54, Cerdic a écrit :
Oui mais si tu fournis pas de squelette ça fait une erreur de 
compilation !


--

___
liste: https://listes.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] r121578 - in _plugins_/contacts_et_organisations/trunk

2020-02-04 Par sujet Charles Razack
Oui, j'ai gardé ça au cas hypothétique où quelqu'un le rajouterait plus 
tard, comme ça pas à se souvenir qu'il faut modifier ce squelette, ça 
sera déjà pris en compte.



Le 04/02/2020 à 16:22, toutati a écrit :

hello,

le fichier contact-enfants demandé dans

[(#SET{enfants,#INCLURE{fond=prive/objets/contenu/contact-enfants,id_contact,env}})]

ne semble pas exister

?

Merci

++

touti


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


Re: [spip-dev] Mails perdus dans les tuyaux

2020-02-04 Par sujet Charles Razack
Ah ok, alors c'est le délai de réception qui m'a mis en erreur (pour un 
message d'hier soir c'était + de 10mn)


Bon désolé pour le bruit et les doublons.

Le 04/02/2020 à 10:36, Bruno Bergot a écrit :

Hop, tes trois messages de ce matin sont bien arrivés, cf :

https://www.mail-archive.com/spip-dev@rezo.net/

Le 04/02/2020 à 09:52, Charles Razack a écrit :


En croisant les doigts pour que celui là arrive :p

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


[spip-dev] Mails perdus dans les tuyaux

2020-02-04 Par sujet Charles Razack

Bonjour la liste,

Hier j'ai eu 4 messages qui ne sont jamais arrivés.
J'ai bien vérifié, ils étaient bien à destination de spip-dev, et je 
n'ai pas reçu de "undelivered return to sender".


Le truc c'est que ça à l'air un eu random, j'en ai au moins 1 qui est 
arrivé (donc juste 1 sur 5 envoyés hier).
Du coup je commence à me demander si d'anciens messages que je pensais 
avoir envoyés ne sont jamais arrivés non plus.


Est-ce que d'autres ont constaté ça ?
Et pour les admins, il y a moyen d'en savoir plus ? (des logs, liste des 
messages bloqués, je sais pas).


En croisant les doigts pour que celui là arrive :p

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


[spip-dev] Mails perdus dans les tuyaux

2020-02-04 Par sujet Charles Razack

Bonjour la liste,

Hier j'ai eu 4 messages qui ne sont jamais arrivés.
J'ai bien vérifié, ils étaient bien à destination de spip-dev, et je 
n'ai pas reçu de "undelivered return to sender".


Le truc c'est que ça à l'air un eu random, j'en ai au moins 1 qui est 
arrivé (donc juste 1 sur 5 envoyés hier).
Du coup je commence à me demander si d'anciens messages que je pensais 
avoir envoyés ne sont jamais arrivés non plus.


Est-ce que d'autres ont constaté ça ?
Et pour les admins, il y a moyen d'en savoir plus ? (des logs, liste des 
messages bloqués, je sais pas).


En croisant les doigts pour que celui là arrive :p

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


[spip-dev] Messages perdus dans les tubes

2020-02-03 Par sujet Charles Razack
Hello la liste,

Je ne sais pas si d'autres ont constaté, mais j'ai eu plusieurs messages
qui ne sont jamais arrivés sur la liste aujourd'hui. C'est un peu random
en plus, des fois ça passe, des fois pas. Je croise les doigts pour
celui-là :p

Précision : aucun retour de messages non parvenus, et ils étaient bien
tous à destination de spip-dev.



pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.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 - Squelettes - Etat de la Migration

2020-02-03 Par sujet Charles Razack
Le problème en gardant un seul dépôt, c'est que les changement portant
sur les squelettes devront constamment être reportés entre le master et
la branche, ça va être bien relou à maintenir.
Et la maintenance denièrement, c'est plutôt bibi qui se la tape, donc un
peu de considération merci :p

Je trouve que c'est pas bien méchant d'avoir à récupérer 3 dépôts au
lieu d'1 quand on veut initialiser un projet basé sur Integraal.

Le 03/02/2020 à 18:58, RastaPopoulos a écrit :

> Le 03/02/2020 à 18:41, Charles Razack a écrit :
>> *Integraal*
>>
>> Logiquement on devrait scinder en 3 dépôts différents :
>>
>>   * integraal_core
>>   * integraal_squelettes
>>   * integraal_theme
> C'est plus compliqué que ça, car core est toujours vide à priori, le principe 
> de Intégraal c'est de pouvoir générer un échafaudage qu'on va modifier 
> directement ensuite (en supprimant ou ajoutant des choses).
>
> Donc ça peut aussi être un seul dépôt avec core, squelettes et theme dedans 
> (ce qui est au départ depuis le début) mais du coup une branche avec 
> l'ancienne version du thème et une branche avec la nouvelle ?
>
> Je sais pas trop encore mais ça demande réflexion :)
>


pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.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 - Squelettes - Etat de la Migration

2020-02-03 Par sujet Charles Razack

Je peux me prononcer sur integraal et tutocommerce :

*Integraal*

Logiquement on devrait scinder en 3 dépôts différents :

 * integraal_core
 * integraal_squelettes
 * integraal_theme

*Tutocommerce*

Pour ma part je trouve pas très grave qu'on perde 7 commits. Donc go !


Le 03/02/2020 à 16:58, Bruno Bergot a écrit :

Hop,

Le 03/02/2020 à 15:55, Eric Lupinacci a écrit :

Hello,

Sur les 180 repos du dossier _squelettes_/ sur la zone, 138 repos ont 
été

migrés correctement (donc avec tout l'historique).
Il reste 42 repos que je n'ai pas encore transférés car il y a des
structures non standard pour lesquelles il faut prendre des décisions.
Certains même devraient ne jamais être migrés de mon point de vue.
Parmi ces squelettes il y en a de très utilisés.



Je ne vais répondre que sur les éléments que je connais ou auxquels 
j'ai participé :



blog_SpipClear non dossiers branches/ et dev/ pas de trunk/ ?


osef, vieillerie historique, ne doit pas passer en git

mediaspip non 4 dossiers avec des trunk/ et branches/ chacun. c'est 
quoi %

galaxie ?


Kent1 nous en dira plus, mais là, c'est typiquement le répertoire 
d'une distribution, à part laisser tel quel dans une orga à part, je 
ne vois pas par quel bout le prendre...



spipclear_z oui moitié des commits apres le trunk


Amha ça n'est pas bien grave si on perd des bouts d'historique pour 
celui là, je ne le maintiens plus depuis perpète.


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

Re: [spip-dev] Doc Git pour SPIP

2020-01-25 Par sujet Charles Razack
Le 25/01/2020 à 10:48, Franck a écrit :
> Pas conseillé mais assez souvent utile :
> Pour comprendre l'usage d'un pipeline ou d'une fonction, rien de tel qu'une 
> recherche globale sur la zone pour étudier le code qui l'utilise.
>
> Et parfois nécessaire :
> des fonctions de nospam ont récemment été préfixées par nospam_ Pas plus tard 
> qu'hier, la recherche sur le source de toute la zone m'a permis de trouver 
> les ocurences de ces fonctions et de corriger le plugin qui restait à 
> corriger.
> Quelle alternative sans tout avoir sur place ?
>
> JL

Oui, il est parfois pratique de pouvoir rechercher des exemples ou des
occurences de codes particuliers sur l'ensemble des plugins de la zone.

Sur ce sujet, gitea a une option non activée par déaut qui permet
d'indexer le code des dépôts et donc de rechercher dedans :
https://docs.gitea.io/en-us/config-cheat-sheet/#indexer-indexer
Cela dit :

- Ça consomme beaucoup plus de ressources
- J'ignore si ça permet de faire une recherche sur l'ensemble des dépôts
- J'ignore aussi si ça permet de faire des recherches avancées, à partir
de motifs



pEpkey.asc
Description: application/pgp-keys
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Inscription ouverte des contributeurices (choses à résoudre)

2020-01-23 Par sujet Charles Razack

Le 23/01/2020 à 09:40, Bruno Bergot a écrit :
Je ne vois pas d'option à ce sujet (à moins que ça soit possible en 
désactivant oauth2 
https://docs.gitea.io/en-us/config-cheat-sheet/#oauth2-oauth2), mais 
au final ne serait-il pas plus simple de désactiver l'inscription 
manuelle sur gitea cf l'option DISABLE_REGISTRATION 
https://docs.gitea.io/en-us/config-cheat-sheet/#service-service


Oui, ne faudrait-il pas garder le fonctionnement actuel du svn ? Que la 
création de compte se fasse uniquement après lecture de la charte, 
inscription aux listes et une demande explicite sur spip-dev. Réserver 
la création de comptes aux admins + interdire la connexion via un compte 
externe.


Il faudrait également un message d'accueil sur gitea ou un lien vers une 
page expliquant ce fonctionnement. J'ai vu que nicod_ a déjà commencé à 
personnaliser les templates, donc ça doit être possible.


Mes 2 centimes d'anciens francs.

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


Re: [spip-dev] Inscription ouverte des contributeurices (choses à résoudre)

2020-01-23 Par sujet Charles Razack
Dans les trucs à résoudre, il faut aussi prendre en compte le fait que 
gitea permet de se connecter avec un compte github, donc même pas besoin 
de créer un compte sur le gitea (et donc lire et accepter la charte et 
s'inscrire à la liste).


Le 22/01/2020 à 12:06, RastaPopoulos a écrit :

Yo, je ne sais plus quand on a décidé ça (azerttyu disait que ça avait été 
évoqué dans un des fils), mais le fait que l'inscription soit désormais ouverte 
dans la forge Git me fait poser quelques questions. Qui peuvent être résolues 
hein mais il faut y penser.

- À court terme déjà, tant qu'il y a encore le SVN, certains projets ne sont 
pas encore en Git. Or les gens peuvent donc s'inscrire tous seuls, sans avoir 
spécialement dialogué avec nous (pas sur la liste, etc), mais ils ne sont pas 
inscrit automatiquement au SVN. Du coup pour cette période là, ça peut être 
confus : je peux m'inscrire tout seul, mais en fait non pour certains, mais 
c'est marqué nulle part (juste il faut y penser et l'expliquer clairement, à un 
endroit où les nouveaux arrivants sont obligés de le voir).

- Les gens ne sont pas inscrits à la liste de discussion de dev (désormais 
uniquement spip-dev), alors que normalement c'est obligatoire quand on est 
contributeurice. Si on décide de les inscrire automatiquement, il faut 
prévenir, c'est même obligatoire avec le RGPD. (Avec le temps, est-ce que ça 
aura encore un sens si on se met à tout discuter dans les tickets ? :) Mais 
bon, pour l'instant oui : liste obligatoire.)

- Quand on s'inscrit, on a juste un compte isolé, on peut juste forker et faire des PR. Ensuite il 
y a actuellement un cron qui ajoute *après coup* (possiblement 1h) les droits pour modifier 
directement tout ce qui est "contrib". Soit il faudrait que ce soit immédiat, soit il 
faudrait l'expliquer clairement au moment de s'inscrire (même si c'est immédiat il faudrait 
sûrement l'expliquer d'ailleurs, "Vous allez être ajouté⋅e automatiquement aux organisations 
de contribution…").

- Mais le plus important : normalement pour être contributeurice, on doit absolument 
avoir lu et accepté la charte de la communauté (désormais valant pour 100%, pas juste la 
zone : https://www.spip.net/fr_article6431.html). Le fait que la demande de compte était 
fait 1) en étant obligé de s'inscrire à la liste de discussion et 2) en demandant à des 
humains, faisait qu'on pouvait valider ça. Là avec une inscription ouverte, ce n'est plus 
le cas du tout. Donc comment faire ? Ajouter un lien vers la charte avec une case à 
cocher "J'ai lu et accepté la charte" ?


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

Re: [spip-dev] [spip-team] Migration svn-git - problème du passage en trunk

2020-01-21 Par sujet Charles Razack

Hop les voilà :

 * verifier
 * prix

Le 21/01/2020 à 17:38, Eric Lupinacci a écrit :


Du coup il faudra ajouter une poignée de plugins que j'avais mis
en trunk pour la synchro git aussi, faut que je retrouve la liste.

Oui si on rattrape le coup mieux vaut inclure ce que tu as fait.

++
Eric

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

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

2020-01-20 Par sujet Charles Razack

clap clap clap pour le boulot :)

3 petites questions (qui ont peut-être déjà eu des réponses, mais je ne 
retrouve plus où) :


 * Qu'est-ce que ça va signifier pour le fichier archivelist.txt une
   fois que le basculement à git sera définitif ?
 * Est-ce qu'il est prévu qu'à terme certains plugins puissent avoir
   des droits restreints ? Quand une équipe de développeurs veut garder
   la main et n'accepter des contributions que par PR ? Je pense aux
   plugins comme bank et cie.
 * D'ici la bascule complète à Git, est-ce qu'il est déconseillé de
   créer des dépôts directement à partir de gitea ?


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

Hello,

C'est un jour important pour le développement de SPIP car la migration 
de la forge SPIP de SVN (autrement dit la Zone) vers Git (forge Gitea 
ou notre nouvelle Zone) a clairement débutée.
Une première étape est finalisée (où se termine au moment où j'écris 
ce mail, le script n'étant pas totalement fini), je vais expliquer en 
quoi elle consiste.


_Etape 1 : organisations et plugins 3.2_
Cette première étape nous a donné l'occasion d'échanges multiples 
quant aux nombres et aux noms des organisations que nous espérons 
compréhensibles . Il a été décidé que la nouvelle forge rappellerait 
l'organisation de la Zone SVN pour faciliter l'apprentissage.
De fait nous avons choisi de créer les organisations dont la liste est 
consultable à l'adresse https://git.spip.net/explore/organizations, à 
savoir :

- spip
- spip-contrib-extensions
- spip-contrib-squelettes
- spip-contrib-themes
- spip-contrib-outils
- galaxie

L'organisation "spip" contient le noyau de spip et l'ensemble des 
plugins-dist. Elle est publique (donc accessible en lecture pour tout 
le monde) mais accessible en écriture uniquement par une *équipe 
nommée "SPIP"* qui correspond exactement à l'équipe noyau actuelle.
Il sera possible pour des développeurs externes à la team SPIP de 
proposer des modifications en utilisant le processus de Push Request 
(PR) qui remplace avantageusement le patch de SVN.


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.


Enfin, les organisations spip-contrib- contiennent les 
contributions accessibles en écriture à tous les inscrits sur la forge 
qui ont été regroupés dans une *équipe nommée "contrib"* (a priori la 
même liste que sur la Zone aux erreurs près). On distingue donc :
- spip-contrib-extensions : qui contient l'ensemble des contributions 
fonctionnelles (sou forme de plugin ou autre) et qui proviennent des 
répertoires _plugins_ (principalement) et _grenier_ (à voir).
- spip-contrib-squelettes : qui contient l'ensemble des contributions 
de squelettes (sou forme de plugin ou autre) qui proviennent de 
_squelettes_
- spip-contrib-themes : qui contient l'ensemble des contributions de 
thèmes au sens de SPIP qui proviennent de _themes_
- spip-contrib-outils : qui contient les outils connexes à SPIP qui 
proviennent de _outils_ et _dev_
Pour l'instant toute la zone n'a pas encore été transférée, le choix 
s'est portée en premier lieu sur les plugins compatibles SPIP 3.2. 
Certains (liste à disposition) n'ont pas été importés car leur 
organisation sur le Zone nécessite quelques adaptations ou 
discussions. Par exemples, il reste à discuter comment on aplatit la 
structure actuelle de _themes_ (nomenclature à décider).
spip-contrib-extensions et spip-contrib-squelettes sont quand à elles 
bien peuplées.


Pour le moment, la Zone continue d'être accessible en écriture 
(commit) de la même façon que la forge Git.

Un outil de synchronisation assure la cohérence bidirectionnelle.
Cette synchronisation va être assurée encore jusqu'à fin mars pour les 
organisations spip-contrib-.
A partir d'avril seule la forge Git permettra de contribuer aux 
organisations spip-contrib-, il faudra donc d'ici là switcher les 
environnements de développement sous Git.
Pour cela, une documentation sera proposée pour expliquer à tous 
comment effectuer la migration des environnements de développement.


_Etape 2 : consolidation des organisations_
L'étape qui débute maintenant va permettre à tout membre de la forge de :
- vérifier qu'il a bien accès aux organisation spip-contrib- en 
écriture. Si ce n'est pas le cas, remonter le problème aux admins sur 
la liste spip-dev
- continuer à peupler les organisations *avec les plugins qui posaient 
un problème dans la liste des SPIP 3.2 (voir PS)*, puis les plugins 
3.1... et aussi les outils, la galaxie et les thèmes. Si vous avez 
besoin d'un plugin particulier ne pas hésiter à remonter aussi cela 
sur la liste spip-dev.

- rédiger les articles d'explication et commencer l'apprentissage
- mettre au point les organisations spip et galaxie
- définir le fonctionnement avec les 

Re: [spip-dev] [spip-team] Maintenance de git.spip.net 2019-01-07

2020-01-07 Par sujet Charles Razack

Top, ça à l'air en effet plus rapide.
Merci km !

Le 07/01/2020 à 18:00, cam.la...@azerttyu.net a écrit :

Bonjour

Le service a été migré sur un nouveau serveur il devrait (en thèorie)
être bien plus réactif.

Une autre opération va être effecutée sous peu, concernant la mise à
jour de gitea. J'ai pris un peu de retard sur ce point.

Km
___
spip-t...@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-team

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


Re: [spip-dev] formidable participation sur gitea

2019-12-20 Par sujet Charles Razack

fait, et par la même occasion tous les formidable_xxx qui ont un trunk

Le 20/12/2019 à 14:51, Maïeul a écrit :

Holla,

serait-il possible aussi d'avoir formidable_participation sur 
git.spip.net ?


Merci

___
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

___
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] Import ics sur gitea

2019-12-19 Par sujet Charles Razack

done

Le 19/12/2019 à 16:22, Maïeul a écrit :

Coucou,

ce serait possible de mettre _plugins_/import_ics sur git.spip.net ?

Merci d'avance

Maïeul

___
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

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

Le 17/12/2019 à 17:30, Matthieu Marcillaud a écrit :
>
> 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.

Mes deux centimes d'anciens francs : c'est bien que ce soit la même
chose partout, et dans l'API du noyau c'est de la forme "objet_machiner".
Donc la prop de rasta me semble raccord.




pEpkey.asc
Description: application/pgp-keys
___
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-12-13 Par sujet Charles Razack

Le 13/12/2019 à 11:06, Eric Lupinacci a écrit :

Hello,

Juste pour compléter mon propos vu qu'on est peu nombreux à s'exprimer.
Si tout le monde est d'accord avec la proposition de Rasta allons-y.
Le pire est l'immobilisme actuel.

++
Eric


+1

Cette proposition me semble claire et logique.

Ça n'évacue pas la question d'améliorer la présentation et la navigation 
quand il y a beaucoup de dépôts sur une même orga, mais ça peut se faire 
dans un second temps.
Le principal étant de définir une bonne fois pour toutes les orgas 
principales amha.


Il y a plusieurs tickets qui évoquent des solutions pour ce problème 
dans le tracker de gitea, par le biais de sous-groupes ou de "labels" 
(mais rien d'implémenté pour l'instant il semblerait) :


 * https://github.com/go-gitea/gitea/issues/1872
 * https://github.com/go-gitea/gitea/issues/363
 * https://github.com/go-gitea/gitea/issues/219

___
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] spam git.spip.net

2019-12-11 Par sujet Charles Razack
Ouais ce point là, je vois pas trop dans quelle mesure c'est 
améliorable. Les forges git affichent tous les dépôts, qu'il s'agisse de 
fork ou pas. Mais peut-être que c'est possible, hein.


Les retours de bugs/améliorations sont dispersées dans plusieurs fils de 
discussion, il serait peut-être temps d'ouvrir un projet sur redmine 
pour les regrouper ?


Pour revenir au sujet initial, je n'ai pas les droits nécessaires pour 
supprimer des utilisateurs/dépôts.


Le 11/12/2019 à 14:35, Eric Lupinacci a écrit :
Le mer. 11 déc. 2019 à 14:30, RastaPopoulos > a écrit :


Le 11/12/2019 à 14:23, Eric Lupinacci a écrit :
> Alors je ne sais pas si c'est voulu ou pas mais ça donne pas une
impression de "maitrise" comme sur la zone.

Dans une forge git ça c'est normal : chaque participant doit
pouvoir faire son fork de ce qu'il veut (du noyau, de tel ou tel
plugin) pour pousser ses modifications temporaires puis générer
des requests.


Soit mais il faudrait que ce soit quelque part et pas accessible au 
milieu du reste "officiel" de la nouvelle zone.
Sinon je pense que ça va être encore une raison de dire que c'est plus 
compliqué moins lisible...


++
Eric

___
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] spam git.spip.net

2019-12-10 Par sujet Charles Razack
Quelqu'un a décidé de mener son combat contre cloudfare sur git.spip.net
: https://git.spip.net/crimeflare/cloudflare-tor

Je supprime ?



pEpkey.asc
Description: application/pgp-keys
___
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] SPIP 3.3-beta

2019-12-09 Par sujet Charles Razack

Hello,

Si je comprends bien, l'intérêt de cette fonction c'est que c'est plus 
optimisé que de faire plusieurs sql_fetsel, j'ai bon ?


Juste une remarque sur la signature de la fonction : ça me semble un peu 
pénible d'avoir à récupérer le nom du champ qui sert d'identifiant 
*avant* d'appeler cette fonction. N'est-il pas possible de rendre le 
paramètre $champ_id optionnel, et le mettre en dernier ?
Il me semble que dans la majorité des cas, il s'agira du champ qui porte 
la clé primaire, qui peut être déduit automatiquement non ?


Ainsi l'utilisation "de base" serait plus simple et identique à 
objet_modifier et objet_inserer.


C'est à dire faire ça :

objet_lire('patate', 10, array('titre', 'texte'));

Au lieu de faire ça :

objet_lire('patate', 'id_patate', 10, array('titre', 'texte'));


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

Hello,

Oui, j'avais déjà pris en compte ta remarque et enlevé le pipeline.
Ce que j'avais par contre c'est un appel à une fonction spécifique 
pour lire les champs de l'objet si elle existe et qui se substitue au 
traitement standard si besoin (comme par exemple pour les plugins qui 
nécessite une jointure sur la table des dépots).

Si ça convient pas on peut le supprimer aussi.
Rasta avait fait aussi la remarque sur l'intérêt de l'argument forçant 
le recalcul en base : effectivement ça sert peut être à rien et on 
pourrait l'enlever.


Le code actuel est donc le suivant, dites moi si on fait des 
modifications et je le commite :


/** * Lit un objet donné connu par son id ou par un identifiant 
textuel unique et renvoie tout ou partie de sa * description. * Il est 
possible pour un objet donné de fournir la fonction 
_lire_champs qui renvoie simplement tous les * champs de 
l'objet concerné sans aucun autre traitement. Sinon, l'appel SQL est 
réalisé par l'API. * * @param string $objet Type d'objet comme article 
* @param string $champ_id Nom du champ utilisé comme identifiant de 
l'objet * @param int|string $valeur_id Valeur du champ identifiant * 
@param array|string $informations Liste des champs à renvoyer. Si vide 
la fonction renvoie tous les champs. * @param bool $forcer_lecture 
Permet de forcer la lecture en base de données même si l'objet a déjà 
été lu * sur le même hit. * * @return array|mixed */ function objet_lire($objet,$champ_id,$valeur_id,$informations =array(),$forcer_lecture =false) {


// Initialisation du tableau des descriptions et des id d'objet (au 
sens id_xxx). // Les tableaux sont toujours indexés par l'objet et 
l'id objet. static $descriptions =array();

static $ids =array();

// On détermine le nom du champ id de la table. include_spip('base/objets');
$table_id =id_table_objet($objet);

// On détermine si on a passé l'id objet ou un autre identifiant 
unique de la table : if ($champ_id != $table_id) {
   // on a passé un identifiant différent que l'id de l'objet, on cherche 
si cet objet a déjà été rencontré // car dans ce cas on a déjà stocké 
son id objet. $index =isset($ids[$objet][$valeur_id]) ? $ids[$objet][$valeur_id] :0;

}else {
   $index =$valeur_id;
}

// On vérifie si l'objet demandé n'est pas déjà stocké : si oui, la 
description sera utilisée sauf si on a forcé // la lecture en base. if (isset($descriptions[$objet][$index])) {

   $description = $descriptions[$objet][$index];
}else {
   $description =array();
}

// Si l'objet n'a pas encore été stocké, il faut récupérer sa 
description complète. if ($forcer_lecture or !$description) {
   // Il est possible pour un type d'objet de fournir une fonction de 
lecture de tous les champs d'un objet. if (include_spip('action/editer_' .$objet)

   and function_exists($lire ="${objet}_lire_champs")) {
  $description = $lire($objet,$champ_id,$valeur_id);
   }else {
  // On récupère la table SQL à partir du type d'objet. $table 
=table_objet_sql($objet);

  // La condition est appliquée sur le champ désigné par l'utilisateur. 
Si ce champ n'est pas l'id objet // on considère qu'il est de type 
chaine. $where = ($champ_id != $table_id)

 ?array("${champ_id}=" .sql_quote($valeur_id))
 :array("${champ_id}=" .intval($valeur_id));

  // Acquisition de tous les champs de l'objet : si l'accès SQL retourne 
une erreur on renvoie un tableau vide. if (!$description =sql_fetsel('*', $table, $where)) {

 $description =array();
  }
   }

   // On stocke systématiquement la description à l'index correspondant à 
l'objet et l'id objet. if (!$index) {
  // Première sauvegarde de l'objet qui est forcément lu via un champ 
qui n'est pas l'id objet. // Il faut donc stocker l'index pour un 
futur appel si la description est non vide. if ($description) {

 $index = $description[$table_id];
 $ids[$objet][$valeur_id] = $index;
  }
   }

   // Si l'index a bien été déterminé, on stocke la description à 

Re: [spip-dev] Interface Rôles cassé (depuis le début), inutilisable la moitié du temps

2019-12-03 Par sujet Charles Razack
Avec la façon dont c'est conçu dans le dropdown de bootstrap, ça m'a 
l'air mission impossible aussi.
Et aucune réponse convaincante les quelques fois où le problème a été 
évoqué dans leurs tickets.


À mon avis, autant basculer vers une autre lib qui gère ce problème 
correctement, exactement comme tu disais : en copiant le dropdown à la 
fin du body pour être sûr qu'il soit au-dessus de tout le reste.

C'est la méthode employée par Select2, par exemple.


Le 29/11/2019 à 20:03, RastaPopoulos a écrit :

Help, si vous avez des idées qui vous viennent, de choses à tester…

Je mets ça là car ça concerne un plugin mais qui à terme devrait être dans le 
noyau (puisque l'API y est déjà).

La partie interface de l'API Rôles est donc pour l'instant à part en plugin. Ça utilise 
la lib dropdown de Bootstrap et depuis le début il y a un problème. Le menu est 
positionné en absolu, mais son "contexte" de calque est celui de la boite de 
liens. Et du coup le menu passe en fait SOUS toutes les autres boites qui seraient en 
dessous. Donc concrètement si on a une boite de liens avec rôles et dessous aucun contenu 
qui fasse de la place mais directement une autre boite (GIS par ex ou autre), et bien 
quand on ouvre le menu déroulant, il passe dessous.

Les rôles sont donc littéralement inutilisable (impossible d'accéder aux 
boutons d'ajouter/retrait) dans un très grand nombre de cas.

Au niveau technique, le problème est
- un mélange de styles du privé bourrés de position:relative à tous les niveaux
- et (de mon point de vue) de la librairie de Bootstrap qui est de la merde :) 
et qui se base que sur CSS.

Alors que comme c'est en JS de toute façon, d'après moi, une lib "dropdown" qui fait bien 
les choses, devraient toujours s'arranger d'elle-même pour qu'un menu qu'on demande explicitement à 
ouvrir soit TOUJOURS au-dessus de tout. En effet, dans un contexte modulaire, quand tu ajoutes un 
dropdown dans une appli, tu n'es pas du tout en mesure forcément de changer l'ensemble des CSS qui 
te gênent pour bien que le calque soit au-dessus, donc on peut pas de mander aux devs utilisateurs 
de dropdown "ah oui mais en fait il faut que tous les parents soient comme ci comme ça pour 
que ça marche" : si c'est ça : c'est de la merde !

J'ai tenté de mettre à jour avec le JS de Bootstrap 4.4 tout dernier et… ça ne 
marche toujours pas, la lib fonctionne pareil qu'avant, que en CSS pour 
positionner.

Donc
- si vous avez un truc magique en CSS qui permettrait de repasser au-dessus 
(protip : à priori c'est rigoureusement impossible)
- ou bien il faut changer de lib JS complètement et en trouver une mieux faite ?


___
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] Les SVG sont des images comme les autres

2019-10-16 Par sujet Charles Razack
Complément d'enquête : des fois on ne sait pas à l'avance à quel type 
d'image on a affaire.
Si c'est un svg, on aimerait qu'il soit embeddé (donc |balise_svg), 
sinon on veut le tag  normal (donc |balise_img).


Ça amène à faire des tests dans les squelettes de la sorte :
[(#EXTENSION}|=={svg}|oui) [(#FICHIER|balise_svg)] ]
[(#EXTENSION}|=={svg}|non) [(#FICHIER|balise_img)] ]

Dans ces cas là il serait pratique d'avoir un filtre qui fasse ça 
automatiquement.
Sémantiquement, je ne sais pas quel serait le nom le plus approprié, 
peut-être « balise_image » tout simplement : ça ne présuppose pas du tag 
qui va être produit ( ou ), ça dépend de l'image.


Un exemple de fonction que j'utilise de mon côté : 
http://spip.pastebin.fr/58813


if (!function_exists('filtre_balise_img_svg')) {
functionfiltre_balise_img_svg($src, $alt='', $class='') {
include_spip('inc/filtres');
  $balise ='';
// Récupérer le chemin si c'est déjà un tag 
if (substr(trim($src), 0, 4) ==='Un autre truc que je remarque à l'usage : sur un svg qui n'a pas 
d'attribut width dans le , image_reduire n'applique rien du tout.


Alors oui, on peut styler les svg en css, mais c'est moins propre : 
quand tu affiches la page sans css par exemple, le svg perd sa dimension.


Je m'attendrais à ce que image_reduire ajoute un attribut width, qu'en 
pensez vous ?


Autre truc : on peut enchainer balise_img et image_reduire, mais pas 
avec balise_svg

#CHEMIN{images/machin.png}|balise_img|image_reduire{5}  OK
#CHEMIN{images/machin.svg}|balise_svg|image_reduire{5}  Pas de réduction

Là aussi, je m'attendrais à ce que le fonctionnement soit similaire non ?

___
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] Les SVG sont des images comme les autres

2019-10-15 Par sujet Charles Razack



Le 15/10/2019 à 21:19, nicod_ a écrit :
Un autre truc que je remarque à l'usage : sur un svg qui n'a pas 
d'attribut width dans le , image_reduire n'applique rien du tout.
Alors oui, on peut styler les svg en css, mais c'est moins propre : 
quand tu affiches la page sans css par exemple, le svg perd sa dimension.
Je m'attendrais à ce que image_reduire ajoute un attribut width, qu'en 
pensez vous ?


+1

(pour être sûr : tu parles bien de ce cas là : 
#CHEMIN{images/machin.svg}|image_reduire{5} ? )


Autre truc : on peut enchainer balise_img et image_reduire, mais pas 
avec balise_svg

#CHEMIN{images/machin.png}|balise_img|image_reduire{5}  OK
#CHEMIN{images/machin.svg}|balise_svg|image_reduire{5}  Pas de réduction


+1 aussi

J'ai un doute : on a le droit de ne mettre qu'une seule dimension avec 
les svg ? Dans ce cas, le navigateur garde la proportion en fonction du 
viewbox ?

Ou c'est forcément width + height à la fois ?

___
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-26 Par sujet Charles Razack
Hello,

Pour le logo du site, en utilisant 'site' comme nom d'objet, est-ce
qu'il n'y a pas une confusion possible avec l'objet site syndiqué ?
'site' étant un surnom de la table spip_syndic :
https://git.spip.net/dist/sites/src/branch/master/base/sites.php#L61

Dans rôles de documents pour lever toute ambiguité je m'étais rabattu
sur 'site_spip'.

Le 26/07/2019 à 10:56, Cerdic a écrit :
> OK, en effet, le cas particulier du site 0 était bloqué par un certain
> nombre de tests sur intval($id_objet)
> J’ai ajouté une condition pour l’autoriser sur l’objet site, mais
> peut-être il faudrait modifier la condition : si le id_objet passé est
> vraiment un 0 l’accepter quel que soit l’objet
>
> Un up du core et du plugin medias devrait donc résoudre ça
> (le logo était normalement bien migré dans le dossier logo/ et dans la
> base, il manquait juste le lien)
>
> -- 
> Cédric


pEpkey.asc
Description: application/pgp-keys
___
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] Nouveau logo de SPIP pour la 3.1 comme prévu ?

2014-11-06 Par sujet Charles Razack
> j’adore le chat volant numéro 2, surtout sur fond blanc, il me fait 
bien rire. il mort pas j’espère :)


Ah, si ça ressemble à un chat, c'est mal parti :p

La bataille est un peu finie me dit-on dans l'oreillette, mais voilà une 
dernière proposition pour le plaisir : 
http://pix.toile-libre.org/?img=1415298080.png
C'est vaguement inspiré de la forme des poupées russes. Polatouchement 
parlant, il n'est pas en plein vol. Il faut imaginer qu'une fois les 
bras dépliés, il plane comme tout polatouche qui se respecte.
La police sans est du "Voltaire", la serif du "Jacques Francois", toutes 
deux trouvables sur font squirrel.


C.R

Le 04/11/2014 19:43, dlatr a écrit :


j’adore le chat volant numéro 2, surtout sur fond blanc, il me fait bien rire

il mort pas j’espère :)



Le 4 nov. 2014 à 18:31, Charles Razack <tchar...@hotmail.fr> a écrit :


Hop, quelques variations de mon côté d'après le logo de Sébastien :
http://pix.toile-libre.org/upload/original/1415120809.png

J'aime les intentions du logo original : l'idée du polatouche volant, la 
composition, les proportions... En revanche, il y a quelque chose qui me gêne 
dans l’exécution, ça ne tient sans doute à pas grand chose, mais quand ça 
gratte... Il faut gratter.

Bref, j'ai essayé 2 directions différentes : rajouter quelques détails, ou 
rendre un peu plus abstrait.
Pour la couleur, j'identifie beaucoup SPIP au violet utilisé sur le site 
officiel, je préfère rester dessus donc.

En ce qui concerne la typo, ce serait l'occasion d'utiliser une police libre, 
ce qui n'est pas le cas actuellement (c'est du adobe trajan pro je crois). J'ai 
pas vérifié pour les 2 polices utilisées sur ces propositions, mais ce sont 
juste des esquisses.

Bon, on est quand même un peu à mi chemin entre l'illustration/le logo. Dans 
les petites tailles (en dessous de 48px) c'est chaud.
Si j'ai le temps, je ferais bien des essais dans une direction complètement 
différente.



Le 03/11/2014 14:17, nicod_ a écrit :

Le 31/10/2014 19:43, JLuc a écrit :

Je regrette que l'écureuil y ait une forme de requin gueule grand'ouverte
mais j'apprécie les lignes claires et nettes.


C'est un peu là dessus que je bloque le plus depuis le début, ce "nez"
et ce gros oeil morne. Surtout en mode à-plat de couleur.

J'ai fait un petit essai en supprimant le nez et en lui ouvrant un peu
l'oeil :
https://lut.im/4mijwaIa/HLCwPflC
(j'ai mis les deux en diagonale pour mieux les comparer)

C'est fait rapidement dans Photoshop sur le png d'origine, je n'ai pas
la source vectorielle.






Re: [spip-dev] Nouveau logo de SPIP pour la 3.1 comme prévu ?

2014-11-04 Par sujet Charles Razack

Hop, quelques variations de mon côté d'après le logo de Sébastien :
http://pix.toile-libre.org/upload/original/1415120809.png

J'aime les intentions du logo original : l'idée du polatouche volant, la 
composition, les proportions... En revanche, il y a quelque chose qui me 
gêne dans l’exécution, ça ne tient sans doute à pas grand chose, mais 
quand ça gratte... Il faut gratter.


Bref, j'ai essayé 2 directions différentes : rajouter quelques détails, 
ou rendre un peu plus abstrait.
Pour la couleur, j'identifie beaucoup SPIP au violet utilisé sur le site 
officiel, je préfère rester dessus donc.


En ce qui concerne la typo, ce serait l'occasion d'utiliser une police 
libre, ce qui n'est pas le cas actuellement (c'est du adobe trajan pro 
je crois). J'ai pas vérifié pour les 2 polices utilisées sur ces 
propositions, mais ce sont juste des esquisses.


Bon, on est quand même un peu à mi chemin entre l'illustration/le logo. 
Dans les petites tailles (en dessous de 48px) c'est chaud.
Si j'ai le temps, je ferais bien des essais dans une direction 
complètement différente.




Le 03/11/2014 14:17, nicod_ a écrit :

Le 31/10/2014 19:43, JLuc a écrit :

Je regrette que l'écureuil y ait une forme de requin gueule grand'ouverte
mais j'apprécie les lignes claires et nettes.


C'est un peu là dessus que je bloque le plus depuis le début, ce "nez"
et ce gros oeil morne. Surtout en mode à-plat de couleur.

J'ai fait un petit essai en supprimant le nez et en lui ouvrant un peu
l'oeil :
https://lut.im/4mijwaIa/HLCwPflC
(j'ai mis les deux en diagonale pour mieux les comparer)

C'est fait rapidement dans Photoshop sur le png d'origine, je n'ai pas
la source vectorielle.





Re: [spip-dev] Nouveau logo de SPIP pour la 3.1 comme prévu ?

2014-10-31 Par sujet Charles Razack

Hop,

je vais faire tâche au milieu de toute cette belle unanimité, mais je me 
dois de ronchonner : il ne s'est certes pas dégagé de consensus sur les 
autres propositions de logo, toujours est-il que les réserves émises sur 
le nouveau logo demeurent.

Moi je trouve ça dommage de choisir ce logo "faute de mieux".
Y a-t-il besoin d'avoir à tout prix un nouveau logo  pour cette release, 
celui-ci n'ayant pas provoqué d'engouement unanime ? Est-ce pour ne pas 
faire de la peine à son créateur ?





Le 31/10/2014 14:45, Matthieu Marcillaud a écrit :

Salutations,

En mars 2013 après un nombre non négligeable de discussions autour d'un
logo, était proposé la chose suivante : si personne ne propose d'autre
logo intéressant d'ici la 3.1, ce serait celui proposé à l'époque qui
serait installé.

Que pensez-vous à l'heure d'aujourd'hui de tout cela ?

Les gens qui souhaitaient un logo acceptable ont eu le temps de le créer
et de le proposer non ? En l'absence, donc je suppose que l'on doit donc
mettre celui proposé par Sébastien
(http://notes.desbenoit.net/SPIP-THE-END)

MM.

Ci-dessous le message original :


 > De: Matthieu Marcillaud 
 > Objet: Rép : [spip-dev] logo de spip.net
 > Date: 12 mars 2013 17:17:19 UTC+1

 > Mes pensées et propositions du jour :
 > - remettre sur spip.net l'image d'avant
 > - dire que la 3.1 aura un nouveau (et vrai) logo (soit celui de seb,
soit un autre)
 > - sortir la 3.0.6
 > - se préparer pour la 3.1 qui sortira quand elle sera prête
 > - au moment de sa sortie, prendre le logo le plus accepté et décliné
; le placer sur les sites de la galaxie (dans la mesure du possible).
 >
 > Ainsi, on aurait à la fois de quoi causer pour la 3.1, une date
(fonction de la 3.1), un nouveau logo… Ça serait pas beau ça ?
 >
 > Évidemment, ça sous-entend que ceux/celles qui veulent un logo
différent de ce qui est actuellement proposé se débrouillent pour
proposer quelque chose de mieux (et décliné, et leurs sources), et ce
avant que la 3.1 ne sorte. Ça incite à ce que ces personnes
s'auto-organisent et amènent quelque chose d'utilisable au bout du
compte. Rien n'empêche aussi d'utiliser le logo de la zone ou je ne sais
quel logo déjà existant si c'est ce qui est voulu finalement.
 >
 > Est-ce, serait-ce un bon compromis que de dire attendons la prochaine
version (ça laisse un peu de temps, mais pas tante que ça j'espère) et
intégrons dans la version en question le travail sur le logo ?
 >
 > Notez que dans mon idée, la 3.1 n'attend pas d'avoir un logo
hypothétique pour sortir (des oui on va faire ça, mais qui n'est pas
encore prêt) : dans ma petite tête c'est de dire au moment où la 3.1 est
prête, soit les objecteurs (j'en fais un peu parti) ont validé (et
finalisé) un meilleur logo à leurs yeux, soit pas.
 >
 >
 > Ceci n'est qu'une proposition.
 >
 >
 > 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 3.1 : thèmes pour la dist

2014-10-23 Par sujet Charles Razack

(désolé si c'est un doublon, problème avec thunderbird)

Bonjour,

C'est chouette de voir toute cette émulation autour de la nouvelle dist.
Pourrait-on résumer rapidement et concrètement comment faire des 
propositions de thèmes pour la dist, pour les gens intéressés ? Pour 
l'instant, c'est encore un peu flou, à moins de recouper les éléments de 
réponse éparpillés dans plusieurs fils de discussion.


S'agit-il d'une unique feuille CSS, ou peut-on inclure d'autres fichiers 
: polices de caractère, images ?
Si on peut avoir plusieurs fichiers, quelle est la nomenclature, 
s'agit-il d'un plugin, ou d'un simple zip ?


Il y a bien l'exemple du thème «tonton» ici : 
http://zone.spip.org/trac/spip-zone/browser/_themes_/dist/v1/tonton/

Mais ça ne répond pas à toutes les questions.

Le 23/10/2014 15:33, Joseph a écrit :


Le 23 octobre 2014 14:46, RastaPopoulos > a écrit :

Installer un thème facilement, il suffit qu'il soit empaqueté sous
forme de plugin (un dossier, un paquet.xml). Et il peut alors
s'installer en UN CLIC, sans FTP, donc pas de mauvaise foi sur ce
sujet s'il vous plaît.


​Il y aurait peut être un intérêt à faire évoluer la présentation de
http://plugins.spip.net/spip.php?page=plugins=theme afin de
pouvoir clairement identifier les thèmes pour la dist, ceux de Zpip,
ceux de sarka etc.

Certes, c'est visible dans le champs "Compatible" dans la description
mais pas des plus ergonomiques.



Joseph






Re: [spip-dev] Comportement des mises à jour des plugins : interrogations

2014-07-24 Par sujet Charles Razack
[grmmlbml. Je renvoie ma réponse d'hier qui s'est égarée dans les 
méandres d'internet]


Ok, donc c'est moi qui n'avait pas saisi la portée de create, je pensais 
qu'elle ne devait justement pas évoluer.

Désolé pour le bruit !

Si j'ai bien compris, pour résumer, il faut y répercuter au fur et à 
mesure toutes les actions qui n'ont pas trait aux tables du plugin, 
c'est bien ça ?


Est-ce que c'est documenté quelque part, ou c'est un secret transmis de 
spipeur à spipeur ?


C.R

Le 23/07/2014 09:05, Eric a écrit :

Hello,

Ben non c'est correct pour moi.
La fonction de create permet de passer de rien à la mise en place de la
version max du schéma de la base / configuration (celui qui est dans le
xml).
Cette fonction évolue donc toujours en même temps que le schéma évolue.

Les autres fonctions ne font que les mises à jour incrémentales ni plus
ni moins.


++
Eric



Le 23 juillet 2014 08:55, Charles Razack <tchar...@hotmail.fr
<mailto:tchar...@hotmail.fr>> a écrit :


Bonjour la liste,

J'ai constaté un comportement qui m'a surpris en ce qui concerne les
mises à jour des plugins. Soit c'est le comportement voulu, soit
c'est moi qui m'y prends mal, soit c'est un bug.
Comme je ne suis pas sûr, avant d'ouvrir un rapport de bug, je
voulais voir avec la liste.

Pour résumer, lors d'une mise à jour d'un plugin, la fonction de
mise à jour correspondant au numéro de schéma courant est appelée :
ça me semble logique.
En revanche, lors d'une nouvelle installation, ce n'est pas le cas :
seule la fonction d'installation est appelée.
Moi ça me semblait pourtant logique d'appeler aussi la mise à jour
correspondant au numéro de schéma en cours.

Du coup, il y peu y avoir inconsistance entre les plugins mis à jour
par incréments, et les plugins nouvellement installés non ?
En général, les fonctions de mise à jour font des actions relatives
aux tables du plugin, donc ça n'occasionne pas de différence entre
les 2 cas.
Par contre, si on veut y faire d'autres actions (supprimer des
options de config obsolètes par exemples), ben les plugins mise à
jour en bénéficieront, mais pas ceux nouvellement installés.

J'espère être clair.
Concrètement, pour être sûr j'ai procédé de la sorte : plugin de
test avec les fonction d'upgrade suivante :

```
$maj['create'] = array(array('spip_log', 'installation',  'test'));
$maj['2.0.0'] = array(array('spip_log',  'mise à jour 2', 'test'));
$maj['3.0.0'] = array(array('spip_log',  'mise à jour 3', 'test'));
```

- Au départ, le plugin a un schéma 1.0.0.
En activant le plugin, la fonction d'installation est bien appelée.
- Incrémentation du schéma à 2.0.0, rechargement de la page d'admin
des plugins : la fonction de mise à jour n°2 est bien appelée.
- Incrémentation du schéma à 3.0.0, rechargement de la page d'admin
des plugins : la fonction de mise à jour n°2 est bien appelée.
- Désinstallation, puis réinstallation : seule la fonction
d'installation est appelée, alors que je m'attendais à ce que la
fonction de mise à jour 3.0.0 soit également appelée.

Voilà,
à vous lire

C.R



_
liste: http://listes.rezo.net/__mailman/listinfo/spip-dev
<http://listes.rezo.net/mailman/listinfo/spip-dev>
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/__spip/ <http://trac.rezo.net/trac/spip/>
irc://irc.freenode.net/spip <http://irc.freenode.net/spip>








[spip-dev] Comportement des mises à jour des plugins : interrogations

2014-07-23 Par sujet Charles Razack

Bonjour la liste,

J'ai constaté un comportement qui m'a surpris en ce qui concerne les 
mises à jour des plugins. Soit c'est le comportement voulu, soit c'est 
moi qui m'y prends mal, soit c'est un bug.
Comme je ne suis pas sûr, avant d'ouvrir un rapport de bug, je voulais 
voir avec la liste.


Pour résumer, lors d'une mise à jour d'un plugin, la fonction de mise à 
jour correspondant au numéro de schéma courant est appelée : ça me 
semble logique.
En revanche, lors d'une nouvelle installation, ce n'est pas le cas : 
seule la fonction d'installation est appelée.
Moi ça me semblait pourtant logique d'appeler aussi la mise à jour 
correspondant au numéro de schéma en cours.


Du coup, il y peu y avoir inconsistance entre les plugins mis à jour par 
incréments, et les plugins nouvellement installés non ?
En général, les fonctions de mise à jour font des actions relatives aux 
tables du plugin, donc ça n'occasionne pas de différence entre les 2 cas.
Par contre, si on veut y faire d'autres actions (supprimer des options 
de config obsolètes par exemples), ben les plugins mise à jour en 
bénéficieront, mais pas ceux nouvellement installés.


J'espère être clair.
Concrètement, pour être sûr j'ai procédé de la sorte : plugin de test 
avec les fonction d'upgrade suivante :


```
$maj['create'] = array(array('spip_log', 'installation',  'test'));
$maj['2.0.0'] = array(array('spip_log',  'mise à jour 2', 'test'));
$maj['3.0.0'] = array(array('spip_log',  'mise à jour 3', 'test'));
```

- Au départ, le plugin a un schéma 1.0.0.
En activant le plugin, la fonction d'installation est bien appelée.
- Incrémentation du schéma à 2.0.0, rechargement de la page d'admin des 
plugins : la fonction de mise à jour n°2 est bien appelée.
- Incrémentation du schéma à 3.0.0, rechargement de la page d'admin des 
plugins : la fonction de mise à jour n°2 est bien appelée.
- Désinstallation, puis réinstallation : seule la fonction 
d'installation est appelée, alors que je m'attendais à ce que la 
fonction de mise à jour 3.0.0 soit également appelée.


Voilà,
à vous lire

C.R





Re: [spip-dev] Projet de refonte de l'espace privé de SPIP 3.0

2013-04-10 Par sujet Charles Razack
Ca commence à être vraiment sympa, le bandeau sur fond clair est 
beaucoup mieux.
Les icônes du bandeau prennent le dessus sur les autres plugins par 
contre (c'est à dire : j'utilise un autre plugin qui fournit des icônes 
pour le bandeau, et du coup elles ne sont pas utilisées).


En ce qui concerne ma remarque précédente sur la balise 
#ECRAN{pleine_largeur}, il y aurait moyen de régler ça soit au niveau du 
css :

- faire en sorte que .pleine_largeur.span9 = .span12
(j'ignore si c'est faisable en less)
ou alors au niveau du squelette :
- quand la div #conteneur a une classe .pleine_largeur (ajoutée par la 
balise), il faudrait que la div #contenu ait une classe .span12 au lieu 
de span9.

Bon je ne sais pas si je suis très clair, je pense tout haut là.

Tant que j'y suis 2 micro pétoules :
- les boutons ayant la classe .link ne devraient pas avoir de bordure ni 
de fond, cf. "ajouter un auteur"
- dans les listes d'objets, il y a une petite marge un peu disgracieuse 
en bas, au niveau de table.spip et table.liste


Une dernière remarque dont je te faisais part en privé :
Je verrais bien le texte des fiches objets (div #wysiwyg) dans une 
police "serif" type garamond ou autre, afin de distinguer le contenu 
éditorial du reste.



Le 10/04/2013 01:02, Ybbet Spip a écrit :

Bonsoir tout le monde,

Il y a eu quelques changements dans l'interface, notamment pour les
couleurs.
Pouvez-vous me dire si ça marche chez vous s'il vous plaît ? Ne pas
oublier de mettre un var_mode=recalcul dans votre url ;-)

Teddy





[spip-dev] SVP et m.a.j des plugins de la dist

2013-01-06 Par sujet Charles Razack

Bonjour,

Dans la page de gestion des plugins, une mise à jour manuelle est 
proposée lorsqu'une nouvelle version est dispo, mais qu'en est-il pour 
les plugins de la dist ?


Est-ce qu'ils se mettent-ils à jour automatiquement, ou sont-ils 'figés' 
entre chaque version de SPIP  ?


J'ai un plugin en dev qui nécessite un plugin de la dist dans une 
version plus récente que celle fournie avec la dernière release de SPIP, 
aussi je me demande s'il faut attendre la prochaine version de SPIP pour 
le publier, ou si c'est bon maintenant.


C.R



[spip-dev] filtre 'couleur_melanger'

2012-10-11 Par sujet Charles Razack

Bonjour la liste,

Pour compléter les filtres de couleurs automatiques, je suggère un 
nouveau filtre 'couleur_melanger' pour mélanger 2 couleurs entre elles.
J'utilise ça pour mes thèmes et je trouve ça fort pratique pour affiner 
un peu plus la gestion des couleurs.


Utilisation :
#ENV{claire}|couleur_melanger{88}
#CONFIG{mon_plugin/ma_couleur}|couleur_melanger{#ee, 0.2}
#VAL{88}|couleur_melanger{ff0066, 0.75}

Et le prototype : http://www.pasteall.org/36183/php

Vos avis ?

Toujours à propos des filtres de couleur, je trouve le nom du filtre 
'couleur_saturation' assez déroutant, on s'attend à ce que la couleur 
tende vers le gris en diminuant le coefficient comme c'est le cas dans 
n'importe quel logiciel de retouche d'image.

Une meilleure appellation eut été 'couleur_vibrance' par exemple.
Bref, il manque me semble-t-il un filtre se comportant comme indiqué 
plus haut.