Re: [spip-dev] [fontawesome5] mise à jour du plugin picto à la version fontawesome (...)

2020-09-26 Par sujet RastaPopoulos
Le 26/09/2020 à 12:35, RealET a écrit :
>> Si on a un problème ergonomique avec SVP quand il gère et prévient les gens 
>> des mises à jour : c'est ça qu'il faudrait corriger absolument, pas faire un 
>> préfixe par version majeur de plugin, non ?
> 
> Dans la mesure où SVP a un bouton "Cocher toutes les mises à jour", et un 
> comportement identique quel que soit les risques de la mise à jour, je trouve 
> que le choix de changer de préfixe est tout à fait cohérent.

Tu réponds ça en citant très exactement la phrase qui explique bien que c'est 
justement ÇA qu'il faut corriger…

Et je ne vois pas le rapport que ce soit Bootstrap, Foundation, FontAwesome, ou 
n'importe quel : ça vaut pour n'importe quel plugin. Si le plugin Agenda ou 
Formidable passe de la version X à X+1, en cassant de la compat, des boucles 
qui changent, etc, alors d'après cette argumentation ça voudrait dire qu'il 
faudrait faire un autre plugin avec un autre préfixe pour chaque. Pourtant ce 
n'est pas ce qu'on fait, et il ne faut pas faire ça.

Je crois qu'à peu près tout le monde est d'accord pour dire qu'il y a des 
problèmes importants d'ergonomie dans SVP. Il y a même un ticket explicitement 
sur ce point :
https://core.spip.net/issues/3017

Et deux autres sur l'ergo de SVP sur d'autres points (le sous-menu et le lien 
de configuration) :
https://core.spip.net/issues/3603
https://core.spip.net/issues/4429

Et j'ai travaillé une maquette ergo regroupant les solutions aux trois tickets 
à la fois, la dernière version (avec l'ajout de tcharlss) étant celle là :
https://core.spip.net/attachments/download/1179/3603.html

Cette ergonomie empêchant totalement de faire des mises à jour majeure sans le 
savoir. Tout est explicite.

Mais c'est de l'ergo… ensuite il faut faire une PR.

-- 
RastaPopoulos

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

Re: [spip-dev] [fontawesome5] mise à jour du plugin picto à la version fontawesome (...)

2020-09-26 Par sujet RastaPopoulos
Le 26/09/2020 à 11:31, erational a écrit :
> comme pour les plugins boostrap, j'aimerai qu'on propose des plugins pour 
> embarquer les versions majeures de ces libraires de facon simple d'où mon 
> plugin indépendant
> 
> suis-je plus clair ?

Pour moi oui.

En revanche pour l'instant je ne comprends toujours pas l'intérêt d'avoir des 
plugins réellement différents (= autre préfixe) pour chaque version de ce qu'on 
embarque.

Le principe du versionning sémantique c'est justement pour permettre de dire 
que quand on change la version X (dans X.Y.Z) c'est un changement majeur qui 
casse la compatibilité antérieure. Donc quel intérêt de carrément changer de 
plugin pour ça, alors que les numéros de version servent précisément à ça ?

Concrètement pourquoi un plugin prefix="fontawesome5" et non pas un unique 
plugin "fontawesome" ayant des branches Git "branches/v4", "branches/v5", 
"branches/v6", etc ?

Je sais qu'un argument est que ça empêche les gens de mettre à jour 
"automatiquement" vers une version majeure différente qui casserait leur site. 
Mais on a alors ce problème pour TOUS les plugins du monde qu'on a et qui 
changeraient de version X. Pourtant on ne le fait pas pour chaque plugin du 
monde. Quand le plugin Patates passe de 2.3.4 à 3.0.1, on ne fait pas un 
prefix="patates2" et un prefix="patates3", même quand ça casse le 
fonctionnement (ce qui est souvent le cas si on décide de changer X).

Si on a un problème ergonomique avec SVP quand il gère et prévient les gens des 
mises à jour : c'est ça qu'il faudrait corriger absolument, pas faire un 
préfixe par version majeur de plugin, non ?

-- 
RastaPopoulos

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


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

2020-09-15 Par sujet RastaPopoulos
Le 15/09/2020 à 08:25, Cerdic a écrit :
> Mais potentiellement il faut remettre à jour la listes des urls à 
> télécharger, en particulier si tu as des ressources générées automatiquements 
> (css, js..) dont les URLs peuvent changer (si tu as fais des modifs de 
> squelette), ou si tu veux que les visiteurs téléchargent par défaut les 
> derniers articles ou…
> 
> bref ça dépend aussi comment tu veux utiliser le plugin

Ok alors pour cette liste de démarrage : y a-t-il un squelette surchargeable 
permettant de personnaliser la liste des pages (justement pour "les derniers 
articles" ou plus précisément "la même liste que ceux qu'on voit sur 
l'accueil") ?

Car la doc parle de comment générer des boutons pour des objets entiers avec 
offline/urls-{objet}.html, ça ok. Mais pour la liste automatiquement chargée à 
l'installation ?
J'ai vu que dans la config ya un champ libre pour en personnaliser en plus à la 
main, mais ça c'est du ponctuel manuel. Pour faire comme les boutons pour 
objets, des automatismes (donc avec boucles) pour lister dans l'installation 
les mêmes que sur l'accueil, ya un squelette ou un pipeline PHP possible ?

Pour le build d'installation avec spip offline:build:services (ou le rebuild 
total avec les objets aussi), ya deux possibilités, pour que ce soit moins 
complexe pour Booz, et qu'il n'y ait que à changer le numéro dans l'admin :
- sur le serveur on peut programmer un vrai cron pour l'appeler une fois par 
nuit, et donc le lendemain ça enverra les nouveaux contenus aux gens, si ça 
suffit comme période
- si on veut encore plus de réactivité, on pourrait imaginer une option 
"--if-version-changed". Dans ce cas on pourrait programmer un vrai cron *toutes 
les minutes*, mais la commande sortirait immédiatement si ça détecte que la 
version éditoriale dans la config n'a pas changé depuis le dernier build. 
Évidemment pour pouvoir faire ça, il faut que lors d'un build, ça enregistre 
dans un fichier ou en base, le numéro de la version éditoriale utilisée à ce 
moment, pour pouvoir comparer ensuite.

-- 
RastaPopoulos

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


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

2020-09-14 Par sujet RastaPopoulos
Le 28/07/2020 à 20:43, BoOz a écrit :
> la mise à jour de la version éditoriale est complexe (ligne de commandes plus 
> vider le cache plus..., j'ai fini par me décourager en testant, il faudrait 
> que je m'y remette)

Ce point m'interroge : je croyais en lisant la doc que justement il y avait 
*dans l'interface* de la config, un "numéro éditorial" changeable manuellement 
(donc pas un admin sys), et que changer ce champ permettait de forcer la mise à 
jour du contenu chez les gens.

Et pas juste la doc, c'est l'explication collée au champ même : "Version 
éditoriale. Le changement de numéro de version force la mise à jour de toutes 
les pages en cache chez tous les visiteurs."

Du coup ce que tu dis pour le Diplo parait bizarre, ça ne marche pas ?

-- 
RastaPopoulos

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


[spip-dev] ***UNCHECKED*** Re: ***UNCHECKED*** Re: ***UNCHECKED*** Re: Statistiques avancées

2020-09-07 Par sujet RastaPopoulos
Le 07/09/2020 à 08:33, BERTRAND Joël a écrit :
> J'ai besoin de savoir que tel utilisateur se connecte à telle page à
> telle heure. C'est pour mettre des cours en ligne pour des collégiens et
> éviter qu'ils ne tirent au flanc en disant comme d'habitude "je me suis
> connecté mais il n'y avait rien à voir" (air connu).

Faut regarder ça 
https://plugins.spip.net/bigbrother.html

Mais c'est pas à jour, faut le tester en 3.2, changer la compat, et sûrement 
pas mal de corrections à faire dedans…

Donc si c'est juste pour utiliser tel quel, ya rien de prêt (enfin c'était prêt 
fut une époque mais plus maintenant), va falloir mettre les mains dans le 
cambouis.

-- 
RastaPopoulos

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

[spip-dev] ***UNCHECKED*** Re: Statistiques avancées

2020-09-07 Par sujet RastaPopoulos
Qu'est-ce que tu appelles "avancées", et le point principal n'est pas tant 
statistiques *de qui* mais surtout statistiques *de quoi*, pour compter quoi ?

-- 
RastaPopoulos

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


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

2020-07-28 Par sujet RastaPopoulos
Le 28/07/2020 à 20:43, BoOz a écrit :
> A part ça, pourquoi ne pas ajouter les push à Offline ?

Bé je l'ai dit plusieurs fois non ? :)
Parce qu'à part le service worker en centre, ça n'a strictement aucun rapport, 
qu'on peut parfaitement vouloir des pushs sans avoir besoin d'offline, comme 
l'inverse, ou autre fonctionnalité de PWA (la synchro de données en arrière 
plan… tout ce qui a besoin d'ajouter un event dans le SW). Chacune des ces 
fonctionnalités peut avoir pleiiin de code, peut avoir besoin de tables dans 
SPIP, etc. Donc tout mélanger dans le même plugin, vla le bazar tout-en-un à 
maintenir…

-- 
RastaPopoulos

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

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

2020-07-28 Par sujet RastaPopoulos
(répondre sur la liste :p)

Le 28/07/2020 à 11:55, Cerdic a écrit :
> Ah ben si c’est ça ton soucis et ton use case de maintenant, on peut ajouter 
> facilement une extensibilité de offline.

Bah disons que c'est *un* des soucis (pour avant-hier :p)

J'ai bien vu déjà tout le bazar de gestion complète (installation, mise à jour, 
désinstallation) du service worker dans Offline, qui est déjà pas mal complet 
et ça c'est super !

Au delà de l'aspect choix des utilisateurs (proprio qui veut une seule ou 
plusieurs fonctionnalités nécessitant un SW) qui implique une conception 
modulaire, même juste de notre point de vue dév maintenance du code, vu que 
d'autres événements (push ou autres) en ont obligatoirement besoin aussi, je 
m'étais dit que ça serait justement peut-être plus clair, plus facile à 
maintenir si c'est découpé :
- tout le code qui est propre à la gestion, quelque soit le contenu
- VS le code propre à chaque besoin, Offline qui gère le fetch etc
(par ex il pourrait y avoir des logs différents pour chaque morceau et donc 
suivant ce qu'on voit, on saurait si ça vient du plugin central ou de Offline 
ou de Push).

Mais pour l'instant de ton côté tu as l'air de penser que ça serait plus 
compliqué, ce que je comprends. :)

(Et pour revenir sur le point Non-2, je ne crois pas qu'il y ait "plusieurs 
plugins" au sens "plein" qui vont s'insérer dedans et qu'on contrôle rien : ce 
sont forcément quelques rares plugins qui "se connaissent" et qui vont faire en 
sorte de travailler ensemble, genre 2 ou 3 max. Le découpage proposé est là 
pour permettre d'avoir seulement ce qu'on veut, car mise à part le SW au cœur, 
chacun n'a aucun rapport, c'est des fonctionnalités totalement différentes, 
possiblement avec des tables SPIP, etc.)

À court terme, si déjà un plugin Push peut profiter immédiatement de ce qui 
existe et gérer ses événements à lui dans le SW, moi ça me va hein. On pourra 
découper mieux plus tard…


> Mais comme je le disais, offline n’est pas encore super fini, il reste des 
> soucis, il y a besoin de debug, ce qui prends du temps, et je suis 
> moyennement confiant sur le fait qu’ajouter des js en plus aide...

Bé pour un site j'ai vraiment besoin de Offline *et* de Push, donc je vois pas 
comment on… enfin au moins moi, je pourrais faire l'économie d'avoir plus de 
JS… :(

Pour Offline en particulier ça tombe bien, on peut aider à faire des retours, 
puisque besoin sur un site avec pas mal d'articles et beaucoup de visites.

Une des grosses différences que je crois voir, c'est que pour le Diplo c'est un 
mensuel, et donc peu de changement éditoriaux (on peut se permettre de changer 
manuellement la "version éditoriale" quand un nouveau numéro sort), alors que 
nous ya des nouveaux articles tous les jours, possiblement plusieurs fois par 
jour (l'accueil change tout le temps quoi). Et ya évidemment besoin que les 
gens puissent garder en mémoire au moins l'accueil + les articles liés dans 
l'accueil, quand ils ont une connexion, pas juste une fois par mois.

Mais bon on verra plus tard pour Offline, la priorité c'était surtout la 
structure générale, et le fait de pouvoir avoir *en même temps* qu'Offline un 
autre plugin qui permet de s'abonner à des pushs. :)

-- 
RastaPopoulos

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

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

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

Merci pour ces réflexions !

Alors je pourrais être d'accord (pas faire de la sur-qualité) si… c'était 
possible. :)

Car comme je le dis au début, la volonté de concevoir un truc modulaire 
concerne plusieurs cas :
- on peut ne vouloir qu'une seule des fonctionnalités (que l'offline, que les 
pushs, que de la synchro de données, etc)
- on peut vouloir plusieurs de ces fonctionnalités dans le même site

