Bonjour,
Je viens de tomber par hasard sur ce plugin qui est présenté comme un add-on de IEConfig pour les metas des plugins, Plugin SEO, GIS 4, Modèles Facebook, Autorité, paniers et commandes, Bank et les objets des plugins selections éditoriales, formidables…
Je ne comprends pas du tout pourquoi inclure cela dans un plugin unique alors que la logique de IEConfig est justement que chaque plugin intègre dans un formulaire unique géré par IEConfig ses propres exports via un pipeline.
Ouais.
--
RastaPopoulos
Euh quoi ouais ? J’ai gouré ?
Le 09/01/2019 à 15:30, Eric Lupinacci a écrit :
Euh quoi ouais ? J'ai gouré ?
++
EricLe mer. 9 janv. 2019 à 15:24, RastaPopoulos <rastapopoulos@spip.org <mailto:rastapopoulos@spip.org>> a écrit :
Ouais.
-- RastaPopoulos
----
spip-zone@rezo.net <mailto:spip-zone@rezo.net> -
https://listes.rezo.net/mailman/listinfo/spip-zone----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Ce plugin est la parceque personne n'as souhaité que ce soit intégré aux plugins cités
j'ai abordé le sujet maintes fois, je trimbalais ça depuis x années dans ma toolbox , etc … ça a fini comme ça pour être dispo aux autres sans avoir trouvé de consensus ^^ et avoir déjà pas mal alimenté de discussions pourtant
--
Bonne journée
Arnaud B. (Mist. GraphX)
Hello,
Je comprends.
Ce plugin est la parceque personne n’as souhaité que ce soit intégré aux
plugins cités
Là je ne comprends pas.
Ce plugin est intégré à tous les plugins-dist.
On peut avoir des griefs sur pourquoi, comment et ça serait mieux si… mais toujours est-il que cela apporte une solution à un besoin réel.
Donc c’est quoi cette histoire de consensus ?
L’ajout de cette fonctionnalité dans ces plugins est indolore car elle ne perturbe pas le fonctionnement du plugin et voire inodore si on active pas IEconfig.
j’ai abordé le sujet maintes fois, je trimbalais ça depuis x années dans
ma toolbox , etc … ça a fini comme ça pour être dispo aux autres sans
avoir trouvé de consensus ^^ et avoir déjà pas mal alimenté de
discussions pourtant
Ben donc je maintiens ce que j’ai dit.
C’est une erreur et on devrait inclure cela dans les plugins.
Si un jour on se décide à mettre en place un mécanisme du core pour remplir cette fonction il sera temps de migrer mais aujourd’hui je ne comprends pas les réticences quand cela ne cause aucun dommage aux plugins concernés.
Bonjour,
Le mer. 9 janv. 2019 à 16:06, Eric Lupinacci <eric@smellup.net> a écrit :
Hello,
Je comprends.
Et je ne comprends…
Le mer. 9 janv. 2019 à 15:55, Mist. GraphX <arnaud.berard@mister-graphx.com> a écrit :
Ce plugin est la parceque personne n’as souhaité que ce soit intégré aux
plugins citésLà je ne comprends pas.
Ce plugin est intégré à tous les plugins-dist.
On peut avoir des griefs sur pourquoi, comment et ça serait mieux si… mais toujours est-il que cela apporte une solution à un besoin réel.
Donc c’est quoi cette histoire de consensus ?
L’ajout de cette fonctionnalité dans ces plugins est indolore car elle ne perturbe pas le fonctionnement du plugin et voire inodore si on active pas IEconfig.j’ai abordé le sujet maintes fois, je trimbalais ça depuis x années dans
ma toolbox , etc … ça a fini comme ça pour être dispo aux autres sans
avoir trouvé de consensus ^^ et avoir déjà pas mal alimenté de
discussions pourtantBen donc je maintiens ce que j’ai dit.
C’est une erreur et on devrait inclure cela dans les plugins.
Si un jour on se décide à mettre en place un mécanisme du core pour remplir cette fonction il sera temps de migrer mais aujourd’hui je ne comprends pas les réticences quand cela ne cause aucun dommage aux plugins concernés.
En effet, cela a fait couler de l’encre quand le sujet a été abordé.
Rien n’empêche aujourd’hui que chaque développeur d’un plugin intègre ce qui a été fait dans IEconfig Plus dans son propre plugin et le retirer de ce dernier plugin.
C’est à chaque auteur de plugin de prendre la décision (c’était entre autre le consensus trouvé à l’époque).
Ybbet
++
Eric
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Le 09/01/2019 à 16:05, Eric Lupinacci a écrit :
Si un jour on se décide à mettre en place un mécanisme du core pour remplir cette fonction il sera temps de migrer mais aujourd'hui je ne comprends pas les réticences quand cela ne cause aucun dommage aux plugins concernés.
Je crois que certains ne voulaient pas qu'un plugin tiers gère ses besoins dans le code de leur plugin.
JL
Le 09/01/2019 à 16:13, JLuc a écrit :
Le 09/01/2019 à 16:05, Eric Lupinacci a écrit :
Si un jour on se décide à mettre en place un mécanisme du core pour remplir cette fonction il sera temps de migrer mais aujourd'hui je ne comprends pas les réticences quand cela ne cause aucun dommage aux plugins concernés.
Je crois que certains ne voulaient pas qu'un plugin tiers gère ses besoins dans le code de leur plugin.
JL
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
l'histoire aussi c'était de virer justement les exports de config des plugins du core,
après discussion avec b_b de mémoire c'était au plugin ie_config d'utiliser les autres et pas l'inversse
y'avait un tiquet sur medias la dessus, un télescopage de meta, de mémoire
--
Bonne journée
Arnaud B. (Mist. GraphX)
Le mer. 9 janv. 2019 à 16:13, JLuc <jluc@no-log.org> a écrit :
Le 09/01/2019 à 16:05, Eric Lupinacci a écrit :
Si un jour on se décide à mettre en place un mécanisme du core pour remplir cette fonction il sera temps de migrer mais
aujourd’hui je ne comprends pas les réticences quand cela ne cause aucun dommage aux plugins concernés.Je crois que certains ne voulaient pas qu’un plugin tiers gère ses besoins dans le code de leur plugin.
Ouais enfin là c’est un mécanisme général qui DEVRAIT être fourni par le Core de même que la gestion des tables.
Un schéma de données d’un plugin est autant composé des tables en base que des informations de configuration éventuelles.
D’ailleurs on a commencé à intégré cette gestion dans le fichier administrations de certains plugins qui n’ont parfois pas de tables SQL.
Et ça permet de gérer proprement la désinstallation des données de configuration aussi car sinon elles ne sont jamais supprimée.
Donc pour moi cela est un tout, j’initialise le schéma, je désinstalle le plugin et ses données et je permet un import/export pour ne pas perdre forcément tout lors de la désinstallation ou pour avoir une initialisation plus complète.
Donc c’est pas une raison même si je répète que je ne suis pas forcément fan de l’implémentation de IECOnfig mais c’est la seule aujourd’hui qui existe et qu’elle ne fait aucun mal aux plugins.
++
Eric
Héhé,
Rien n’empêche aujourd’hui que chaque développeur d’un plugin intègre ce qui a été fait dans IEconfig Plus dans son propre plugin et le retirer de ce dernier plugin.
C’est à chaque auteur de plugin de prendre la décision (c’était entre autre le consensus trouvé à l’époque).
C’est la nouvelle charte de SPIP ?
Je conçois tout à fait que modifier les fonctions d’un plugin soit à discuter préalablement et je suis le premier à le dire.
Le Go go go m’emmerde un peu parfois.
Mais là je ne vois pas ce que cela modifie dans le plugin ? Rien à mon avis.
Donc préférer créer des CS pour cette raison me parait pas raisonnable.
Et cette fonction manque dans SPIP !
Eric
Le 09/01/2019 à 15:30, Eric Lupinacci a écrit :
Euh quoi ouais ? J'ai gouré ?
Ouais je suis d'accord. Je vois pas l'intérêt d'être obligé d'installer
deux plugins pour faire ça. Et quitte à centraliser, autant que ce soit
dans le plugin de base dans ce cas là, au minimum (du genre, le plugin
de base fournit des implémentations par défaut, et ensuite chacun peut
continuer d'étendre). Même si le principe c'est qu'il y a une API et que
chaque besoin peut l'implémenter.
Après je comprends en partie que des devs de plugins ne veuillent pas
ajouter du bazar à leur plugin pour une API qui n'est pas officiel, pas
fournie par le noyau (là ça serait un autre débat). Moi-même je ne suis
pas sûr que ce soit super.
Mais dans cas, le plugin central peut déjà fournir une liste
d'implémentations de choses qui sont connus. Et le système d'extension
sera surtout pour celleux qui veulent ajouter des comportements vraiment
persos pour leur site précis.
(Mais ça pose des problèmes techniques car des branches d'un même plugin
peuvent avoir des changements importants, cf noizetier, et donc
difficile d'avoir un truc central qui marcherait toujours, alors que si
chaque version du plugin a son implémentation interne ça va.)
Mais pas deux plugins différents dans les deux cas possibles.
--
RastaPopoulos
Re,
Le mer. 9 janv. 2019 à 17:20, RastaPopoulos <rastapopoulos@spip.org> a écrit :
Le 09/01/2019 à 15:30, Eric Lupinacci a écrit :
Euh quoi ouais ? J’ai gouré ?
Ouais je suis d’accord. Je vois pas l’intérêt d’être obligé d’installer
deux plugins pour faire ça. Et quitte à centraliser, autant que ce soit
dans le plugin de base dans ce cas là, au minimum (du genre, le plugin
de base fournit des implémentations par défaut, et ensuite chacun peut
continuer d’étendre). Même si le principe c’est qu’il y a une API et que
chaque besoin peut l’implémenter.
Ben oui on est bien d’accord surtout que ça sert aussi dans le plugin de base « tout seul ».
Et c’est le fonctionnement de IEConfig.
Après je comprends en partie que des devs de plugins ne veuillent pas
ajouter du bazar à leur plugin pour une API qui n’est pas officiel, pas
fournie par le noyau (là ça serait un autre débat). Moi-même je ne suis
pas sûr que ce soit super.
Je pense que c’est une très mauvaise pratique même si je comprends ceux qui veulent utiliser IEConfig.
Ce que je ne comprends c’est la réticence pour les plugins accueillant IEConfig.
Ok l’API n’est pas officielle mais d’un autre coté elle n’est pas si invasive (quelques items de langue et un php) que cela et surtout elle est inoffensive.
Après j’avoue que j’aimerais qu’on intègre une telle API dans le Core au même titre que la gestion des tables car je pense que c’est au même niveau (schéma de données).
Mais dans cas, le plugin central peut déjà fournir une liste
d’implémentations de choses qui sont connus. Et le système d’extension
sera surtout pour celleux qui veulent ajouter des comportements vraiment
persos pour leur site précis.
C’est déjà ce que fais IEConfig en traitant certaines metas il me semble.
A vérifier tout de même.
(Mais ça pose des problèmes techniques car des branches d’un même plugin
peuvent avoir des changements importants, cf noizetier, et donc
difficile d’avoir un truc central qui marcherait toujours, alors que si
chaque version du plugin a son implémentation interne ça va.)
Absolument.
Quand je vois le bordel que j’ai créé de façon non standard à l’époque dans Sarka-SPIP pour faire un truc moins performant je trouve que l’idée est très intéressante.
Par exemple, mon squelette en cours de dev, Z-Gala, utilise menus, sélections éditoriales, noiZetier…
Si ces plugins utilisent IEConfig je n’ai rien à faire d’autres que d’utiliser IEConfig pour obtenir une configuration initiale du squelette que je peux charger à l’activation ou après.
Et ça je trouve que c’est notable.
Et nécessiter IEConfig Plus ou le développer dans Z-Gala parce qu’un plugin ne « veut » pas inclure cette fonction je trouve ça idiot.
Avec IEConfig Plus on vient de créer encore un nouveau CS…
Eric
Le 09/01/2019 à 17:57, Eric Lupinacci a écrit :
Avec IEConfig Plus on vient de créer encore un nouveau CS...
Merci du compliment … j'apprécie (…)
ça fait 6 ans que personne ne veux de ces fonctionnalités et que je les utilises quotidiennement pour déployer mes distribs/skels , ce plugin est arrivé la car real_et m'as demandé en réponse a un post du forum de ie_config si j'avais intégré l'export de formulaires ou autres, je l'ai mis en plugin et a disposition, pour rendre service, et sans prétention (c'est ptet codé a l'arrache, mais ça fait le job …) …
après faut proposer mieux, c'est sur la zone, et si quand tu parle toi on t'écoute ça va peut être faire avancer le débat…
quand vous vous serez mis d'accord je m'adapterais et la prochaine fois je foutrais ça sur github ou dropbox…
--
Bonne journée
Arnaud B. (Mist. GraphX)
Hello,
Le jeu. 10 janv. 2019 à 09:34, Mist. GraphX <arnaud.berard@mister-graphx.com> a écrit :
Le 09/01/2019 à 17:57, Eric Lupinacci a écrit :
Avec IEConfig Plus on vient de créer encore un nouveau CS…
Merci du compliment … j’apprécie (…)
Je ne comprends pas ta réaction.
Je soulève un sujet a priori un peu tard mais allant dans le sens que tu proposes depuis longtemps et tu te vexes.
Oui, le plugin tel qu’il est aujourd’hui est un CS car il crée une situation potentielle de doublon à terme et casse la logique du plugin IEConfig.
Maintenant, je peux remballer mon mail et faire ce qu’il me plait sur les plugins sans me préoccuper si ça va gêner ou pas, c’est peut être mieux oui.
ça fait 6 ans que personne ne veux de ces fonctionnalités et que je les
utilises quotidiennement pour déployer mes distribs/skels , ce plugin
est arrivé la car real_et m’as demandé en réponse a un post du forum de
ie_config si j’avais intégré l’export de formulaires ou autres, je l’ai
mis en plugin et a disposition, pour rendre service, et sans prétention
(c’est ptet codé a l’arrache, mais ça fait le job …) …
Le code ne pose pas de souci.
Et je soutiens le fait qu’on pourrait intégrer cela dans chaque plugin mais j’en conviens qu’il y a des réticences que je considère pas fondées.
quand vous vous serez mis d’accord je m’adapterais et la prochaine fois
je foutrais ça sur github ou dropbox…
Si tu le dis…
Tout ça milite quand même malheureusement pour ne pas se préoccuper de ce qui est fait.
Ca me désole.
Aller à +
Eric
Hello,
Déjà désolé j’ai été un peut sec et tu n’y est pour rien n’étant pas au courant de ce feuilleton …
Je ne comprends pas ta réaction.
Je soulève un sujet a priori un peu tard mais allant dans le sens que tu proposes depuis longtemps et tu te vexes.
on peut pas dire que comparer un plugin au Couteau Suisse soit un compliment… ça fait genre éléphant man, l’erreur humaine … (cela dit c’est un des plugins les plus utilisés dans les stats spip quasiment … j’aurais du prendre ça pour un compliment alors ^^).
ce qui me « vexe » c’est le temps de perdu en tergiversations, pour qu’on me dise quasiment que c’est de ma faute si cette contrib est une « erreur de la nature » …en résumant grossièrement et avec humour ;-).
Pour moi l’erreur c’est de ne pas vouloir polluer un fichier pipeline avec trois lignes de codes, alors que c’est blindé de compat de versions de spip et de php que l’on ne devrait mm plus supporter (ça fait du code lent illisible, mais ça dérange pas ça …) au passage comme ça, et la je rigole pas.
Oui, le plugin tel qu’il est aujourd’hui est un CS car il crée une situation potentielle de doublon à terme et casse la logique du plugin IEConfig.
Quelle « logique » ? :
si j’ai bien compris : ieconfig fourni des pipelines pour faciliter les exports (que ce soit depuis un plugin, ou depuis un skel pour tout ses plugins : ex le noizettier) donc jusqu’ici on est dans la logique : un plugin A fourni une api et le plugin B ou C utilise , le plugin D peut apporter au plugin C… pas idéal, risqué mais c’est SPIP, au final on a plus de surcharges que de skel
In the real life the SPIP zone logik :
1- les auteurs respectif des plugins ne veulent pas de ça dans leur plugin
2- ça n’as pas été souhaité par l’auteur de ie config non plus
3- les plugins du core ne veulent plus des configs de ieconfig
4- (qui devrait toujours être en position numéro 1^^ car on est ‹ agile › avec nos dix doigts) les utilisateurs et personnes qui installe/utilise des squelettes basé sur une 60aine de plugins en on besoin : et n’en on rien a foutre de ce que pense les devs des autres plugins (hé oui désolé, mais ils/elles s’en tape des bugs js sur FF, IE, ou des trois lignes dans un fichier pipeline qui font désordre: faut que ça marche et basta …) enfin moi c’est plutôt ça .
donc je pense avoir fait tout ce qui était possible, et limite je crois avoir passé plus de temps a envoyer/repondre échanger sur le sujet qu’a coder les fonctions d’export et le plugin 
d’ou mon agacement, mais encore une fois tu n’y est pour rien.
Maintenant, je peux remballer mon mail et faire ce qu’il me plait sur les plugins sans me préoccuper si ça va gêner ou pas, c’est peut être mieux oui.
ça fait 6 ans que personne ne veux de ces fonctionnalités et que je les
utilises quotidiennement pour déployer mes distribs/skels , ce plugin
est arrivé la car real_et m’as demandé en réponse a un post du forum de
ie_config si j’avais intégré l’export de formulaires ou autres, je l’ai
mis en plugin et a disposition, pour rendre service, et sans prétention
(c’est ptet codé a l’arrache, mais ça fait le job …) …Le code ne pose pas de souci.
Et je soutiens le fait qu’on pourrait intégrer cela dans chaque plugin mais j’en conviens qu’il y a des réticences que je considère pas fondées.quand vous vous serez mis d’accord je m’adapterais et la prochaine fois
je foutrais ça sur github ou dropbox…Si tu le dis…
Tout ça milite quand même malheureusement pour ne pas se préoccuper de ce qui est fait.
C’est les X ans de non discussion stériles qui ne milite pas en faveur de ce qui pourrait/aurait pue/due être fait !! et je ne parle pas que de ieconfig, y’a pas mal d’autres sujets similaires hein : svn/git, accessibilité, responsive admin, etc …
je passe assez de temps a me préoccuper justement de ce qui se fait, quitte a passer pour troll (voir un c…) la plupart du temps … mais comme je l’ai dit peut être que toi on t’écoutera … ne perdons pas espoirs 
Bon courage ou bonne chance … et comme c’est sur la zone tu fait bien ce que tu sent le mieux , si j’avais quelque chose a redire je l’aurais mis ailleurs, y’aurait eut des PR …
ha si un détail : ce qui est fait : n’est plus a faire
déjà c’est plutôt bien,
y’en a y dise merci, ça permet de répondre de rien… (une approche différente en quelque sorte)
Allez bises et Bonne soirée
Arnaud
Le 10/01/2019 à 23:18, GraphX a écrit :
Déjà désolé j'ai été un peut sec et tu n'y est pour rien n'étant pas au courant de ce feuilleton …
Je ne comprends pas ta réaction.
ce qui me "vexe" c'est le temps de perdu en tergiversations, pour qu'on me dise quasiment que c'est de ma faute si cette contrib est une "erreur de la nature" …en résumant grossièrement et avec humour ;-).
C'est cool de pas en rester sur le sec ou sur le vex.
Ça tombe bien car le passé est ce qu'il est (et c'est rarement l'idéal !),
mais <poesie>le présent reste à écrire</poesie>.
> In the real life the SPIP zone logik :
> 1- les auteurs respectif des plugins ne veulent pas de ça dans leur plugin
> 2- ça n'as pas été souhaité par l'auteur de ie config non plus
> 3- les plugins du core ne veulent plus des configs de ieconfig
Je n'ai pas lu/vu ces avis exprimés sur la liste dans ce fil aujourd'hui.
Est ce que qqn aujourd'hui s'oppose à qu'il y ait des traces de IEconfig dans "son" plugin ou dans un plugin-dist?
JLuc
J'aime ce fil ou on arrive a revenir sur l'essentiel ne pas démultiplié ...
mais quelques fois , il me semble que regrouper n'enclenche pas forcement une usine a gaz
mais evite le dédoublonnage des plugins
je comprend que concepteur considère son plugin comme son bébé, vous avez déjà vu quelqu'un qui aime qu'on tripote son bébé
ceci étant depuis le temps que je voulais me coller a un article sur le carnet ...
des plugins qui n’ont pas forcément le même concepteur, mais une approche similaire et qui pourrais fusionner il me semble
pour fournir un gros plug qui regroupe, je sais la tendance est plus a la multiplicité pour la lecture et le débugage
on en reviens a la source l'utilisateur ou le concepteur ?
2019 l'article du carnet faut que je m'y colle 
--
https://spipfactory.fr
----
En répondant a ce courriel vous acceptez implicitement la diffusion, l'échange de la conversation, sauf avis contraire clairement exprimé.
+1 à L'utilisateur !
Qui me semble parfois oublié...
"Mais la critique est facile... et l'Art difficile", ne voyez donc aucune attaque de quoi/qui que ce soit dans cet avis personnel de non-codeur (je me demande pourquoi je précise cela vu que "SPIP, ce n'est que de l'Amour" 
Je profite aussi de ce mail pour vous souhaiter à toutes et tous, mes meilleurs vœux pour cette nouvelle année, ainsi qu'une bonne santé, sans quoi rien n'est vraiment possible.
Bises,
Pascual
-----Message d'origine-----
De : teamspipfactory@gmail.com <teamspipfactory@gmail.com>
Envoyé : vendredi 11 janvier 2019 10:17
À : spip-zone@rezo.net
Objet : Re: [SPIP Zone] Importeur/Exporteur de configuration PLUS
J'aime ce fil ou on arrive a revenir sur l'essentiel ne pas démultiplié ...
mais quelques fois , il me semble que regrouper n'enclenche pas forcement une usine a gaz
mais evite le dédoublonnage des plugins
je comprend que concepteur considère son plugin comme son bébé, vous avez déjà vu quelqu'un qui aime qu'on tripote son bébé
ceci étant depuis le temps que je voulais me coller a un article sur le carnet ...
des plugins qui n’ont pas forcément le même concepteur, mais une approche similaire et qui pourrais fusionner il me semble
pour fournir un gros plug qui regroupe, je sais la tendance est plus a la multiplicité pour la lecture et le débugage
on en reviens a la source l'utilisateur ou le concepteur ?
2019 l'article du carnet faut que je m'y colle
--
https://spipfactory.fr
----
En répondant a ce courriel vous acceptez implicitement la diffusion, l'échange de la conversation, sauf avis contraire clairement exprimé.
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
bon vous pouvez modifié casser complété :
moi je tacherais de m’y coller le samedi
Le 11/01/2019 à 08:54, JLuc a écrit :
Est ce que qqn aujourd'hui s'oppose à qu'il y ait des traces de IEconfig dans "son" plugin ou dans un plugin-dist?
Dans les plugins dist oui, ça a été exprimé clairement qu'on ne voulait pas y mettre de lien avec des plugins non dist.
--
nicod_