Je tente de faire fonctionner le plugin mots_partout sur SPIP svn. Sans
succès.
Il signale notamment que la fonction afficher_tranches_requete() n'est
pas définie alors que la doc technique ne dit rien au sujet de la
disparition éventuelle de cette fonction :
http://doc.spip.org/@afficher_tranches_requete
Est-ce qu'il y a des explications quelque part ?
Merci
François
* franz tapuscrivait, le 24/08/2008 23:13:
Je tente de faire fonctionner le plugin mots_partout sur SPIP svn. Sans
succès.Il signale notamment que la fonction afficher_tranches_requete() n'est
pas définie alors que la doc technique ne dit rien au sujet de la
disparition éventuelle de cette fonction :
http://doc.spip.org/@afficher_tranches_requete
Est-ce qu'il y a des explications quelque part ?
Compte tenu des changements profonds au niveau de la structure des tables des mots, de toute manière, ce plugin ne marche plus (en l'état) avec SPIP 2.
--
RealET
Le dimanche 24 août 2008 à 23:18 +0200, RealET a écrit :
Compte tenu des changements profonds au niveau de la structure des
tables des mots, de toute manière, ce plugin ne marche plus (en l'état)
avec SPIP 2.
Ouille. Merci de l'info.
Est-ce que les auteurs de ce plugin comptent l'adapter à SPIP 2 ?
Est-ce qu'il existe une autre solution pour mettre des mots-clés sur les
auteurs ?
Au passage, une question d'ordre plus général : comment la communauté
SPIP envisage-t-elle de gérer les inévitables situation où des
utilisateurs vont devenir dépendants de plugins qui cesseront d'être mis
à jour ? Personnellement, là où il y encore un ou deux ans, la mise à
jour de SPIP vers une version ultérieure était quelque chose de très
simple, si pas automatique, je constate que je suis amené à être de plus
en plus prudent dans le choix de passer un site à une version ultérieure
(et que c'est donc et en plus une opération qui prend de plus en plus de
temps).
François
Au passage, une question d'ordre plus général : comment la communauté
SPIP envisage-t-elle de gérer les inévitables situation où des
utilisateurs vont devenir dépendants de plugins qui cesseront d'être mis
à jour ?
Le principe du logiciel libre c'est de ne pas en être dépendant, ou
d'acquérir la capacité à les maintenir. Si un plugin est utilisé, à
priori il trouve des gens pour le maintenir ; il est rare qu'il soit
abandonné.
Personnellement, là où il y encore un ou deux ans, la mise à
jour de SPIP vers une version ultérieure était quelque chose de très
simple, si pas automatique, je constate que je suis amené à être de plus
en plus prudent dans le choix de passer un site à une version ultérieure
(et que c'est donc et en plus une opération qui prend de plus en plus de
temps).
En ce qui me concerne c'est le contraire, grâce à la mutualisation et
à la séparation plus nette des ensembles de fichiers (code,
squelettes, plugins). Mais évidemment si tes sites ont gagné en
complexité à cause de la profusion de plugins (presque 500 sur la zone
!), c'est une autre affaire.
-- Fil
Le dimanche 24 août 2008 à 23:58 +0200, Fil a écrit :
Le principe du logiciel libre c'est de ne pas en être dépendant, ou
d'acquérir la capacité à les maintenir.
Sauf qu'il n'y a probablement que quelques pourcents (et encore) des
utilisateurs de SPIP (ou de tt autre ll) qui ont effectivement la
capacité de le maintenir.
Si un plugin est utilisé, à priori il trouve des gens pour le
maintenir ; il est rare qu'il soit abandonné.
C'est vrai que SPIP 2.0 n'est pas encore sorti (donc on peut considérer
qu'il est trop tôt pour tirer des conclusions), mais il y a quand même
pas mal de plugins qui ne fonctionnent pas encore sous SPIP 2 (ce qui
limite, soit dit en passant, la possibilité de faire fonctionner des
sites en production avec la version svn, pourtant le meilleur moyen de
la tester en permanence).
En ce qui me concerne c'est le contraire, grâce à la mutualisation et
à la séparation plus nette des ensembles de fichiers (code,
squelettes, plugins).
Je ne suis jamais parvenu à partager le code de SPIP entre différents
utilisateurs sur une machine Debian. Ce que je cherche à faire, c'est de
permettre aux utilisateurs de "se brancher" (ou pas -- et de se
débrancher) sur une copie de SPIP gérée au niveau du serveur. La
dernière fois que j'en avais parlé, Ben m'avait répondu
qu'effectivement, ce n'est pas possible actuellement.
Mais évidemment si tes sites ont gagné en complexité à cause de la
profusion de plugins
Il y a sans doute de ça, mais je ne pense pas que c'est le facteur
principal. Un truc qui me pose presque systématiquement problème, par
exemple, ce sont les formulaires, dont le fonctionnement a beaucoup
évolué depuis un an ou deux; dès qu'on les personnalise un tout petit
peu, la mise à jour devient très délicate.
(presque 500 sur la zone !), c'est une autre affaire.
Enfin, pour ce qui est des plus de 500 plugins, je trouve qu'il manque
d'un espace dédié à leur présentation. Pour chacun, une description
claire de ce qu'il fait, un historique des versions, une évaluation de
sa fiabilité, l'indication par l'auteur de ses perspectives de
développement, des rapports de bugs, l'état des lieux des éventuelles
traduction, la possibilité de le télécharger directement,...
François
Hello à tous,
Je me permets de réagir à la discussion
franz a écrit :
Le dimanche 24 août 2008 à 23:58 +0200, Fil a écrit :
Le principe du logiciel libre c'est de ne pas en être dépendant, ou
d'acquérir la capacité à les maintenir.
C'est pas toujours évident de maintenir ce qui a été fait par plusieurs personnes, rien que d'entrer dans la logique de programmation demande quelques fois pas mal de temps !
J'aime bien linux mais de la à le développer ou créer des drivers c'est une autre histoire... et je pense que c'est du libre.
Cela me fait plutôt penser à un recul par rapport à la facilité de mettre en place, ceci n'est en rien une critique mais un sentiment personnel.
Je pense que Spip 2 est attendu avec la plus grande impatience et que les nouveautés seront légions, mais la crainte de devoir arrondir les angles de nos bidouilles personnelles s'agite dans le lac de Nessie.
Sauf qu'il n'y a probablement que quelques pourcents (et encore) des
utilisateurs de SPIP (ou de tt autre ll) qui ont effectivement la
capacité de le maintenir.
C'est sur et j'en fait parti ! et j'étudie encore le php pour pouvoir aider du mieux que je peux, mes neurones étant pas très frais, c'est vrai que cela avance pas trop vite 
Si un plugin est utilisé, à priori il trouve des gens pour le
maintenir ; il est rare qu'il soit abandonné.
Pas forcément abandonné, mais quelque peu oublié ou plus utile par rapport au projet initial, ... bref un tas de raisons pour utiliser le classeur vertical.
C'est vrai que SPIP 2.0 n'est pas encore sorti (donc on peut considérer
qu'il est trop tôt pour tirer des conclusions), mais il y a quand même
pas mal de plugins qui ne fonctionnent pas encore sous SPIP 2 (ce qui
limite, soit dit en passant, la possibilité de faire fonctionner des
sites en production avec la version svn, pourtant le meilleur moyen de
la tester en permanence).
Justement si je prends le plugin association qui est lui même tributaire de spip2 et de inscription 2, peut-on réellement commencer à le développement alors que l'on sait que les 2 outils cités précédemment sont eux-mêmes encore en développement ? Et que moi je suis nulle part ! (c'est pas de ma faute, c'est eux ... arf je viens de trouver une belle excuse 
)
En ce qui me concerne c'est le contraire, grâce à la mutualisation et
à la séparation plus nette des ensembles de fichiers (code,
squelettes, plugins).
Tes compétences Fil ne sont plus à démontrer, mais les miennes sont limitées, et j'en suis navré.
Je ne suis jamais parvenu à partager le code de SPIP entre différents
utilisateurs sur une machine Debian. Ce que je cherche à faire, c'est de
permettre aux utilisateurs de "se brancher" (ou pas -- et de se
débrancher) sur une copie de SPIP gérée au niveau du serveur. La
dernière fois que j'en avais parlé, Ben m'avait répondu
qu'effectivement, ce n'est pas possible actuellement.
J'arrive à gérer plus ou moins le svn.
Mais évidemment si tes sites ont gagné en complexité à cause de la
profusion de plugins
C'est vrai que c'est très tentant de transformer notre bon et brave Spip en usine à gaz.
Il y a sans doute de ça, mais je ne pense pas que c'est le facteur
principal. Un truc qui me pose presque systématiquement problème, par
exemple, ce sont les formulaires, dont le fonctionnement a beaucoup
évolué depuis un an ou deux; dès qu'on les personnalise un tout petit
peu, la mise à jour devient très délicate.
Les formulaires, on parle de personnalisation de l'interface privée, des outils de série dans le core, ... vu de l'extérieur, sérieux ça fait peur !
(presque 500 sur la zone !), c'est une autre affaire.
Enfin, pour ce qui est des plus de 500 plugins, je trouve qu'il manque
d'un espace dédié à leur présentation. Pour chacun, une description
claire de ce qu'il fait, un historique des versions, une évaluation de
sa fiabilité, l'indication par l'auteur de ses perspectives de
développement, des rapports de bugs, l'état des lieux des éventuelles
traduction, la possibilité de le télécharger directement,...
C'est un débat qui a déjà eu lieu dans un autre post, des initiatives ont été prises, ou en sont-elles je n'en sais rien ?
J'installe quelque fois un plugin par fainéantise, sans en utiliser toutes les fonctions, un bel exemple, le couteau suisse pour les urls propres, alors qu'avec mesoptions et htacess, cela le fait aussi...
Et pourtant, je me sens incapable de maintenir toutes les fonctions du couteau suisse en cas de besoin.
Toujours et de plus en plus admiratif devant les possibilités passées, présentes et à venir de Spip, c'est avec respect que je voulais réagir à ce message.
Avec toute mon amitié
P@ulbe
Fil a écrit :
Personnellement, là où il y encore un ou deux ans, la mise à
jour de SPIP vers une version ultérieure était quelque chose de très
simple, si pas automatique, je constate que je suis amené à être de plus
en plus prudent dans le choix de passer un site à une version ultérieure
(et que c'est donc et en plus une opération qui prend de plus en plus de
temps).En ce qui me concerne c'est le contraire, grâce à la mutualisation et
à la séparation plus nette des ensembles de fichiers (code,
squelettes, plugins). Mais évidemment si tes sites ont gagné en
complexité à cause de la profusion de plugins (presque 500 sur la zone
!), c'est une autre affaire.
SPIP pourrait avertir quelquepart
"Surtout n'upgradez pas votre spip avec la nouvelle version alléchante
car les plugs XXX, XXY et XXZ n'existent pas pour la nouvelle version !
Mais vous pouvez vous rendre sur la zone pour bosser à leur mise à jour..."
ou bien
"Youhou! Savez vous qu'une nouvelle version de SPIP existe (lien doc)
pour laquelle tous vos plugins sont compatibles
ou peuvent également être mis à jour ???"
JL
* JLuc tapuscrivait, le 25/08/2008 10:21:
Fil a écrit :
Personnellement, là où il y encore un ou deux ans, la mise à
jour de SPIP vers une version ultérieure était quelque chose de très
simple, si pas automatique, je constate que je suis amené à être de plus
en plus prudent dans le choix de passer un site à une version ultérieure
(et que c'est donc et en plus une opération qui prend de plus en plus de
temps).En ce qui me concerne c'est le contraire, grâce à la mutualisation et
à la séparation plus nette des ensembles de fichiers (code,
squelettes, plugins). Mais évidemment si tes sites ont gagné en
complexité à cause de la profusion de plugins (presque 500 sur la zone
!), c'est une autre affaire.SPIP pourrait avertir quelquepart
Tu peux faire l'article sur www.spip.net/ecrire/ ?
--
RealET
franz a écrit :
Salut Francois,
si tu commencais par nous dire quelle version du plugin tu utilises, ca pourrait aider....
il y avait une branche qui suivait à svn avant l'été, je ne sais pas si le travail s'est poursuivi.
A coté de ca, on a une branche 1.9.2 et un trunk...
Le dimanche 24 août 2008 à 23:18 +0200, RealET a écrit :
Compte tenu des changements profonds au niveau de la structure des tables des mots, de toute manière, ce plugin ne marche plus (en l'état) avec SPIP 2.
Ouille. Merci de l'info.Est-ce que les auteurs de ce plugin comptent l'adapter à SPIP 2 ?
sans doute vu qu'on est quelques uns à avoir mis les mains dedans.
Perso, dès que j'ai un site à migrer sur 2.0 (vu que j'utilises quasi systématiquement ce plugin) ou que je me lance dans la mise à jour de spipcarto
Est-ce qu'il existe une autre solution pour mettre des mots-clés sur les
auteurs ?Au passage, une question d'ordre plus général : comment la communauté
SPIP envisage-t-elle de gérer les inévitables situation où des
utilisateurs vont devenir dépendants de plugins qui cesseront d'être mis
à jour ?
l'open source a ses avantages et ses inconvénients...
maintenant, en general, un plugin "stable" et utilisé (car répondant à un vrai besoin) sera maintenu au moins jusqu'à ce que la fonctionnalité soit accessible par un autre plugin ou integrée...
Mais bon, la, tu parles de mots_partout qui reste rangé dans les plugins en test et contient plein de fichiers forkés... l'exemple type du plugin à ne pas utiliser !
Il faut comprendre que la course au SVN est un sport épuisant
les plugins contenant des surcharges de fichier ont donc tendance à attendre la sortie d'une version stable avant de se lancer dans une mise à jour (qui consiste en général à reporter les modifications sur la nouvelle version du fichier).
A coté de ca, il y a plein de plugins qui ne nécessitent pas vraiment de mise à jour et continueront à fonctionner en 2.0 (la seule chose à faire, c'est de tester et de faire remonter l'info à l'auteur)
bref, une chose à la fois, il faudrait deja qu'il y ait un spip 2.0 avant de commencer à raler après les plugins (et laisser un mois ou 2 aux developpeurs de plugins pour mettre à jour, parce qu'ils ont des fois autre chose à faire...).
@++
franz a écrit :
Je tente de faire fonctionner le plugin mots_partout sur SPIP svn. Sans
succès.
bon j'arrive un peu après la bataille mais vacances obligent
Ce plugin ne sera pas abandonné.
Par contre les recents changements au niveau des mots demandent une bonne grosse refonte de ce plugin.
De plus, le code devenant un peu brouillon sur la fin (rustine sur rustine ( de ma part j'en suis conscient ) ) ne permettent pas une adaptabilité et reprise du code par la suite par quelqu'un d'autre...
D'ici quelque temps, a partir de mi septembre environ, je vais commencer a y bosser dessus ... mais de la a le terminer rapidement ... je ne peux rien garantir ... je reviendrais trés probablement vers vous a ce moment la
Yoann
Je tente de faire fonctionner le plugin mots_partout sur SPIP svn. Sans
succès.Ce plugin ne sera pas abandonné.
Par contre les recents changements au niveau des mots demandent une bonne
grosse refonte de ce plugin.
Quand tu y retravailleras, tu peux avoir en tête que pour SPIP 2.1 il
est prévu de pêter la structure des liens entre les mots et les
articles. Au lieu de (id_mot, id_article) dans spip_mot_articles, on
vise (id_mot, id_objet, type) dans spip_mots_liens (avec id_objet =
id_article et type = 'article'). Avec ça "mots partout" sera presque
dans le core.
C'est ce qu'on vient de faire pour les documents, ce qui permet
"presque" nativement de faire du "documents partout". Et qu'on
pourrait généraliser si le temps etc... (auteurs partout, etc)
-- Fil
franz a écrit :
C'est vrai que SPIP 2.0 n'est pas encore sorti (donc on peut considérer
qu'il est trop tôt pour tirer des conclusions), mais il y a quand même
pas mal de plugins qui ne fonctionnent pas encore sous SPIP 2 (ce qui
limite, soit dit en passant, la possibilité de faire fonctionner des
sites en production avec la version svn, pourtant le meilleur moyen de
la tester en permanence).
heu, non, surtout pas.
à la limite il faudrait plutot bloquer la possibilité de mettre des plugin sur la version beta meme.
si les utilisateurs testent avec chacun leur 3 plugins, leur retour de bug n'a plus la meme valeur, comment savoir si c'est effectivement qqchose à corriger dans Spip ?
le but aujourd'hui est de stabiliser SPIP pour sortir une 2.0.
Il y a de plus en plus de melange entre Spip et les plugins, ce qui est dommageable pour tout le monde.
il faut faire comprendre aux utilisateurs qu'en mettant un plugin, ils n'utilisent plus un spip standard comme tout le monde, et que les problemes qu'ils rencontrent sont du coup spécifiques à leur config (interaction entre plugins, bugs, configuration particulière nécessaire...). En gros, ils perdent la "garantie" (le fait de pouvoir se dire quand ca ne marche pas : il n'y a pas 40 personne dans le meme cas que moi, c'est donc que le probleme vient de moi).
Le fait qu'on traite les problemes de plugins sur la liste user contribue fortement à laisser penser aux utilisateurs que les plugins ont les memes qualités que Spip alors qu'il y a vraiment de tout, y compris des trucs vraiment sales...
Peut etre efferctivement qu'un petit rappel sur la page d'activation des plugins ne ferait pas de mal, au moins pour dire qu'un plugin n'est stable que pour une version donnée de Spip et qu'il faudra donc attendre que tous les plugins aient une nouvelle version pour pouvoir migrer.
Peut etre aussi en profiter pour rappeler que lors des sauvegarde restauration, il faut en general reconfigurer les plugins AVANT de restaurer.
mes 2 cents.
@++
Fil a écrit :
Je tente de faire fonctionner le plugin mots_partout sur SPIP svn. Sans succès.Ce plugin ne sera pas abandonné. Par contre les recents changements au niveau des mots demandent une bonne grosse refonte de ce plugin.Quand tu y retravailleras, tu peux avoir en tête que pour SPIP 2.1 il est prévu de pêter la structure des liens entre les mots et les articles. Au lieu de (id_mot, id_article) dans spip_mot_articles, on vise (id_mot, id_objet, type) dans spip_mots_liens (avec id_objet = id_article et type = 'article').
il me semblait que c’était déjà le cas pour tous les objets … apparement ce n’est que pour les documents … bon je creuserai le moment voulu
j’avais suivi de loin les discussions sur la liste de dev
Avec ça "mots partout" sera presque dans le core. C'est ce qu'on vient de faire pour les documents, ce qui permet "presque" nativement de faire du "documents partout". Et qu'on pourrait généraliser si le temps etc... (auteurs partout, etc)
j’ai toujours penser que la puissance des mots clefs était sous utilisée dans spip … mais bon en faisant du squelette perso on peut en tirer parti a fond
Le lundi 25 août 2008 à 11:15 +0200, Stephane a écrit :
à la limite il faudrait plutot bloquer la possibilité de mettre des
plugin sur la version beta meme.
si les utilisateurs testent avec chacun leur 3 plugins, leur retour de
bug n'a plus la meme valeur, comment savoir si c'est effectivement
qqchose à corriger dans Spip ?
Evidemment, quand je tombe sur un bug, la première chose que je fais est
de désactiver les plugins pour m'assurer que le bug ne vient pas d'eux.
Le lundi 25 août 2008 à 10:55 +0200, Stephane a écrit :
si tu commencais par nous dire quelle version du plugin tu utilises, ca
pourrait aider....
0.4.1 SVN [22193]
il y avait une branche qui suivait à svn avant l'été, je ne sais pas si
le travail s'est poursuivi.
Il ne semble pas.
A coté de ca, on a une branche 1.9.2 et un trunk...
Bête question : c'est quoi un trunk ?
Il faut comprendre que la course au SVN est un sport épuisant [...]
bref, une chose à la fois, il faudrait deja qu'il y ait un spip 2.0
avant de commencer à raler après les plugins
Je ne me permettrais pas de râler. Je fais juste part de difficultés que
je rencontre liées à l'utilisation de plus en plus intensive des plugins
et à la difficulté d'évaluer exactement ce qu'on peut attendre de chacun
d'eux (par exemple, sans avoir vérifié, je pensais que mots partout
pouvait fonctionner sans forker des fichiers, juste avec les points
d'entrée. Intuition erronée manifestement).
++
François
* franz tapuscrivait, le 25/08/2008 16:42:
d'eux (par exemple, sans avoir vérifié, je pensais que mots partout
pouvait fonctionner sans forker des fichiers, juste avec les points
d'entrée. Intuition erronée manifestement).
En 1.9.2, y'avait plein de forks.
En 2.0, Cédric a effectivement mis les points d'entrée qui vont bien (mais pas encore d'exemple d'utilisation).
--
RealET
RealET a écrit :
>JLuc a écrit
SPIP pourrait avertir quelquepart
Tu peux faire l'article sur www.spip.net/ecrire/ ?
Je pensais surtout à une page d'actu-versions-bilan-plugins-conseils-upgrade
dans la partie privée.
En doc, je vois pas de quoi remplir un article !
Juste, si ce n'est pas déjà fait dans la page sur l'upgrade :
"La mise à jour de SPIP sur un site aura des conséquences sur le fonctionnement
des plugins.
Si vous installez la nouvelle version, certains plugins marcheront toujours parfaitement,
d'autres marcheront mal, d'autres ne marcheront plus du tout.
Consultez donc attentivement la documentation de chacun de vos plugins
avant de faire cette mise à jour !
Certains des plugins bénéficient peut-être également d'une nouvelle version,
compatible avec la nouvelle future version de spip envisagée,
et qu'il sera nécessaire de charger et d'installer après la mise à jour de SPIP"
Sans la page d'actu-plugins-bilan-conseil personnalisés,
ça dissuade pas mal d'upgrader...
et ça invite à structurer la zone ou spip-contrib (lequel ?)
de manière à trouver ces infos facilement...
JL
Fil a écrit :
...
Je tente de faire fonctionner le plugin mots_partout sur SPIP svn.
...
Quand tu y retravailleras, tu peux avoir en tête que pour SPIP 2.1 il
est prévu de pêter la structure des liens entre les mots et les
articles. Au lieu de (id_mot, id_article) dans spip_mot_articles, on
vise (id_mot, id_objet, type) dans spip_mots_liens (avec id_objet =
id_article et type = 'article'). Avec ça "mots partout" sera presque
dans le core.
C'est ce qu'on vient de faire pour les documents, ce qui permet
"presque" nativement de faire du "documents partout". Et qu'on
pourrait généraliser si le temps etc... (auteurs partout, etc)
Ben peut être le plugin devrait il alors lors de son install
faire comme un upgrade spip et carrément traduire la structure actuelle
des motclés vers la future manière.
JL
ne pas compter sur un portage rapide de ce plugin, il me semble
Cédric
Le 30 août 08 à 23:48, JLuc a écrit :
Fil a écrit :
...Je tente de faire fonctionner le plugin mots_partout sur SPIP svn.
...
Quand tu y retravailleras, tu peux avoir en tête que pour SPIP 2.1 il
est prévu de pêter la structure des liens entre les mots et les
articles. Au lieu de (id_mot, id_article) dans spip_mot_articles, on
vise (id_mot, id_objet, type) dans spip_mots_liens (avec id_objet =
id_article et type = 'article'). Avec ça "mots partout" sera presque
dans le core.C'est ce qu'on vient de faire pour les documents, ce qui permet
"presque" nativement de faire du "documents partout". Et qu'on
pourrait généraliser si le temps etc... (auteurs partout, etc)Ben peut être le plugin devrait il alors lors de son install
faire comme un upgrade spip et carrément traduire la structure actuelle
des motclés vers la future manière.
JL_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
cedric.morin@yterium.com a écrit :
ne pas compter sur un portage rapide de ce plugin, il me semble
Non je ne compte pas car je ne m'en sers pas,
mais c'est une belle fonctionnalité et même un peu emblématique,
surtout avec l'ouverture de spip à toutes tables.
peut être le plugin devrait il alors lors de son install
faire comme un upgrade spip et carrément traduire la structure actuelle
des motclés vers la future manière.
ça n'a t il pas de sens intéressant ?
car ensuite il suffirait de porter les éléments du plugins
(upgrade notamment) vers spip 2.1
JL
Le 31 août 08 à 20:54, JLuc a écrit :
cedric.morin@yterium.com a écrit :
ne pas compter sur un portage rapide de ce plugin, il me semble
Non je ne compte pas car je ne m'en sers pas,
mais c'est une belle fonctionnalité et même un peu emblématique,
surtout avec l'ouverture de spip à toutes tables.peut être le plugin devrait il alors lors de son install
faire comme un upgrade spip et carrément traduire la structure actuelle
des motclés vers la future manière.ça n'a t il pas de sens intéressant ?
car ensuite il suffirait de porter les éléments du plugins
(upgrade notamment) vers spip 2.1
non c'est le contraire :
le core doit avoir juste les structures et mecanismes pour que mot partout ne soit plus, in fine, que des ajouts d'interface.
Cédric