Présentement, c'est le deuxième pour moi : j'ai absolument besoin que les gens 
puissent lire hors-ligne *et* pouvoir s'abonner à des "flux" de notifs en push.

Alors comment "travailler en parallèle" si de base le fait d'avoir Offline 
empêche un autre plugin d'avoir aussi un service worker avec une portée "root" 
(tout le site) ?

Est-ce que l'idée ça serait que le plugin de Push soit pour l'instant forcément 
dépendant de Offline (donc sans plugin central mutualisateur) et que donc il 
doive surcharger "en dur" (pas par pipelines je veux dire) certaines fonctions 
de Offline ?
Un truc du genre : surcharger "action_api_offline_sw_js_dist()" pour ajouter un 
fichier JS à la liste, qui contiendrait "self.addEventListener('push'" + 
"self.addEventListener('notificationclick'" etc

Restera aussi la question de où mettre et rendre configurable (couleur, icône) 
le Manifest qui permet d'installer vraiment.

-- 
RastaPopoulos

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


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

2020-07-25 Par sujet RastaPopoulos

Après une semaine de diverses recherches, voici où j'en suis. Celleux qui 
s'intéressent à la question (notamment Cédric car Offline), merci de me dire ce 
que vous en pensez. :)

Rappel : une PWA, ce n'est pas une fonctionnalité précise, mais un ensemble de 
fonctionnalités JS qui augmentent les capacités d'un site web pour lui 
permettre des choses que seules les applis natives pouvaient faire avant. Et 
comme son nom l'indique : ça peut être progressif, on peut ajouter petit à 
petit des choses. Ça peut être :
- garder en mémoire des pages pour lire même déconnecté
- synchroniser des données régulièrement
- s'inscrire à des notifications push (qui arrivent donc même quand on n'a pas 
ouvert le site)

Point important 1 : on peut vouloir *une seule ou plusieurs* de ces 
fonctionnalités. C'est forcément modulaire, ya aucune obligation d'avoir tout.

Cependant elles utilisent un truc commun : un service worker, un programme JS 
qui tourne chez la personne en parallèle du site.

Point important 2 : il ne peut y avoir QU'UN service worker pour une même 
"branche" de l'arbo des URL. Et par défaut la portée est celle du dossier/URL 
où se trouve le fichier JS. Par exemple s'il est dans 
exemple.com/javascript/sw.js alors par défaut il ne pourrait servir que pour 
les requêtes sous exemple.com/javascript/…  Si le fichier est à la racine du 
site, alors la portée par défaut est "tout le site".

Le plugin Offline de Nursit, fait pour le Diplo et utilisé en test grandeur 
nature sur Contrib, ajoute la fonctionnalité "lecture hors ligne" :
https://git.nursit.net/open/offline
(au passage maintenant qu'on a git, est-ce qu'il pourrait être dans la 
communauté ?)

Ce plugin ajoute donc UN service worker, pour TOUT le site, mais seulement pour 
la fonctionnalité "hors ligne". Du coup quand on veut ajouter une autre 
fonctionnalité, les pushs par ex, il est impossible d'avoir un autre SW pour la 
même portée. J'ai bien cherché s'il était possible de coder les pushs dans un 
SW avec une portée bidon car ya pas à capter les requêtes (événement "fetch") 
on s'en fout. Mais impossible d'avoir une réponse exacte à ça et la doc dit 
plutôt le contraire :
https://developer.mozilla.org/fr/docs/Web/API/PushEvent
> Cet événement est envoyé au scope global d'un ServiceWorker

Je propose donc que SPIP ait un plugin "pwa" commun, qui va mutualiser :
- la génération d'un fichier JS de service worker ayant une portée globale
- mais ce fichier serait VIDE par défaut, et ce sont à des sous-plugins comme 
Offline ou Webpush d'ajouter du JS pour capter des événements dedans (qui 
"fetch", qui "push", etc)
- l'inscription de ce SW dans le site
- la désinstallation
- la gestion de la version, comme le fait déjà Offline et donc la mise à jour 
chez les gens : cela se ferait si on ajoute ou retire un sous-plugin qui 
s'insère dans son JS + quand des sous-plugins le demandent en plus (comme 
Offline quand on a une version de site qui change)
- comme ce serait LE plugin commun, c'est aussi là qu'on déclarerait le 
"manifest" permettant d'installer le site-appli sur l'accueil des mobiles 
(comme tout autre appli)

Il faudra donc modifier Offline pour s'insérer dedans, et non plus fournir son 
propre service worker.

-- 
RastaPopoulos

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

Re: [spip-dev] api objet_modifier

2020-07-24 Par sujet RastaPopoulos
Le 24/07/2020 à 14:23, tofulm a écrit :
> J'ai loupé une étape ?

objet_inserer() n'appelle aucune autorisation

objet_modifier() n'appelle aucune autorisation

objet_instituer() appelle une autorisation (parmi trois : publierdans, 
instituer, modifier)

=> incohérence (et l'incohérence, c'est mal)

En ce qui me concerne, j'ai toujours dit qu'il faut absolument avoir une API 
centrale (CRUD quoi les opérations vraiment de base), qui n'appelle AUCUNE 
autorisation. Sinon il est souvent impossible de les utiliser dans des scripts 
en masse ou même dans des plugins avec les pipelines etc.

Pour les opérations de base (insérer, modifier), il me semble que 
autoriser_exception() est un non-sens, une erreur d'architecture. Car il est 
structurellement impossible de connaître *par avance* la liste des 
autorisations qui vont s'exécuter ! Avec les pipelines, les plugins qui 
s'insèrent dedans, de nombreuses opérations peuvent se dérouler en cascade : 
objet_modifier() sur tel objet va possiblement en modifier 3 autres en cascade. 
Et quand on veut que ça se fasse forcément, qu'on ne connait pas qui fait le 
hit PHP, impossible de connaitre les autorisations à mettre à "false". C'est la 
structure même des fonctions avec chacune leur pipeline qui rend cela 
impossible.

Je pense toujours qu'on devrait tenter de retirer ses quelques autorisations 
restantes. Et surtout ne pas en rajouter dans les deux qui n'en ont pas.
Celles-ci devraient être :
- dans les squelettes pour autoriser l'affichage ou pas d'une action de 
contrôle (formulaire CVT, bouton d'action, etc)
- dans les CVT et les actions appelables par bouton (qui sont les vraies 
interfaces humaines par le HTML)
- dans les actions appelées dans des API au sens "API distante" (REST etc) : 
c'est une autre forme d'interface, différente du HTML
- mais pas dans les fonctions de base, qui ne sont pas des interfaces (humaines 
HTML ou pas)

-- 
RastaPopoulos

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


Re: [spip-dev] Compte Gitea

2020-07-23 Par sujet RastaPopoulos
Le 23/07/2020 à 19:29, CSI a écrit :
> Quelle est la procédure pour avoir un compte sur git.spip.net ? pour
> l’instant j'en ai besoin pour ouvrir un ticket (ou une demande de
> fonctionnalité plutôt) ...

Si tu avais un compte sur la zone SVN, c'est pareil.

Sinon un admin ici va te créer tout ça.

-- 
RastaPopoulos

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

Re: [spip-dev] Questions Formidable et paiement

2020-07-23 Par sujet RastaPopoulos
Le 23/07/2020 à 17:32, CSI a écrit :
> qui n'est pas sorti sur la
> liste (je ne l'ai pas reçu)

Il y est pourtant bien, à 00h20 chez moi.

> Peut-être devrai-je mettre cette demande sur Spip-contrib ?

Les forums c'est plus pour du support à l'utilisation. Pour des bugs ou 
améliorations, il y a les tickets maintenant : 
https://git.spip.net/spip-contrib-extensions/formidablepaiement/issues

-- 
RastaPopoulos

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


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

2020-07-20 Par sujet RastaPopoulos
Le 20/07/2020 à 13:14, "Rémi Suinot via spip-dev 
"@alan.cursys.net a écrit :
> Mais si je cadre à ma façon la tour de Pise à 90°, allez vous la recadrer de 
> 3°59' (exactement!)?

Ça n'a strictement aucun rapport, c'est même l'inverse. Suivant les appareils, 
si tu prends en portrait au lieu du paysage classique (donc appareil tourné à 
90), alors parfois la photo enregistrée est "physiquement" directement tournée 
(largeur petite, hauteur grande) OU BIEN parfois elle est "physiquement" en 
paysage MAIS avec une indication dans l'exif disant "cette image doit être 
visionnée tournée à 90" (et l'inverse sur les mobiles ou c'est plutôt le 
portrait par défaut, je crois)

Or justement sans cette prise en compte, la photo vue dans l'admin ne sera PAS 
vue comme tu l'avais prise, tournée à 90, pas comme tu voudrais la voir. JLuc 
dit donc que SPIP devrait bien toujours prendre en compte cette information et 
afficher la photo comme TOI tu voulais qu'elle soit, car c'est ce qu'attende 
les gens intuitivement. C'est donc l'inverse, c'est actuellement sans cette 
prise en compte que ça modifie et n'affiche pas comme tu l'avais prise. Et 
Cédric précise en disant que normalement SPIP a bien un code pour que ce soit 
pris en compte mais que peut-être il y a un bug et que ça ne marche plus (à 
confirmer et faire un ticket pour ça donc).

-- 
RastaPopoulos

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


Re: [spip-dev] Documentation sur les temps de connexion

2020-07-09 Par sujet RastaPopoulos
Le 03/07/2020 à 19:37, JLuc a écrit :
> Et ça marche bien

Ok mais la question là n'est pas juste quoi faire mystérieusement, mais de 
comprendre, la doc quoi. :)

C'est un mystère et ça reste flou pour tout le monde sauf 2 ou 3 personnes ?

-- 
RastaPopoulos

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


[spip-dev] Documentation sur les temps de connexion

2020-07-03 Par sujet RastaPopoulos

J'ai l'impression que la doc sur combien de temps on peut être connecté et 
comment ça se modifie est incomplète mais aussi confusionante. Et moi-même je 
ne sais du coup jamais ce que ça fait :p

Quand je lis :
https://www.spip.net/fr_article5716.html
ça parle d'un temps de *session* de 12h, et qu'on peut le modifier.

Mais la case dans le formulaire de connexion dit *quelques jours*. On est 
d'accord que 12h c'est pas quelques jours ? :)
Donc les "quelques jours", c'est la validité d'un cookie, pas la session ? Mais 
c'est quoi le temps de session alors ? Par rapport à mon navigateur, quand je 
me barre, que je l'éteins, ça correspond à quoi ?

Et ces validités de cookies, ils sont automatiquement calculés suivant cette 
session (là ça parle de 4 × la variable) ? ou bien on peut les personnaliser 
séparément ?

Cas concret : j'ai un site avec des abonné⋅es, comptes uniquement visiteurs 
publics donc, et ça se déconnecte toujours trop vite. Pourquoi ? Que doit-on 
changer pour ça ? Plusieurs choses ? Une seule chose ?

Bonus : peut-on imaginer une méthode pas trop compliquée pour définir un temps 
différent suivant les machines ? Du genre plus long sur un navigateur mobile 
que sur un ordi bureau (on partage pas trop son mobile) ?

Je mettrai à jour l'article (ou les) suivant les réponses :)

-- 
RastaPopoulos

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

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

2020-06-29 Par sujet RastaPopoulos
Le 29/06/2020 à 19:25, Eric Lupinacci a écrit :
> La liste est ici : http://spip.pastebin.fr/63331

Merci !

En ce qui me concerne dans ta liste il faut migrer :

agenda_dates_floues : permet de préciser qu'une date est floue (mai 2020, 
printemps 2021, etc), et filtre pour afficher
amappca : début de conception pour gérer amap ou autre circuit court avec une 
archi tentant de pouvoir gérer plein de cas
api_syntaxe : donne accès à des fonctions de transformation de texte (propre, 
_T, typo, etc) par API
app : API Atom, lecture seulement mais pourrait gérer l'écriture (APP est 
standardisé)
ayants_droit : gérer des ayants droit sur n'importe quel contenu (objet lié), 
avec les dates de validité, etc
devis : objet simple représentant un devis
menus_partager : insérer un menu déclaré dans un autre site SPIP
mesfavoris_collections : pouvoir organiser ses favoris en collections
prestations : lister des prestations dans n'importe quel contenu (objet lié)
styleguide : à la base pour essayer de générer un guide de style, en suspens 
mais à garder
tout_partout : appliquer {tout} partout

Eh bé, ça fait un paquet de truc à continuer ou documenter un jour…

Mais il y en a dont je sais très bien qu'il n'y a ni ZIP ni doc, et donc en 
théorie qui n'avaient pas été détectés pour migration, et pourtant ils ne sont 
pas dans ta liste. Donc je ne sais pas la méthode que tu as utilisé, mais je ne 
peux pas aller vérifier s'ils sont déjà sur la forge vu que serveur de nouveau 
down complet.

acces_restreint_date : configurable par rubrique, restreindre auto les articles 
suivant leur date, avant ou après une période
acces_restreint_ip : donner accès à des IP ou tranche d'IP, sans même avoir à 
se connecter
acces_restreint_videos : obliger à faire partie d'une zone pour voir un doc 
inséré
souhaits : gérer des listes de souhaits, avec lien, prix, et form pour proposer 
d'offrir, y compris par cagnotte, afin de ne pas donner ces infos très persos à 
des services "gratuits"

et peut-être d'autres… mais on verra demain

(merci touti pour l'idée d'en profiter pour dire à quoi ça sert)

-- 
RastaPopoulos

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

Re: [spip-dev] Redirection #FORMULAIRE_INSCRIPTION

2020-06-29 Par sujet RastaPopoulos
Le 29/06/2020 à 13:52, RealET a écrit :
>> [(#FORMULAIRE_INSCRIPTION{6forum,0,#URL_PAGE{bienvenue}})]
>> Donc pour recharger entièrement la page je mettrais un #SELF.. ;)
> Bernard, commence par lire :
> https://core.spip.net/issues/3599#note-8

Et encore une personne de plus qui a compris le truc à l'inverse de ce que ça 
fait ! :)
évidemment pour la raison que je n'arrête pas d'évoquer : parce que tous les 
autres formulaires du monde fonctionnent différemment comme cela, l'URL étant 
la redirection immédiate après traitement, et donc incohérence, et donc on 
comprend de travers de manière totalement légitime

-- 
RastaPopoulos

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


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

2020-06-26 Par sujet RastaPopoulos
Le 26/06/2020 à 14:30, nicod_ a écrit :
> Je m'interroge toujours là dessus : est ce qu'on le remplace par une simple 
> liste en json par exemple, versionnée par branche donc, en attendant d'avoir 
> une vraie gestion de dépendances ?

+1
comme rappelé dans le ticket concernant le déplacement de Bigug
https://core.spip.net/issues/4482#note-3

Car s'il est sur la communauté désormais, dans le fichier c'est toujours celui 
de Github qui est déclaré + c'est juste stocké dans le master + ensuite dans 
checkout/spip-cli yavait une bidouille d'exception *en dur* dans le code, 
disant que ce plugin en particulier ne devait être mis que pour le master et 
pas les autres. Et donc là à priori faut tout changer de comment ça fonctionne, 
et oui il faudrait une liste explicite pour chaque branche.

-- 
RastaPopoulos

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


Re: [spip-dev] Mots multi parents ?

2020-06-24 Par sujet RastaPopoulos
Le 24/06/2020 à 11:39, cam.lafit a écrit :
> Polyhierarchie a dans son code une logique multi objet.
> J'avais regardé il y a (très) longtemps pour gérer ça pour un autre type 
> d'objet et cela semblait jouable sans trop de galère.

Si l'architecture de tous ces classements correspond déjà à ça, oui, de mon 
point de vue ça parait plus logique d'utiliser Polyhiérarchie qui est méga 
éprouvé et qui sert à ça depuis des années, plutôt que de recoder en fait 100% 
la même chose que Polyhiérarchie dans un autre objet. En terme de structure, 
tout est déjà là et d'après moi c'est ça qui est important à maintenir. Ensuite 
on peut toujours améliorer l'interface, personne n'est contre je crois… :)

Et là, pour l'interface, ce qui manque pour moi, c'est que Polyhiérarchie a 
toujours son exception dans sa table de lien (ça utilise id_parent au lieu de 
id_rubrique) et donc l'API des liens du noyau ne reconnait pas la table, ce qui 
ne facilite pas le même type de "bloc de liaison" habituel. Si on pouvait avoir 
le bon nom du champ (ou si l'API des liens permettait d'avoir le nom qu'on veut 
!) ça permettrait pas mal de facilités ensuite…

-- 
RastaPopoulos

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

Re: [spip-dev] Filtres |couper + |propre

2020-06-24 Par sujet RastaPopoulos
Bé ça dépend ce que tu as dans ton #DESCRIPTIF* là, donc difficile de dire…

Cela dit tu vas couper que le texte *de syntaxe SPIP* donc du coup tu peux pas 
être assuré qu'il va y avoir que 160 à la fin, si ya des modèles etc.

D'où la fonction texte_truncate() rajouté à Bonux il y a 5 ans, qui permet de 
couper du HTML final directement. :)
(cf aussi le ticket dans bonux pour faire une fonction plus simple par dessus)

-- 
RastaPopoulos

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

Re: [spip-dev] r125253 - _plugins_/spip-bonux/trunk

2020-06-20 Par sujet RastaPopoulos
Le 20/06/2020 à 15:50, nicod_ a écrit :
> 
> tu as mélangé une modification de l'indentation et tes propres modifs dans ce 
> commit unique, ce qui fait que le diff est illisible, on ne peut pas lire ce 
> que tu as modifié (sauf manip acrobatique).

Tutafé, et du coup, vu que c'est moi qui l'ai ajouté et que je l'utilise pas 
mal, jluc tu as fait quoi dessus donc ? :)

Comme 99% de bonux, ça devrait pouvoir être ajouté au core, dès la 3.3… ça fait 
5 ans c'est là "pour tester" quand même…

-- 
RastaPopoulos

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

Re: [spip-dev] Compositions / SpipR : passer des paramètres au body

2020-06-20 Par sujet RastaPopoulos
Tu peux avoir un squelette body dédié à un objet ou une composition oui.

-- 
RastaPopoulos

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


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

2020-06-17 Par sujet RastaPopoulos
Le 17/06/2020 à 12:23, cam.lafit a écrit :
> Par exemple sur l'api gitea comme le fait l'autre script d'import.
> Avant d'avoir une logique via composer.
> 
> https://git.spip.net/spip-contrib-outils/git_loader/src/branch/master/git_loader.sh#L84

On ne veut justement pas tous les dépôts maintenu par l'équipe noyau. Tous ne 
sont pas dans les plugins-dist distribués de base. Pour chaque distribution, 
les plugins-dist sont une liste explicite, qui n'est ni l'entièreté des dépôts 
de l'orga "spip", ni n'est forcément la même pour chaque version de SPIP.

-- 
RastaPopoulos

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


Re: [spip-dev] [HS] Problème CSS : position: fixed sur Android

2020-06-16 Par sujet RastaPopoulos
Le 17/06/2020 à 00:08, Stephane Santon a écrit :
> Avez-vous des infos sur une telle différence de comportements ?
> (ou bien ai-je manqué qqchose dans mes CSS ?)

Ici c'est la liste de développement de SPIP et des plugins, tu devrais au 
minimum déplacer ta question sur spip-user.

-- 
RastaPopoulos

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


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

2020-06-16 Par sujet RastaPopoulos
Attention changement : le répertoire d'install n'est plus un argument avec une 
place précise, mais une option --dest ou -d, qu'on met donc où on veut.

Comme avec Console, on peut pas simplement avoir des mêmes arguments qui 
veulent dire plusieurs choses (l'argument numéro 2 ne peut être que XXX), c'est 
beaucoup plus logique que ce soit une option. Toujours le dossier courant par 
défaut.

-- 
RastaPopoulos

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


Re: [spip-dev] Open calais ?

2020-06-15 Par sujet RastaPopoulos
Le 15/06/2020 à 19:04, JLuc a écrit :
> je n'ai que de mauvais résultats où seuls apparaissent les noms propres 
> géographiques ou de célébrités ou de grosses entreprises.
> Je crois que ce n'est pas adapté au français.
> La démo en tout cas.

C'est très exactement pour ça que c'était utilisé sur seenthis, ça n'a jamais 
été pour autre chose : villes, personnes…

-- 
RastaPopoulos

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

Re: [spip-dev] Écriture inclusive

2020-06-14 Par sujet RastaPopoulos
Le 14/06/2020 à 22:35, RealET a écrit :
> Avec une dédicace particulière à Rasta qui adore les regex

tou(te)?s  plutôt :)

-- 
RastaPopoulos

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


[spip-dev] Désactiver Adaptive images sur des pages entières ?

2020-06-10 Par sujet RastaPopoulos


J'ai le soucis par exemple sur les affichage en mode web des newsletters. C'est 
en web mais ça reste le code avec tous les styles nazes email etc, et adaptive 
peut tout péter en se mettant là alors qu'il n'y est pas dans les emails.

Il y a la classe no-adapt-img, mais on est obligé d'ajouter ça sur 100% des 
images des lettres une par une  (sachant qu'on n'a pas la main sur tout, images 
en modèle dans les contenus, etc), ou bien est-ce qu'il y a une méthode pour 
désactiver totalement Adaptive sur une page entière ?

-- 
RastaPopoulos

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


Re: [spip-dev] Écriture inclusive

2020-06-08 Par sujet RastaPopoulos
Le 08/06/2020 à 17:44, Perline-Spip a écrit :
> Le point median si ?

Oui le point médian est insécable. (Nico le disait dans un autre message hier 
soir)

Par ailleurs, chaque ponctuation à un sens, et c'est mieux lorsqu'il n'y en a 
qu'un et un seul, pour ne pas avoir de conflit. Le tiret court a déjà un autre 
sens (mot-composé).

Exemple donné par Romy déjà dans son article il y a 3 ans :
Vice-président-e

Là on aurait deux fois le tiret, avec deux sémantiques différentes, pour deux 
besoins différents : c'est confus. Le choix des québécoises n'est donc pas 
spécialement plus pertinent que le choix des groupes et assos féministes 
françaises (qui vont majoritairement vers le point médian).

Vice-président⋅e

-- 
RastaPopoulos

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

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

2020-06-06 Par sujet RastaPopoulos
Le 06/06/2020 à 21:07, teamspipfact...@gmail.com a écrit :
> cela aurais du être
> https://git.spip.net/spip-contrib-extensions/pcqd
> 
> le référentiel pourrais eventuellement être
> R pour la rédaction
> w pour la webmasterisation
> C pour le commerce
> 
> donc notre 
> https://git.spip.net/spip-contrib-extensions/paniers_commandes_quantites_decimal
> deviens
> CPQD

Il est 2h30, et après X (trop) verres de rhum : c'est de la merde, on se refait 
pas :p

paniers_commandes_quantites_decimal est bien mieux et plus compréhensible, 
surtout quand on fait des sous-plugin de plugin (et ça arrive de plus en plus 
souvent à partir du moment on dit qu'un plugin fait qu'une seule chose)

je préfère un truc clair, pas cryptique, que je comprends sans même lire un 
article de doc, même à 2h30 du mat avec rhum

-- 
RastaPopoulos

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


Re: [spip-dev] Écriture inclusive

2020-06-06 Par sujet RastaPopoulos
On va finir pas cocher le bingo complet du sexisme.

La plupart des femmes n'en ont strictement rien à foutre d'être vénérées, par 
toi ou quiconque d'autre. Elles demandent "juste" l'égalité.

Le langage est un des lieux où on peut augmenter l'égalité, personne au monde 
n'a dit que c'était le seul, mais c'est l'un des lieux, donc là aussi ça doit 
être fait, comme plein d'autres domaines (salaires, etc).

-- 
RastaPopoulos

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


Re: [spip-dev] Écriture inclusive

2020-06-05 Par sujet RastaPopoulos
Le 05/06/2020 à 10:42, Eric Lupinacci a écrit :
> On pourrait aussi édicter quelques recommandations sur l’écriture des items 
> de langue pour homogénéiser les habitudes.

On parlait aussi l'autre jour d'augmenter un peu la charte pour être plus 
explicite sur ce point. Après elle doit rester concise, le but n'est pas de 
faire une formation à l'écriture dans la charte, mais on doit pouvoir 
l'augmenter d'une ou deux phrases pour être plus clair sur l'écriture.

-- 
RastaPopoulos

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


Re: [spip-dev] Écriture inclusive

2020-06-04 Par sujet RastaPopoulos
Le 04/06/2020 à 19:53, Christian Marget a écrit :
> - si je trouve une parenthèse comme dans technicien(-ne), la parenthèse
> se transforme à l'oral en «ou technicienne» qui me vient naturellement.
> Ce qui n'est pas le cas du «technicien.ne», excusez-m'en.

Sommet de mauvaise foi :D cet exemple est typique d'uniquement un problème 
d'habitude. On a appris des signes, et quand à XX ans on en voit un nouveau 
qu'on ne connaissait pas, on est perdu. Si depuis 3 ans on voyait des points 
médians, personne ne dirait cela, pas plus qu'un point-virgule ou deux-points. 
C'est d'ailleurs un argument que je trouve fallacieux y compris pour certains 
handicaps, parce qu'un truc "inconnu" ralentirait la lecture et la 
compréhension… mais si on ne l'utilise jamais, forcément ça reste à jamais 
inconnu. Je suis persuadé que dans la majorité des cas (y compris pour les 
aveugles une fois que les logiciels de lecture le prendront en compte), ça ne 
ralentira absolument personne une fois intégré.

De manière objective, "technicien(-ne)" est strictement équivalent à 
"technicien⋅ne" en terme de ce qu'on y fait dans le mot, sauf que l'un est 
immensément plus léger typographiquement/visuellement parlant (ce qu'avait déjà 
souligné Tetue dans un article de son site). Et au niveau sémantique, sans 
enfermer la forme féminin "entre parenthèse", donc moins importante, annexe, ce 
qui est le sens des parenthèses : une information annexe (et ce pourquoi la 
parenthèse est critiquée pour l'inclusivité depuis des années et des années, et 
ne fait partie d'aucune recommandation, ni des assos féministes, ni des 
ministères).

La séparation intérieur aux mots, quelque soit le signe typographique, doit 
toujours être en dernier recours. D'abord on doit chercher une formulation 
épicène (= qui vaut de base pour tout le monde), puis en deuxième on doit 
doublonner ou faire une périphrase lorsqu'on le peut (= si on a la place, texte 
long, et que ça n'aboutit pas à un truc immense et lourd).

Mais il reste toujours des cas où on DOIT faire court, notamment dans un 
logiciel justement, pour des éléments d'interface (label, bouton, titre de 
colonne, etc) où il ne sera jamais question de phrase hyper longue. Dans ces 
cas uniquement, en dernier recours, je continue de penser que c'est la moins 
pire des solutions que de faire des mots avec un point médian (et un seul, pas 
10 dans le même mot). Moins pire évidemment que de laisser le masculin parce 
qu'on doit garder un label d'interface en 2-3 mots maximum pour tel endroit où 
il y a peu de place.

Et là, on aura beau râler en accessibilité, pour les cas où de toute façon on 
va embêter, il faut bien arbitrer, et je préfère un mot "Utilisateur⋅ices" qui 
rajoute la moitié de l'humanité, que devoir laisser "Utilisateur" pour 
l'accessibilité. Évidemment il faut faire en sorte de se retrouver le moins 
possible dans ces choix hein, mais ça arrive toujours, et il faut arbitrer (et 
tant mieux si on trouve d'autres solutions !).

-- 
RastaPopoulos

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

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

2020-06-03 Par sujet RastaPopoulos
Le 03/06/2020 à 20:56, RealET a écrit :
> n'est pas accessible

N'est pas accessible *pour l'instant*. Les logiciels de synthèse vocale ne sont 
que des logiciels, du code, qui peut évoluer avec la langue comme n'importe 
quel logiciel peut évoluer.

On ne va pas s'interdire indéfiniment d'avoir des manières d'écrire inclusives 
plus légères et courtes que doublonner tous les mots possibles dans les deux 
genres à chaque fois, parce qu'un logiciel n'est pas encore mis à jour. Trouver 
des solutions temporaires oui peut-être, mais à un moment c'est bien à ces 
logiciels de se mettre à jour.

-- 
RastaPopoulos

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


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

2020-06-03 Par sujet RastaPopoulos
Le 03/06/2020 à 15:36, Cerdic a écrit :
> Attention, l’analogie SVN est piégeuse car il y a une différence 
> philosophique dans la gestion des sources entre git et svn.

Oui, enfin c'est pas forcément une correspondance "1 pour 1", ça peut être plus 
ou moins de commandes suivant les cas.

Mais il y a pourtant bien une "liste d'actions" qui est exactement la même, peu 
importe comment c'est fait avant ou maintenant : pour "récupérer SPIP" avant je 
faisais comme ça, maintenant je dois faire comme ça, pour "récupérer tel 
plugin" avant je faisais comme ça, maintenant… pour "envoyer mes modifications 
dans un plugin", etc.

-- 
RastaPopoulos

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


Re: [spip-dev] Problème d'une recherche lorsqu'il existe plusieurs boucle sur le même type d'objet

2020-05-29 Par sujet RastaPopoulos
Le 29/05/2020 à 17:00, Cerdic a écrit :
> C’est donc corrigé sur dev
> https://git.spip.net/spip/spip/commit/0880b517b0dd3464e5feb85bd6fbb392c3181f88
> et reporté en 3.2
> 
> Le problème provenait d’un décalage entre la date php et la date sql, et 
> pouvait donc se produire aussi bien en mysql qu’en sqlite
> En principe le fix n’introduit pas d’autres bugs :p

Je confirme que ça corrige bien chez moi, merci !

-- 
RastaPopoulos

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


Re: [spip-dev] Problème d'une recherche lorsqu'il existe plusieurs boucle sur le même type d'objet

2020-05-29 Par sujet RastaPopoulos
Le 28/05/2020 à 09:21, Cerdic a écrit :
> Là comme ça je reproduis pas ni en SPIP 3.3dev ni en SPIP 3.2
> Qui plus est si tu dis que tu as la même chose avec et sans plugin fulltexte 
> ça me parait bien louche...

Alors je ne sais pas sur Fulltext, mais l'autre jour je signalais un truc à peu 
près à tcharlss en m'échinant pendant des heures à comprendre pourquoi ça 
sortait rien, et il ne reproduisait pas, et sur le site de dev en ligne non 
plus, ça marchait. Mais en local sur mon instance, dès qu'il y avait deux fois 
la même recherche, pour le même objet, alors ça ne sortait rien !

En local je suis en SQlite alors qu'en ligne c'est en MySQL.

C'est même pas dans le même squelette mais dans la même page : dans le racine 
je fais diverses boucles de recherche (une articles, une rubriques, une 
événements) pour avoir le total à mettre dans des onglets, et ensuite dessous 
j'appelle des INCLURE avec l'une des listes (soit les articles, soit les 
rubriques…). Et donc pour un même objet, mettons les articles, il y a deux 
mêmes boucles de recherche, une pour le total, puis une dans l'INCLURE pour la 
vraie liste.

Et bien pareil que décrit là, ça ne retourne rien pour la deuxième, alors que 
la première affiche le bon total, donc sort bien tous les résultats !

J'aimerais bien comprendre pour reproduire aussi puisqu'en ligne tout 
fonctionne…

-- 
RastaPopoulos

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


Re: [spip-dev] pages

2020-05-27 Par sujet RastaPopoulos
Le 27/05/2020 à 15:30, Maïeul Rouquette a écrit :
> - = et - sont reservé historiquement dans spip pour la gestion des variantes 
> de squelettes liés aux rubriques, avec d'ailleurs l'idée qu'il y a une 
> hierarchie des rubriques et que = permet de distinguer de tirer
> - pour l'heure nous n'avons pas de hierarchie des compositions (on a pas de 
> mecanisme d'héritage dans composition, et je vois pas trop ce que cela 
> donnerait), mais du coup je me dit qu'un sépareteur autre pourrait être 
> pertinent

Je ne vois pas ce que tu veux dire pas là. "-" signifiait de toute la branche 
de l'id_rubrique, alors que "=" signifiait de cette rubrique précise 
uniquement. Ya bien une différence "famille" versus "truc exact".

Là c'est pas avec des id numériques mais ça s'en rapproche "famille d'articles" 
(tous les articles ayant la composition "patate") versus "l'article précis" (la 
seule page ayant l'identifiant "patate").

Sinon si si les compositions ont des héritages (telle compo peut dire que les 
objets enfants ont telle autre composition, etc en cascade). :)

-- 
RastaPopoulos

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


Re: [spip-dev] pages

2020-05-27 Par sujet RastaPopoulos
= me parait très bien, je change ça tout de suite

-- 
RastaPopoulos

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


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

2020-05-27 Par sujet RastaPopoulos
Le 27/05/2020 à 12:07, RealET a écrit :
> Ou, est-ce que comme convenu lors de la dernière SPIP-Party, git sera le seul 
> a écrire sur la zone et on pourra continuer à faire les installations et 
> mises à jour par SVN ?

=>

> - la synchronisation svn-git **serait coupée** et on arrêterait le subgit

Ça me parait assez clair : on arrête complètement de maintenir SVN, car ça 
complexifie tout. La synchro aura été gardé le temps de la migration, pendant 
plusieurs mois. Mais au bout d'un moment stop là on arrête et on ne garde plus 
que Git.

-- 
RastaPopoulos

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


Re: [spip-dev] Splickrbox

2020-05-22 Par sujet RastaPopoulos
Hello,
https://zone.spip.net/trac/spip-zone/wiki/SplickrBox

Mais merci d'arrêter le cross-posting, c'est une mauvaise pratique malpolie, 
sauf cas exceptionnel (annonce générale des admins etc).
Là tu as envoyé le même message aux trois listes à la fois, sachant que 
spip-zone n'existe plus, ça a été dit beaucoup de fois.

-- 
RastaPopoulos

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


Re: [spip-dev] r124365 - in _plugins_/prix

2020-05-19 Par sujet RastaPopoulos
Le 19/05/2020 à 19:09, toutati a écrit :
> attention donc, le plugin prix ne fonctionne pas en PHP 7.2 mais en PHP 7.1

Je ne sais pas si c'est la "bonne" résolution car : le test que je décrivais 
dans mon message précédent où je disais que je ne reproduisais pas c'est : en 
PHP 7.2. Donc si si, ça marche parfaitement en 7.2.

Possible que ce soit plutôt une question de quels modules PHP sont installés ou 
pas (intl etc). tcharlss avait fait un fallback, mais cela dit, c'était pour 
les devises, je vois pas immédiatement le rapport avec les arrondis :)

-- 
RastaPopoulos

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


Re: [spip-dev] r124365 - in _plugins_/prix

2020-05-18 Par sujet RastaPopoulos
Le 18/05/2020 à 17:02, toutati a écrit :
> Après des tests, ce n'est toujours pas bon.
> 
> Il semble que ce soit à l'enregistrement de spip_commandes_details qu'il 
> traine un arrondi, puisque 19,50 x 3 retourne 57 :/
> 
> j'arrête les investigations, tant pis pour aujourd'hui …

Je ne reproduis pas, site de test en 3.2 avec aucun plugin à part Prix et 
Commandes à jour (et Saisies). J'ai créé une commande que j'ai remplis avec un 
détail à 19,50 l'unité et 3 en quantité, et le prix de la commande est bien de 
58,50 HT

-- 
RastaPopoulos

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

Re: [spip-dev] Cloner tout git.spip.net

2020-05-15 Par sujet RastaPopoulos
Le 15/05/2020 à 15:40, nicod_ a écrit :
> Les script crée un dossier cache et un dossier par répos des orgas dans son 
> propre répertoire, donc ça ajoute des fichiers non gérés qu'il vaut mieux 
> ignorer.

Juste parce que je suis pas sûr d'avoir tout compris : non gérés par quoi ? Car 
tous ces fichiers sont *à l'extérieur* de chaque dépôt Git non ?

À moins qu'on parle de transformer soi-même l'ensemble immense en un autre 
dépôt Git perso contenant tout ?

-- 
RastaPopoulos

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


Re: [spip-dev] Bug-sur-filtres_images-image_recadre_mini

2020-05-13 Par sujet RastaPopoulos
Hello, 
ça ce sont les tickets pour signaler un problème sur le site de doc

Les tickets de SPIP et plugins-dist n'ont pas bougé depuis des années, c'est 
toujours sur core.spip.net

-- 
RastaPopoulos

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


Re: [spip-dev] git.spip.net et reboot hardu

2020-05-10 Par sujet RastaPopoulos
Le 11/05/2020 à 00:38, nicod_ a écrit :
> Y'a moyen de vérifier tous les dépôts en lot pour identifier tous les 
> problèmes à coup sûr ?

+1
je demandais similairement sur IRC tout à l'heure :

> (19:06:54) RastaPopoulos: ya un paquet de dépôts pétés en fait apparemment 
> azerttyu
> (19:07:02) RastaPopoulos: tous les jours on va en découvrir des nouveaux
> (19:07:17) RastaPopoulos: ya pas un truc possible à faire pour tout corriger 
> d'un coup ?
> (19:07:31) RastaPopoulos: là par ex tu fais quoi comme opération quand on te 
> signale un pété ?
> (19:07:44) RastaPopoulos: on peut pas faire la même opération mais en masse 
> sur 100% des dépôts ?

-- 
RastaPopoulos

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


Re: [spip-dev] Accès restreint : protection des documents HS

2020-05-08 Par sujet RastaPopoulos
Le 07/05/2020 à 20:53, nicod_ a écrit :
> Parfois il y a un htaccess à la racine de /IMG (le rewrite ci dessus), 
> parfois dans chaque sous répertoire (deny all), je ne détermine pas bien 
> pourquoi (le code est assez... complexe à suivre).

Le pourquoi normalement c'est :
- si protection des documents le plugin cherche en priorité à poser uniquement 
le htaccess de IMG qui doit tout rediriger vers l'action PHP (plus aucune URL 
de document servie brute)
- mais il teste si ça marche vraiment, en demandant un fichier qui doit 
renvoyer OK seulement si depuis l'action PHP
- si ça n'a PAS marché, alors il pose des htaccess de deny (c'est le core qui 
fait ça) dans tous les sous-dossiers, et il supprime celui de IMG puisque ne 
marche pas

Les raisons pour lesquelles ça ne marche pas peuvent être multiples, par ex :
- des problèmes de droits, et donc le fichier n'est pas posé du tout
- des problèmes de config Apache ou ce genre, et donc les réécritures ne 
fonctionnent pas et donc ça n'appelle pas l'action PHP

Toujours est-il que si les rewrite ne fonctionnent pas et que donc pas d'action 
PHP, alors ce sont les deny dans les sous-dossiers.

Mais si le htaccess IMG a bien fonctionné, alors les vrais URL de documents 
redirigent toujours vers l'action PHP *qu'il y ait la query string avec le hash 
ou pas*.

Le fait qu'il y ait le hash, est une facilité, où l'autorisation (matérialisée 
par le hash) est calculée en amont au moment de #URL_DOCUMENT, et du coup si 
c'est le cas, quand on cherche à accéder au document, il ne vérifie plus 
l'autorisation car déjà ok (sauf si constante).
Mais si on demande les fichiers sans le hash, ça marche aussi : ça passe bien 
par l'action de même, et ça vérifie alors l'autorisation sur le moment de 
l'accès (y compris sans la constante donc).

Les htpasswd par contre sont sans rapport avec les documents et donc les 
htaccess de IMG (lui-même ou sous-dossiers).

-- 
RastaPopoulos

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


Re: [spip-dev] r124584 - _plugins_/saisies/trunk

2020-05-08 Par sujet RastaPopoulos
Le 08/05/2020 à 18:48, JLuc a écrit :
> Mais il me semble qu'il faut === et non ==
> dans strpos($flux['args']['form'], 'configurer_') == 0

Ah merde oui merci c'est ce que je voulais, c'est parce qu'au départ j'avais 
fait l'inverse avec !== qui était bien strict et en inversant la condition j'ai 
mal remis…

-- 
RastaPopoulos

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

Re: [spip-dev] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-05-08 Par sujet RastaPopoulos
Le 08/05/2020 à 15:46, jeanmarie a écrit :
> Si ok, j'ajoute un exemple plus complet d'un fichier "/base/prefixe.php" à 
> partir de https://contrib.spip.net/Champs-Extras-3-API-et-creations pour 
> essayer d'être plus exhaustif. Mais doit-on être complètement exhaustif ici ? 
> Et sinon, où trouver tous les champs et leurs syntaxes propres ?
> 
> Ensuite, il restera à l'articuler avec l'article existant : 
> https://contrib.spip.net/Champs-Extras-3-API-et-creations#Creer-un-plugin-en-utilisant-les-API-de-Champs-Extras

Je pense qu'il faut deux exemples, et que ça suffit. Un "simple", là le premier 
à juste deux champs ça va. Et un deuxième plus complexe avec plus de choses 
utilisées (suffit de copier un de l'ancien article). Ça reste des exemples, le 
but c'est pas forcément d'utiliser 100% de ce qui existe non plus hein… Ya la 
doc pour liste exhaustivement les fonctionnalités pour ça.

Pour l'ancien article, je pense qu'il faut alors supprimer totalement les 
exemples, ne laisser que la documentation donc (la liste des fonctions 
fournies, etc), et faire un lien vers l'article d'exemples.

-- 
RastaPopoulos

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

Re: [spip-dev] Socle Interministériel de Logiciels Libres

2020-05-07 Par sujet RastaPopoulos
Le 07/05/2020 à 16:08, Stephane Santon a écrit :
> N'est-ce pas un référent "agent public de l'état" ??

Ah j'avais compris un truc comme ça moi aussi, que pour proposer, fallait 
plutôt faire partie d'un organisme public, puisque le but c'est de proposer des 
choses vraiment utilisés et suivis

-- 
RastaPopoulos

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


Re: [spip-dev] Ajout en masse à "Des sites sous SPIP" ?

2020-05-07 Par sujet RastaPopoulos
Le 07/05/2020 à 15:04, Bruno Bergot a écrit :
> Si tu penses le faire un jour, il faudra aussi demander l'url du site à 
> retirer sans quoi la personne recevra un lien pour supprimer *toutes* ces 
> signatures :p

Si c'est générique au plugin pétitions, ya pas de distinction par "site", je me 
dis que sur la page sur laquelle on arrive depuis l'email, on a alors la liste 
de ses signatures, avec des cases à cocher, et on dit lesquelles on veut 
supprimer (ya un truc dans le même genre pour les commentaires wordpress, pour 
gérer ses notifications de réponses, même en non inscrit).

(mais bon ouais c'est déjà un hack pour une vraie pétition d'accepter plusieurs 
pour un même email… en vrai pour spip.net, faudrait sûrement migrer ça sur un 
truc dédié)

-- 
RastaPopoulos

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

Re: [spip-dev] Ajout en masse à "Des sites sous SPIP" ?

2020-05-07 Par sujet RastaPopoulos
Le 07/05/2020 à 14:49, Stephane Santon a écrit :
> Pourquoi m'empêcher de retirer moi-même les miens ???
> (pour donner plus de crédibilité à cette liste)

Au passage, ça vaut en général pour le choix technique qui a été fait 
d'utiliser les pétitions non ? Là il se trouve que c'est un hack fait avec ce 
qui existait à l'époque (sémantiquement aucun rapport quoi), mais le fait de 
pouvoir supprimer sa signature, c'est bien un truc qui devrait absolument 
pouvoir se faire dans une pétition.

Normalement on donne son email pour signer, donc ensuite il devrait y avoir un 
formulaire du genre #FORMULAIRE_SUPPRIMER_SIGNATURE où on donne son email 
uniquement, et alors on reçoit un courrier avec une URL ayant un hash de sécu, 
qui amène à une page du site demandant à confirmer la suppression (même 
principe que pour changer son mot de passe).

Quand on signe une pétition c'est pas un blanc-seing, si on s'aperçoit qu'en 
fait on n'est plus d'accord, on doit pouvoir s'enlever.

-- 
RastaPopoulos

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


Re: [spip-dev] Accès restreint : protection des documents HS

2020-05-06 Par sujet RastaPopoulos
Le 06/05/2020 à 20:21, nicod_ a écrit :
> En 3.2 ça crée un htaccess dans IMG :
> 
> RewriteEngine On
> RewriteCond %{QUERY_STRING} ^(\d+/[\da-f]+)$
> RewriteRule ^\w+/.*$ ../spip.php?action=api_docrestreint=%1/$0 
> [skip=100]
> RewriteRule ^\w+/.*$ ../spip.php?action=api_docrestreint=0/0/$0 
> [skip=100]

Moi j'ai bien ces règles (je suis en 3.2), et il les faut absolument à la 
racine de IMG. Pierrox dit que lui ne les a pas, et ça ça peut être un bug.

Ces règles servent justement à ne PAS servir les fichiers directement, mais à 
les faire passer par l'action en paramètre.

Et donc ça teste bien l'autorisation ensuite dans l'action, c'est bien le cas 
sur un de nos sites. (et sans define pour ça à priori)

-- 
RastaPopoulos

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


Re: [spip-dev] Formulaire de configuration d'un plugin : Enregistrer ?

2020-05-05 Par sujet RastaPopoulos
Le 05/05/2020 à 23:30, tcharlss a écrit :
> Je pense qu'il doit lui manquer les lignes 'defaut' => 
> lire_config('monplugin/mavaleur'),

Oui car le mécanisme des #FORMULAIRE_CONFIGURER_XXX va chercher *dans le 
squelette* les "name" de tous les champs pour savoir quoi charger en mémoire 
(ce qui permet de ne pas avoir de charger() mais seulement le squelette seul).

Or avec saisies en PHP, ya pas de squelettes justement. Donc c'est à toi de 
pré-remplir les champs, avec "defaut". Ou bien de faire la fonction charger() 
hein, mais c'est plus compliqué pour rien.

-- 
RastaPopoulos

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


Re: [spip-dev] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-05-05 Par sujet RastaPopoulos
Le 05/05/2020 à 12:52, JLuc a écrit :
> Un référentiel complet ne remplace pas un tutoriel

Tu persistes à parler de choses dont personne ne parle. Depuis le début : le 
morceau pointé CE SONT des tutoriels ! Tu n'arrêtes pas d'argumenter comme s'il 
s'agissait de refuser un tutoriel parce qu'il y aurait un référentiel, alors 
que personne n'a parlé de ça et qu'il n'y a aucun rapport avec ça. On parle de 
tutoriels déjà en place, et d'un ajout de tutoriel supplémentaire, ce qui 
ferait QUATRE tutos pour dire la même chose. Et donc depuis le début je dis que 
si les tutos déjà en place ne sont pas corrects, il faut les corriger, 
améliorer, compléter, ou à l'inverse : simplifier. Ce que jeanmarie a bien 
compris et donc il est parti pour combiner et avoir tout ce qui est nécessaire 
en une fois (du genre un exemple simple + un exemple complexe = 2 et ça 
suffit). Bref depuis le début tu parles de chose qui ne correspondent pas à ce 
dont on parle en face…

La documentation, contrairement à ce que tu disais plutôt, demande encore plus 
de relecture que le code. Le code chez nous ya max 3-4 personnes qui vont le 
voir alors si parfois il est un peu bordélique, c'est un peu embêtant oui mais 
on s'en sort. Mais si la documentation a 15 articles pour dire la même chose, 
là ça touche beaucoup plus de monde. Tout comme le code, il ne s'agit pas du 
tout d'un truc publié qui ne bouge plus ensuite, on peut l'améliorer en 
permanence. Ce qui est le cas ici. Il est bien plus utile d'avoir 2 tutos bien 
faits (un simple, un complexe) en un endroit précis, que d'avoir 15 tutos qui 
disent "un peu pareil mais pas tout à fait", et du coup de pas savoir quoi 
suivre (ce qui était justement un des problèmes de la doc actuelle).

-- 
RastaPopoulos

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

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

2020-05-03 Par sujet RastaPopoulos
Le 03/05/2020 à 15:10, tofulm a écrit :
> Et je ne parle pas des binaires qui sont encore plus obscures ;-)
> 
> Ce n'est que mon avis, et sur nos serveurs, je préfère fermer les portes
> aux plus de monde possible.

Je pige pas cette différence, script, binaire etc. Tout ça ce sont "des 
logiciels". La commande "git", "svn", même "php", "apache", que tu installes 
c'est quoi, c'est pas des binaires peut-être ? Ce sont des logiciels, quelque 
soit la manière dont ils sont codés derrières, en C, en python ou en PHP. Après 
c'est libre ou pas, donc vérifié par d'autres gens ou pas, et donc de confiance 
ou pas. T'installes pas "git", "libreoffice" etc avec un différent pour chaque 
utilisateur, ni même dans le compte d'un group, que je sache. On installe ça 
une fois pour toute pour tout le monde à la fois.
Et le fait que ce soit installé en global ne change absolument rien aux droits 
*au moment de l'exécution*, c'est bien tel user précis qui le lance et ça ne va 
pas au delà de ses droits. Quand tu lances "git" avec un user précis, et qu'il 
essaye de télécharger dans un dossier où il n'a pas le droit, bah ça marche 
pas. Pareil pour spip-cli ou n'importe quoi d'autre.

-- 
RastaPopoulos

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


Re: [spip-dev] r124483 - in _outils_/spip-cli/trunk

2020-05-02 Par sujet RastaPopoulos
Le 02/05/2020 à 22:25, RealET a écrit :
> Attention, quand il y a auto/ il faut aussi pour certains plugins qu'il y ait
> lib/ à la racine

ça crée déjà lib/ depuis… 6 ans :o

-- 
RastaPopoulos

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

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

2020-05-02 Par sujet RastaPopoulos
Le 02/05/2020 à 21:44, tofulm a écrit :
> Sous linux, c'est une très mauvaise habitude que d'utiliser sudo pour
> tous les scripts perso.
> 
> spip-cli, composer, npm, checkout.php, ..., tous vos scripts sh ou php
> ne doivent pas etre installés avec les droits root.

C'est l'inverse de comment fonctionne un système unix justement.

Un système unix c'est foncièrement *multi-utilisateurs* à la base. Et c'est 
évidemment encore plus évident… sur un vrai serveur (au sens le gros truc 
lointain sur internet). Mais ça se voit aussi vite quand on a un ordi pour la 
famille aussi, avec plusieurs comptes dessus.

Donc quand on installe un nouveau logiciel, on l'installe *pour tous les 
utilisateurs*, pas juste pour soi. Sinon c'est anti écologique et surtout anti 
maintenable. L'admin doit l'installer pour tout le monde, c'est la base sur un 
système multi-utilisateurs.

Tout le barda de npm, composer, etc, et ça vaut pour les snaps de merde, c'est 
la mauvaise habitude de penser qu'un système c'est que pour un utilisateur 
unique (un webdev dans son coin).

Bah non, sur nos serveurs on peut avoir plusieurs utilisateurs, et c'est pas à 
chacun d'installer 15 fois le même outil. On installe qu'une seule fois Git que 
je sache. Ça devrait être pareil pour n'importe quel autre outil.

En théorie, on devrait avoir de l'empaquetage pour spip-cli, sauf que ça doit 
pas être comme nos ZIP, il faudrait une routine pour générer un PHAR à chaque 
fois qu'on le fait évoluer. Et donc un fichier unique, à mettre dans les 
binaires globaux, pour tout le monde.

-- 
RastaPopoulos

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

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

2020-05-02 Par sujet RastaPopoulos
Le 02/05/2020 à 15:57, teamspipfact...@gmail.com a écrit :
> Ok je suis null , je cherche donc

il manquait de mettre "sudo" partout, pour faire en super utilisateur puisque 
c'est pas dans ton dossier user, ça pouvait se deviner quand même :)

-- 
RastaPopoulos

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


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

2020-05-02 Par sujet RastaPopoulos
Le 02/05/2020 à 14:01, teamspipfact...@gmail.com a écrit :
> et bien non j'ai droit a
> $ ./spip.sh dl
> 
> [deprecated] Veuillez utiliser les executables SPIP-Cli du répertoire bin.
> #!/usr/bin/env php
> . n’est est pas sur le bon dépôt Git.
> . n’est est pas sur le bon dépôt Git.
> 
> 
> une idée ?

Euh ben t'essayes de télécharger SPIP en étant dans le répertoire où est 
installé spip-cli là… je vois pas comment tu peux espérer que ça puise marcher.

Avant de faire un retour, commence déjà par suivre la doc, pour installer la 
commande dans le path des binaires du sytème (que ce soit en global ou juste 
pour tel utilisateur). Et donc pouvoir utiliser la commande spip n'importe où, 
en allant dans n'importe quel dossier.

-- 
RastaPopoulos

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

Re: [spip-dev] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-05-01 Par sujet RastaPopoulos
Le 01/05/2020 à 11:06, jeanmarie a écrit :
> Alors peut être que ça vaudrait le coup de scinder l'article en 2 et faire un 
> nouvel article avec des exemples concrets pour ne pas noyer encore plus 
> l'existant ?

+1 c'est ce que je disais avec :> - Soit faut carrément tout virer de l'article 
existant, et mettre tous les exemples dans un article dédié (mais 3 max c'est 
déjà largement suffisant pour tout montrer à priori)

Dans l'article de doc de l'API, il faudrait remplacer cette partie par juste 
présenter les 2 ou 3 fonctions à utiliser, et ce qu'elles attendent comme 
params, avec ensuite un lien "Voir des exemples" amenant à l'autre article.

Dans l'article d'exemple, là actuellement on a trois exemples issus de 
l'article actuel + le tien. Je pense que c'est beaucoup trop. Il faudrait donc 
simplifier, remettre au propre, en ne faisant par exemple que deux exemples, un 
très simple avec les choses de base, et un compliqué avec les choses avancées. 
Ça devrait suffire il me semble.

-- 
RastaPopoulos

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


Re: [spip-dev] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-04-30 Par sujet RastaPopoulos
Le 30/04/2020 à 22:46, JLuc a écrit :
> Mais si les critères de contribution devenaient également trop ésotériques 
> pour contrib.spip
> ça va restreindre la participation à SPIP aux seuls détenteurs d'une 
> prétendue orthodoxie spipement correcte
> 
> et ça va serait assez sinistre.

Mais de quoi tu parles *concrètement* à inventer des trucs là ?

C'est assez simple pourtant :
- ya déjà une doc existante qui contient des *exemples concrets* pas du tout 
abstraits ou que sais-je que tu t'imagines tout seul
- la doc proposé par Jean-Marie est un simple exemple concret
- donc si on l'intègre c'est en améliorant l'existant, ya pas à lister 40 
exemples à la fois pour dire 40 fois la même chose juste avec d'autres noms de 
champs…
- là ya déjà 3 exemples, perso je trouve ça déjà trop compliqué (des ajouts sur 
des ajouts), donc on peut même simplifier l'article existant, améliorer c'est 
pas que rajouter hein, en mettant moins d'exemples (même revenir à un seul mais 
plus complet ?)

On parle pas de PDF qu'on peut pas modifier là… on parle d'un site en SPIP dans 
lequel on peut continuer d'éditer et améliorer les articles existants. Le but 
c'est pas d'accumuler des couches et des couches similaires, on ajoute un 
article s'il dit vraiment un nouveau truc différent à priori.

-- 
RastaPopoulos

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

Re: [spip-dev] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-04-30 Par sujet RastaPopoulos
Le 30/04/2020 à 20:14, JLuc a écrit :
> Peut être ça doublonne certaines ou toutes les informations techniques, mais 
> ça a l'air beaucoup plus simple.
> Et cette simplicité disparaîtrait si on ajoutait encore à la doc déjà 
> présente.

Informations techniques ? Euh le lien avec ancre que j'ai pointé c'est 
rigoureusement pile la même chose : trois exemples concrets de comment déclarer 
des champs en PHP et comment lancer la fonction d'upgrade. On peut 
difficilement faire plus la même chose c'est la fonction 
XXX_declarer_champs_extras() avec des exemples de champs dedans, puis la 
fonction XXX_upgrade() avec le lancement des fonctions…

Ya déjà 3 exemples différents dans l'article… je vois mal l'intérêt d'en 
rajouter un 4ème pour dire encore pareil.
- Soit faut mettre à jour l'article existant pour corriger/améliorer avec tel 
ou tel mini point qui manquerait.
- Soit faut carrément tout virer de l'article existant, et mettre tous les 
exemples dans un article dédié (mais 3 max c'est déjà largement suffisant pour 
tout montrer à priori)

-- 
RastaPopoulos

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

Re: [spip-dev] Tuto "Créer des champs extras depuis un plugin perso avec l’aide de Saisies"

2020-04-30 Par sujet RastaPopoulos
Bé ya déjà tout ici dans ce chapitre non ?
https://contrib.spip.net/Champs-Extras-3-API-et-creations#Creer-un-plugin-en-utilisant-les-API-de-Champs-Extras

S'il manque quelque chose, je dirais plus d'ajouter ce qui manque à cet endroit 
plutôt que de refaire un autre article complet qui va doublonner 95% de la même 
chose.

-- 
RastaPopoulos

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


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

2020-04-29 Par sujet RastaPopoulos

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)

-- 
RastaPopoulos

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

Re: [spip-dev] Demande de passage d'un plugin sous GIT

2020-04-27 Par sujet RastaPopoulos
Le 27/04/2020 à 12:54, teamspipfact...@gmail.com a écrit :
> je me connecte sur https://git.spip.net/ pour récupéré le plugin via le zip 
> et le transféré sur mon hébergement pour avoir le plugin en GIT
> et pouvoir faire la mise a jour avec

Mais… non… récupérer le zip généré ne fait absolument que tu as le plugin "en 
Git". Tu as seulement le paquet généré, ce n'est pas un clonage du dépôt Git, 
pour pouvoir mettre à jour etc ensuite. Tout comme les zip généré par trac, ou 
par smart-paquet ne te donnait absolument pas un plugin "en SVN" du tout.

Pour avoir les plugins "en Git", il faut les récupérer… en Git.

-- 
RastaPopoulos

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

Re: [spip-dev] Demande de passage d'un plugin sous GIT

2020-04-27 Par sujet RastaPopoulos
Le 27/04/2020 à 12:24, teamspipfact...@gmail.com a écrit :
> pas de lien vers GIT, je cherche donc ...

mais tu cherches quoi ? Contrib n'a jamais servi à dire où est géré le code 
(les gens qui documentent pouvaient ajouter un flux RSS du trac mais c'est que 
pour SVN donc, ça sert pas à dire spécialement où est le code). Le répertoire 
officiel des plugins avec pour chacun où il est géré, c'est toujours 
plugins.spip.net normalement, tant qu'il n'est pas encore fusionné avec Contrib 
(ça va arriver).

Par contre pour Jeux, ya clairement un soucis :
https://plugins.spip.net/jeux

Ça dit pas où est le code, et surtout ya pas les dernières versions, alors que 
pourtant dans le Git, il y a bien les bons tags des branches 2.X et 3.X
https://git.spip.net/spip-contrib-extensions/jeux/releases

Un soucis avec le débardeur ?

-- 
RastaPopoulos

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


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

2020-04-27 Par sujet RastaPopoulos
Le 27/04/2020 à 10:45, Matthieu Marcillaud a écrit :
> Nope, pas moyen pour le moment.
> Cf le succinct https://core.spip.net/issues/3711

Elle est cool cette proposition ! :p

(mais j'y pige pas grand chose dans le compilateur donc je sais pas où ni 
comment ça devrait se coder)

-- 
RastaPopoulos

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


Re: [spip-dev] Bug : tmp/cache/contextes jamais nettoyé ?=et donc =?utf-8?Q?planté

2020-04-22 Par sujet RastaPopoulos
Le 22/04/2020 à 10:51, Cerdic a écrit :
> Same player, shoot again https://core.spip.net/issues/3239

Haha effectivement, et c'était probablement pour le même site. À l'époque 
c'était déjà 6Go, et là maintenant 47… arg

D'après marcimat, ça ne devrait pas être utilisé en SPIP 3. Le comportement 
intermédiaire qu'il décrit, c'est ce que fait déjà SPIP 3 quand il n'y a PAS la 
constante ou c'est un truc perso ? Mais dans ce cas, si ça ne doit pas être 
utilisé, à partir de 3, est-ce que ça devrait pas ne plus rien faire, et alors 
la déprécier et ne plus la documenter ?

Là en attendant je peux vider le dossier moi-même quand même ? Car là tout est 
bloqué comme il y a 6 ans.

Pour l'instant je ne vois pas quoi changer aux squelettes de ce site, ça reste 
des choses assez basiques, des listes, des filtres, mais avec Accès Restreint 
(alors est-ce que certaines inclusions reçoivent des milliers d'ID en params ? 
ça ne me dit vraiment rien mais je vais fouiller…)

-- 
RastaPopoulos

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


[spip-dev] Bug : tmp/cache/contextes jamais nettoyé et donc planté

2020-04-21 Par sujet RastaPopoulos

Ok alors j'ai un répertoire contextes/ de… QUARANTE SEPT GIGAS !

J'ai évidemment utilisé _CACHE_CONTEXTES_AJAX comme le propose la doc. Et bien 
parce que sinon plein d'URL ne marchent juste pas.

C'est un site "normal" bien qu'avec pas mal de contenus. Toutes les listes sont 
en ajax, pour la pagination et parfois pour des filtres (donc combinaison de 
possibilités).

Sauf que ça ne "tourne" jamais comme le fait généralement un cache, càd que ya 
une limite et que les vieux trucs sont supprimés et des nouveaux apparaissent. 
Nulle part ce n'est indiqué que ce répertoire va grossir à l'infini sans jamais 
s'arrêter.

Du coup, c'est pas juste que c'est atrocement énorme (47Go pour un cache d'URL… 
wtf), mais ça plante, ya trop de fichiers, ça veut plus écrire dans le 
répertoire.

C'est pas un sacré gros bug ?

-- 
RastaPopoulos

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

Re: [spip-dev] SVN ou GIT ; mise a jour des plugins

2020-04-21 Par sujet RastaPopoulos
Le 21/04/2020 à 11:47, teamspipfact...@gmail.com a écrit :
> (faut il abandonné définitivement SVN ?)

Si tu peux y réfléchir dès maintenant : oui.
SVN va rester encore, puis en lecture seulement, mais ça va vraiment finir par 
disparaitre, et certains plugins sont désormais ajoutés directement en Git.

Pour Git, utilise par ex le script checkout qui est dans l'orga outils.
Mais je ne désespère pas d'intégrer tout ça à spip-cli et que ce soit ça qui 
soit maintenu… :)

-- 
RastaPopoulos

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

Re: [spip-dev] HTML5up hyperspace : deux prefix différents, donc deux plugins différents

2020-04-15 Par sujet RastaPopoulos
Le 15/04/2020 à 13:58, Eric Lupinacci a écrit :
> Si tout est incompatible on peut dire que c’est bien deux plugins différents.

Moi pige pas cette méthode si c'est à suivre à l'infini et pas un truc 
temporaire. Ça fait des années maintenant qu'on dit qu'on doit aller dans le 
sens de Semver, et que dès que possible on doit suivre les méthodes employées 
partout ailleurs.

Or le principe c'est que le numéro X sert *très précisément* à cela : dire que 
cette version majeure n'est PAS assurée compatible avec la précédente.

Et nous on doit bidouiller à dire que c'est des projets différents uniquement 
parce que notre outil en interne ne gère pas bien Semver depuis toutes ces 
années où on dit pourtant qu'on doit le suivre. C'est-à-dire que notre 
interface (SVP surtout) ne bloque pas par défaut le saut à la version majeure 
suivante, et ne prévient pas de manière hyper claire que cette version suivante 
est un numéro majeur différent ("Attention" etc). Ce qui aboutit à l'exemple 
donné pour spipr avec les gens en galère. Il me semble que la solution pérenne 
c'est bien de suivre Semver, et faire un ticket SVP pour décrire ça et prévoir 
de modifier son ergonomie.

En fait il y a un ticket qui est déjà ça en gros :
https://core.spip.net/issues/3017

-- 
RastaPopoulos

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

Re: [spip-dev] Contrib et fichiers des plugins

2020-04-12 Par sujet RastaPopoulos
Le 12/04/2020 à 19:45, Bruno Bergot a écrit :
> À froid je n'ai pas d'idée concrète pour améliorer ça, mais peut-être faut il 
> chercher directement dans les paquets en fonction de l'url de doc (qui est 
> celle de l'article en cours), sauf que très souvent les paquets référencent 
> l'adresse en mode lien court, etc.

Tout à fait d'accord avec ce point car le lien on l'a, chaque paquet.xml 
référence bien l'article le plus pertinent pour sa version précise, donc on 
doit être capable d'afficher les infos de cette branche en question, et non du 
plugin général.

-- 
RastaPopoulos

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


Re: [spip-dev] Contrib et fichiers des plugins

2020-04-12 Par sujet RastaPopoulos
Le 12/04/2020 à 16:53, Maïeul Rouquette a écrit :
> Bref, on n'est pas encore sur la fusion plugins/contrib, mais on a déjà des 
> choses plus cohérentes niveau contrib.

Super, merci !

-- 
RastaPopoulos

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


Re: [spip-dev] Tag sur git mais pas sur gitea

2020-04-08 Par sujet RastaPopoulos
Le 09/04/2020 à 00:06, RastaPopoulos a écrit :
> Mais pas Gitea à priori.

Ah si effectivement, dans les autres projets, les simples tags apparaissent 
aussi dans release… Bon bah faut demander à azerttyu plutôt alors :)

-- 
RastaPopoulos

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

Re: [spip-dev] Tag sur git mais pas sur gitea

2020-04-08 Par sujet RastaPopoulos
Le 08/04/2020 à 23:52, Maïeul Rouquette a écrit :
> hum, mais il est pas ici
> 
> https://git.spip.net/spip-contrib-extensions/formidable_participation/releases

On a déjà dit dans l'autre fil que le concept de "release" n'avait aucun 
rapport avec Git, c'est propre à chaque forge. Github génère automatiquement 
une release à chaque tag, de ce que quelqu'un avait dit il me semble, et donc 
ya plus qu'à rajouter un texte de présentation (souvent le changelog 
synthétique). Mais pas Gitea à priori. Et j'ai l'impression que quand on est 
pas admin on peut pas le faire (moi je vois aucun bouton pour ça avec mon 
compte), tout comme la personnalisation des étiquettes de tickets et des jalons…

Mais ya pas à le faire puisqu'on n'utilise pas ce concept. Et cet onglet 
pourrait être enlevé à mon avis car c'est pas avec ça qu'on distribue et 
communique, mais avec le débardeur qui fait les paquets et les envoie sur le 
site grand public. Sur la forge les tags seuls suffisent. Après je sais pas 
pourquoi là il ne l'a pas encore pris en compte…

-- 
RastaPopoulos

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

Re: [spip-dev] [Spip-zone-commit] r122733 - _squelettes_/escal/trunk

2020-04-08 Par sujet RastaPopoulos
Le 08/04/2020 à 09:43, Cerdic a écrit :
> soit carrément dans une rubrique dédiée à git dans « Comment contribuer » sur 
> spip.net non https://www.spip.net/fr_rubrique205.html ?

+1 pour ça, c'est un truc global à la communauté (ya des choses à dire sur 
comment contribuer au noyau, et comment contribuer aux plugins), donc c'est 
bien sur le site central

-- 
RastaPopoulos

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


Re: [spip-dev] [Spip-zone-commit] r124083 - in _galaxie_/plugins-spip-net/trunk

2020-04-07 Par sujet RastaPopoulos
Le 07/04/2020 à 19:01, teamspipfact...@gmail.com a écrit :
> merci pour l'éclairage
> car je comprend de moins en moins la structure de la galaxie spip (l'age sans 
> doute)

Mais c'est quoi le problème ? Ça fait des années qu'il y a des plugins 
"externals" que des gens ont choisi de développer totalement ailleurs que sur 
les outils de la communauté, mais qui sont quand même référencés (comme étant 
clairement externals) dans le répertoire des plugins. Donc bah oui ya des 
plugins qui sont sur github, c'est pas nouveau, du tout.

-- 
RastaPopoulos

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


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

2020-04-07 Par sujet RastaPopoulos
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).

-- 
RastaPopoulos

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


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

2020-04-06 Par sujet RastaPopoulos
Le 06/04/2020 à 23:33, Charles Razack a écrit :
> 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.

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

-- 
RastaPopoulos

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


Re: [spip-dev] Bug dernière version de saisies 4.0

2020-04-03 Par sujet RastaPopoulos
Le 03/04/2020 à 17:54, CSI a écrit :
> Ce que trouve bizarre c'est que sur l'autre site avec lequel je
> comparais on ne propose pas de mise à jour de Saisies en 4.0.0 ...

Cf le fil de Maieul "Débardeur migration et tag". Cette version de Saisies 
n'existe pas (et date de 2018), suite à un tag malencontreusement posé et le 
nouveau système de paquets (débardeur) qui génère les ZIP à partir des tags.

Il faut supprimer cette version et mettre la vraie dernière.

-- 
RastaPopoulos

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


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

2020-03-31 Par sujet RastaPopoulos
Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :
> Et pour celles et ceux qui ont oublié de tagguer correctement leur
> projet. On a un outil qui permet de détecter tous les changements de
> version écrits dans paquet et plugin.xml et d'en faire de beaux tags
> git.

C'est justement l'exemple que donne Éric pour Formidable et Saisies, et qu'il 
est conseillé de ne PAS faire.

-- 
RastaPopoulos

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


Re: [spip-dev] API Objet et id_parent

2020-03-31 Par sujet RastaPopoulos
Le 31/03/2020 à 15:26, Matthieu Marcillaud a écrit :
> Et à ce moment là tu peux dire le parent est :
> 
> id_parent > 0 => article / id_parent
> id_parent = 0 => rubrique / id_rubrique

Mais c'est ce que fait l'API parent depuis le début ! cf tous mes liens 
d'exemples précédent…

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

Je ne vois même pas ce que ça voudrait dire, et pour moi ça n'a aucun sens sauf 
à parler de poly-hiérarchie justement, si yen a plusieurs. Mais l'API parent se 
contente de gérer uniquement la parenté *directe/principale*, comme déjà dit. 
Et il n'y a donc qu'un unique parent possible à un instant T pour un contenu 
précis.

-- 
RastaPopoulos

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

Re: [spip-dev] API Objet et id_parent

2020-03-31 Par sujet RastaPopoulos
Le 31/03/2020 à 14:41, Eric Lupinacci a écrit :
> Je ne suis pas du tout d'accord.
> On ne pas considérer qu'un lien de parenté qui définit une arborescence est 
> un cas d'usage d'un lien d'appartenance qu'on souhaite assimiler à une 
> parenté sur certaines actions.

Je n'ai pas vraiment compris cette phrase. :p

Mais arborescence, hiérarchie, appartenance, parenté, tout ça ce sont des 
*synonymes*. La différence est tellement infime et subjective, que ce serait 
beaucoup trop confus pour les utilisateurs finaux de leur dire "l'un veut dire 
ça mais l'autre c'est plutôt ça", alors que dans le langage courant, suivant 
les contextes, ça veut à peu près dire la même chose. Le fait d'avoir un parent 
principal crée une hiérarchie, une arbo.

> Mais un lien d'appartenance ne crée pas de hiérarchie (ou très plate, donc 
> sans intérêt).

Si.

Qu'est-ce que t'en sais que l'objet enfant n'est pas lui-même possiblement 
parent d'autres enfants ?

Rien qu'avec les objets courants avant même "declarerparent" on a : un 
événement est dans un article qui est dans une rubrique qui peut être dans une 
rubrique. TOUT ça est une hiérarchie.

> Et donc si mon objet hiérarchique, comme une rubrique, appartient à un objet 
> X, je fais comment pour distinguer le père et le conteneur (au sens de 
> l'appartenance) ?

Ça n'existe juste pas.
Toute l'API "parent" ne travaille que sur la parenté *directe* ou *principal* = 
un contenu ne peut avoir qu'un seul parent principal.

En revanche il peut y avoir plusieurs *méthodes* de recherche du parent pour un 
même objet (objet-id_objet ET id_parent). Mais pour tel contenu précis, lui n'a 
qu'un parent principal, celui prioritairement trouvé. Et c'est ce que fait 
l'API parent, on peut déclarer plusieurs méthodes à la fois, c'est le cas pour 
les forums.
https://git.spip.net/spip-contrib-extensions/declarerparent/src/branch/master/declarerparent_pipelines.php#L28

Pour une rubrique, c'est une rubrique (ou rien et donc secteur).
Pour un article c'est une rubrique.
Pour un événement c'est un article.
https://git.spip.net/spip-contrib-extensions/agenda/src/branch/master/base/agenda_evenements.php#L146
Pour un forum c'est SOIT n'importe quel objet SOIT un autre forum (et ça ne 
PEUT PAS être les deux à la fois, il n'y a qu'un seul parent direct).
Pareil pour l'objet "chapitre" du plugin éponyme qui a une structure similaire 
aux forums (un chapitre est soit à la racine d'un autre objet, un article, un 
devis, que sais-je, soit un sous-chapitre d'un chapitre, mais ça ne peut pas 
être les deux, il n'y a qu'un parent principal).
https://git.spip.net/spip-contrib-extensions/chapitres/src/branch/master/base/chapitres.php#L99

> En tout cas, je ne pense pas que ce soit aussi limpide que tu le prétends.
Moi si. :p

-- 
RastaPopoulos

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


Re: [spip-dev] API Objet et id_parent

2020-03-31 Par sujet RastaPopoulos
Le 31/03/2020 à 13:47, Eric Lupinacci a écrit :
> Oui soit.
> Mais je ne vois pas trop l'intérêt ni la raison de grouper les deux 
> problématiques liées à la "parenté".

> On a d'un coté un objet arborescent qui utilise id_parent pour structurer sa 
> hiérarchie propre.
> Et de l'autre des objets différents qui sont regroupés dans un même objet de 
> regroupement qu'on appelle "parent" ce qui permettrait de définir une 
> "hiérarchie" entre ces objets et l'objet parent (à un niveau donc ?), un peu 
> comme dans le plan du site.

Il n'y a pas de "côtés". Le fait d'avoir *son propre même objet* comme parent 
possible, est uniquement un cas particulier du fait d'avoir un parent. Voilà 
pourquoi c'est la même chose, ça va ensemble, à gérer dans la même API, les 
mêmes fonctions. Et comme dit dans le fil (et c'est ce que fait déjà toute 
l'implémentation dans declarerparent), il n'y a pas forcément à déclarer 
explicitement dans la définition de l'objet, pour les cas simples, ça gère déjà 
magiquement, dont le fait d'avoir un champ "id_parent".
https://git.spip.net/spip-contrib-extensions/declarerparent/src/branch/master/base/objets_parents.php#L181

> Dans le deuxième cas c'est une nouvelle déclaration dont je ne vois l'utilité 
> que pour la boucle hiérarchie (mais j'ai pas creusé) mais qui est bien 
> différente du premier cas. On pourrait très bien avoir un objet arborescent 
> inclus dans un objet d'un autre type.

Que ce soit soi-même (le même objet) ou un autre objet, les utilisations sont 
les mêmes : gérer le champ pour dire quel est le parent durant l'édition, les 
hiérarchies, les URL, les duplications, et plein d'autres.

-- 
RastaPopoulos

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


Re: [spip-dev] API Objet et id_parent

2020-03-31 Par sujet RastaPopoulos
Le 31/03/2020 à 10:38, Matthieu Marcillaud a écrit :
> Alors c’est tout l’intérêt de la déclaration de parent qui a été ajouté dans 
> la déclaration d’objet éditorial.
> https://core.spip.net/issues/3844

Et pour le cas simple sans déclaration, juste parce qu'on détecte qu'il y a un 
champ "id_parent", j'avais commencé un diff :
https://core.spip.net/issues/3844#note-16

Mais comme expliqué, j'ai pas commité car c'était mieux de réfléchir à long 
terme avec la déclaration complète. Déclaration et API qui ont été implémentées 
entièrement dans le plugin declarerparent, et qui permettent de connaitre dans 
les deux sens les parents et les enfants. D'après moi à intégrer au core 
évidemment. :)

-- 
RastaPopoulos

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

Re: [spip-dev] Accés aux logos

2020-03-26 Par sujet RastaPopoulos
Le 26/03/2020 à 16:24, JLuc a écrit :
> Alors ce n'est plus chercher_log() ?

chercher_logo() ça cherche uniquement les "vrais" logos anciens modèles (qui 
doivent changer), quand on a Rôles de documents par exemple (mais ça peut être 
d'autres plugins comme logo_auto aussi ou encore dans Sélections éditoriales) 
et bien ça ne renvoie pas le logo réellement utilisé.

c'est quete_logo_objet() qui fait ça bien et propre et générique, et lui-même 
appelle chercher_logo() aussi

-- 
RastaPopoulos

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


Re: [spip-dev] Accés aux logos

2020-03-26 Par sujet RastaPopoulos
Le 26/03/2020 à 15:00, JLuc a écrit :
> Apparemment, logo_auto n'utilise pas l'API des logos mais interroge 
> directement la BDD à coups de sql_fetsel

Bé pour faire ce qu'il veut lui (trouver d'autres types de logo) mais non 
justement il s'inscrit dans le pipeline "quete_logo_objet" = il utilise l'API
qui est dans la fonction du même nom, dans public/quete.php

Et c'est quete_logo_objet() qu'il faut utiliser pour vraiment avoir le logo 
*d'où qu'il vienne* (les anciens logos ou tout autre source avec le pipeline)

-- 
RastaPopoulos

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


Re: [spip-dev] Accés aux logos

2020-03-26 Par sujet RastaPopoulos
Le 26/03/2020 à 10:48, Bruno Bergot a écrit :
> Ça n'est plus le cas en 3.3 depuis que les logos sont des documents.

et par ailleurs même avant, yavait une fonction pour trouver un logo d'un objet 
car suivant le raccourci de l'objet (parfois le nom entier, parfois juste 
"art", ça dépend des déclarations) et suivant l'extension (ça peut être jpg, 
png, gif…), donc faut surtout pas chercher un fichier soi-même, mais utiliser 
l'API (cf le plugin logo_auto)

-- 
RastaPopoulos

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

Re: [spip-dev] [Mailshot] Envoi des newsletters dépubliées

2020-03-25 Par sujet RastaPopoulos
Le 25/03/2020 à 10:42, Jean Marie Grall a écrit :
> Est-ce qu'il ne serait pas logique d'annuler un envoi si la newsletter n'est 
> pas publiée ? Je vois bien le principe coté système, mais côté utilisateur, 
> c'est vrai que c'est contre-intuitif.

Dit comme ça oui… ça me parait assez logique de remettre à zéro les 
programmations liées si on dépublie une lettre

-- 
RastaPopoulos

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

Re: [spip-dev] [Spip-zone-commit] r118288 - in _plugins_/agenda/trunk

2020-03-19 Par sujet RastaPopoulos
Le 19/03/2020 à 17:32, Maïeul Rouquette a écrit :
> Je ne suis pas contre sortir dans un plugin à part. Même si je trouve 
> qu'actuellement il y a suffisament de warning pour que les gens le fassent en 
> conscience.

Pour moi ça warn pas grand chose. Déjà 1) par défaut les événements ont des 
pages dédiés, donc déjà par défaut cette option qui est *avant* le choix 
d'avoir page ou pas, ça va de base provoquer du caca, et 2) signaler aux gens 
que ça supprime définitivement, ça leur apprend pas spécialement que ça va 
causer des soucis de référencement, de liens cassés, etc, c'est tout ça qu'il 
faudrait dire, mais si une option a besoin d'un paragraphe de 5 lignes pour 
bien comprendre ce que ça va provoquer, c'est soit qu'il y a un soucis et que 
ça devrait pas être proposé par défaut mais dans un plugin dédié, soit à la 
limite ça devrait être tout tout tout en bas dans un cadre "warning" à part 
(comme les blocs de suppression de dépôt ou de compte sur github etc).

-- 
RastaPopoulos

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


Re: [spip-dev] [Spip-zone-commit] r118288 - in _plugins_/agenda/trunk

2020-03-19 Par sujet RastaPopoulos
Le 07/02/2020 à 18:28, Cerdic a écrit :
> Si on s’y retrouve pas faut peut-être chercher comment améliorer ça non ?
> 
> Le principe de SPIP c’est au contraire qu’on efface rien. 
> Effacer un événement publié c’est créer une page 404.
> 
> Là c’est niet total, danger public, perte de contenu...
> Au pire tu mettras ça dans un plugin séparé si vraiment ça te parait une 
> bonne idée…

+1, par défaut on doit rien effacer, ça fait des 404, c'est le mal absolu ! Ça 
doit surtout pas être fourni par défaut mais dans un plugin dédié uniquement 
pour les cas méga rares qui en aurait besoin.

Mais du coup ça n'a pas été revert ça non ? Là j'ai le master git et il y a 
toujours l'option.

-- 
RastaPopoulos

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


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

2020-03-17 Par sujet RastaPopoulos
Le 17/03/2020 à 21:30, nicod_ a écrit :
> Est ce que tout le monde reçoit bien les notifications de PR ?

Je n'ai strictement rien reçu, et comme dit tout à l'heure sur IRC, je n'étais 
PAS abonné ("suivre") au dépôt principal du noyau (spip/spip), que j'ai ajouté 
manuellement tout à l'heure, et pas non plus à tous les dist (pas fait du coup).

La modif de Camille à priori c'est pour les *nouveaux* dépôts, quand on en crée 
un alors tous les gens de l'équipe sont automatiquement ajoutés en suivi 
dessus. Mais par contre pour tous les dépôts déjà là, ça n'a pas été le cas (et 
il ne faut pas pour les contribs, mais pour noyau et dist m'est-avis qu'on 
devrait).

-- 
RastaPopoulos

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


[spip-dev] Accès Restreint des documents : test lourd juste pour générer les URL

2020-03-17 Par sujet RastaPopoulos

Hello les gens et Cédric surtout,
on a un site de magazine, avec beaucoup d'accès restreint, beaucoup de 
rubriques configurées, des milliers d'articles, etc. Et des documents joints 
doivent absolument être pour les abonnées uniquement, comme des émissions en 
mp3 par exemple, donc sur ce site la protection des documents est activée.

Tout cela génère des requêtes très (TRÈS) lourdes, on le sait bien.

Sauf que… normalement, nous contrôlons précisément quand sont faits ces tests 
car on a activé la constante AR_TOUJOURS_TOUT_VOIR. Ce qui signifie 
qu'absolument AUCUNE boucle ne génère ces requêtes lourdes. Normalement pour 
les documents, le test ne devrait se faire que quand on cherche à accéder au 
vrai document orginal, quand on va sur son URL dans IMG/, car là ça va dans 
l'action d'accès au doc et ça teste l'autorisation. Et ça c'est ok, car il n'y 
a pas beaucoup de demande d'accès aux documents originaux.

Sauf que… on s'est aperçu que tu avais mis un appel à l'autorisation, et donc 
un lancement des requêtes énormes, au tout début de la fonction de génération 
des URL de documents. Du coup ça lance des requêtes énormes pour CHAQUE simple 
lien de document dans les pages, dès qu'on a #URL_DOCUMENT, et ça yen a des 
paquets sur chaque page !

À cause de cela, le site a complètement planté (slow queries en folie etc) 
après avoir dépassé un seuil de rubriques restreintes ajoutées. En virant ce 
test (que chez nous donc pour l'instant) tout est revenu comme il faut.

Alors questions : 
- Pourquoi tester l'autorisation de voir un document pour juste générer son URL 
? On s'en fiche si on a le droit de le voir ou pas, ça change rien que le 
document a bien une #URL_DOCUMENT, c'est quand on demande à y accéder pour de 
vrai que ça suffit de tester si on a le droit.
- Est-ce que ça peut se virer ? Ou le rendre configurable (ne serait-ce qu'avec 
une constante) ?

-- 
RastaPopoulos

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

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

2020-03-17 Par sujet RastaPopoulos
Le 17/03/2020 à 08:59, Stephane Santon a écrit :
> Effectivement, le code source a bien conservé l'espace, et il n'est pas 
> affiché dans Firefox.

Bé oui, c'est la norme HTML elle-même, donc c'est pareil partout. Absolument 
aucun espace n'est pris en compte en dehors d'entre deux mots (ou blocs 
inline), si tu mets 40 espaces et 20 passages à la ligne, ça va pas afficher 
des passages à la ligne. Les navigateurs n'affichent que les espaces entre les 
mots, et les marges des blocs, c'est tout. La seule exception est la balise 
 (ou le style CSS associé comme a dit Charles) dont le but même est 
d'afficher le texte tel qu'écrit.
https://developer.mozilla.org/fr/docs/Web/HTML/Element/pre

-- 
RastaPopoulos

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


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

2020-03-11 Par sujet RastaPopoulos
Le 11/03/2020 à 01:36, nicod_ a écrit :
> Mais si quelqu'un a un peu d'énergie pour faire des trucs, les encouragements 
> c'est un peu mieux que "c'est pas facile, tu vas pas y arriver".

Ce n'est pas ça qui a été dit, c'est plutôt il me semble : refaire un truc from 
scratch à zéro qui va vraiment tenir et être maintenable, c'est pas forcément 
plus facile et rapide que partir de Satis, qui est testé et éprouvé par des 
centaines/milliers de gens et donc dont on sait que ça tient le choc.

-- 
RastaPopoulos

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


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

2020-03-07 Par sujet RastaPopoulos
> (et comme on l'a déjà dit, ça n'empêche pas de l'avoir dans son orga et de ne 
> fonctionner que par PR)

?

Le fait de l'avoir dans la forge commune n'est pas que pour les droits (cf 
cette parenthèse), c'est aussi faciliter le suivi du projet, être prévenu quand 
il y a des commits, des tickets : tout événement de la vie du projet, sans 
devoir aller s'inscrire sur plein d'endroits différents. Donc moi ça ne me 
choque pas que pour avoir accès aux facilités automatiques, c'est pour celleux 
qui jouent le jeu d'être à l'endroit que la communauté a décidé pour l'instant.

-- 
RastaPopoulos

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


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

2020-03-06 Par sujet RastaPopoulos
Le 06/03/2020 à 20:21, Maïeul Rouquette a écrit :
> Si je comprend bien ta perspective, toi tu envisage une amélioration 
> drastique du système de distribution/d'install de paquet pour une future 
> version de SPIP. Avec possibilité de choisir précisement la version du plugin 
> qu'on veut installer, et en s'appuyant sur composer.

Oui mais non. Il dit qu'il l'envisage lointainement pour le futur mais ce qu'il 
a commencé à développer correspond uniquement à ce que tu cherches à faire toi, 
càd générer le même XML qu'utilisé actuellement, et lister les infos et les ZIP 
liés, etc. Mais il dit que si on développe ça en partant d'un outil qui sait 
déjà gérer composer, et bien par la suite, on aura pas à de nouveau tout 
refaire à zéro, la majeure partie sera déjà là. Alors que si on développe un 
nouveau smart_paquet ok pour git, ça restera un projet perso que pour notre cas 
précis, et plus tard on devra encore tout refaire.

Ça ne veut pas dire que c'est pas ça qu'il faut faire, cela dépend de la 
balance entre les temps de développement. Si partir de Satis est moins long, ou 
aussi long, ou même plus long mais de pas trop, alors il vaut mieux partir de 
Satis. Si en revanche refaire un smart_paquet one shot est vraiment vraiment 
beaucoup plus rapide, alors c'est sûrement mieux de le faire (mais faut avoir 
en tête qu'il faut le maintenir, gérer ses perfs, etc).

-- 
RastaPopoulos

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


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

2020-03-06 Par sujet RastaPopoulos
Le 06/03/2020 à 18:59, Matthieu Marcillaud a écrit :
> - ça limite à Gitea, alors que d’autres projets peuvent être ailleurs, de 
> façon temporaire ou non. Et je trouve ça assez dommage de s’en priver ; non ?

Yo, 
sans préjuger de l'infrastructure à utiliser (et je suis justement plutôt 
d'accord avec toi, si c'est possible, d'utiliser un truc qui obligera pas à 
tout refaire à zéro si on passe à composer un jour), pour ce point cité, je ne 
suis pas forcément d'accord.

Personnellement je suis d'avis que si on veut profiter des facilités de la 
communauté, des outils mutualisés, et bien on doit alors avoir son projet dans 
l'outil communautaire démocratique (et comme on l'a déjà dit, ça n'empêche pas 
de l'avoir dans on orga et de ne fonctionner que par PR. Si on développe 
vraiment dans son coin, et bien on se débrouille manuellement pour le reste. 
Après si sans des milliards de développements en plus, l'outil sait gérer les 
trucs externes, c'est à reconsidérer, effectivement, pas une position fixe… 
Mais quand même ça m'embête politiquement qu'on développe ailleurs en mode mon 
ptit projet perso dont je suis le patron, et qu'on profite quand même de toutes 
les largesses automatiques de la communauté.

-- 
RastaPopoulos

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

  1   2   3   4   5   6   7   8   9   10   >