les histoires de versioning de Nicolas & une relecture du projet initial de
SPIP & un besoin temporaire me ramènent vers notre histoire de "recopier cet
article". Voici ma suggestion du matin
1) Un nouveau squelette par défaut fournit les "sources" d'un article
publié : le texte est copi-collable grâce à un truc comme
[(#TEXTE*|htmlspecialchars)].
2) dans l'espace privé, à l'endroit de "créer/modifier l'article", un bouton
"recopier un article" propose un formulaire :
URL du site [ ] (laisser vide pour recopier en local)
n° de l'article à copier [ ]
3) Quand on valide, l'article n du site distant est recopié en local dans
l'article qu'on est en train d'éditer, avec ses images, ses docs joints
(et leurs blablas), ses auteur(s) [y compris leur bio + logo], et ses
mots-clés (en option seulement) [ne pas oublier la balise #EXTRA]
4) Configuration : dans l'espace privé, il faut activer la possibilité de
recopie à distance par n'importe quel visiteur (la recopie locale, ou la
recopie par un admin ou rédacteur est tjs autorisée).
Format de transfert : le "pseudo-xml" qui sert à faire les sauvegardes ?
Seul problème, on ne sait pas faire du "push" vers un site, seulement du
pull. Il manquera donc un système "recopier un article depuis un fichier
uploadé" ou quelque chose comme ça, auquel je n'ai pas encore réfléchi.
Depuis le temps, ça a bien changé, attention à ne pas être trop
conservateur quand même ...
un besoin temporaire
Mais qui peut durer ...
me ramènent vers notre histoire de "recopier cet article". Voici ma
suggestion du matin
1) Un nouveau squelette par défaut fournit les "sources" d'un
article publié : le texte est copi-collable grâce à un truc comme
[(#TEXTE*|htmlspecialchars)].
OK, utile de toute façon.
2) dans l'espace privé, à l'endroit de "créer/modifier l'article",
un bouton "recopier un article" propose un formulaire :
URL du site [ ] (laisser vide pour recopier en local)
n° de l'article à copier [ ]
Mouais ...
Pour la copie locale, c'est sans doute plus simple d'avoir "créer une
copie de cet article" dans l'affichage de l'article source ...
3) Quand on valide, l'article n du site distant est recopié en local
dans l'article qu'on est en train d'éditer, avec ses images, ses
docs joints (et leurs blablas), ses auteur(s) [y compris leur bio
+ logo], et ses mots-clés (en option seulement) [ne pas oublier
la balise #EXTRA]
Ouah, chaud !
4) Configuration : dans l'espace privé, il faut activer la
possibilité de recopie à distance par n'importe quel visiteur (la
recopie locale, ou la recopie par un admin ou rédacteur est tjs
autorisée).
Format de transfert : le "pseudo-xml" qui sert à faire les
sauvegardes ?
C'est peut-être l'occasion de faire du XML "propre", à base de
DocBookXML par exemple ...
Seul problème, on ne sait pas faire du "push" vers un site,
seulement du pull.
C'est déjà pas mal.
Je ne vois par contre pas du tout en quoi ça règle ma problématique de
versioning, si ce n'est que ça facilite la copie, mais bon ...
C'est peut-être l'occasion de faire du XML "propre", à base de
DocBookXML par exemple ...
Tu me parles une langue inconnue, là, mais bon... pourquoi pas
Je ne vois par contre pas du tout en quoi ça règle ma problématique de
versioning, si ce n'est que ça facilite la copie
Euh, oui, tu copies dans un sens, tu édites, modifies, tords... puis tu
copies dans l'autre... enfin, un truc comme ça ; je ne cherche pas à
résoudre ton problème, hein, c'est juste que ce que tu évoques me donne des
idées...
Je ne vois par contre pas du tout en quoi ça règle ma problématique
de versioning, si ce n'est que ça facilite la copie
Euh, oui, tu copies dans un sens, tu édites, modifies, tords... puis
tu copies dans l'autre... enfin, un truc comme ça ; je ne cherche
pas à résoudre ton problème, hein, c'est juste que ce que tu évoques
me donne des idées...
Si tu préfères que le format d'échange soit celui-là, OK, mais il faudra que
tu t'y mettes ; rien que de voir la liste des tags à supporter, ça me colle
des boutons Si c'est moi qui le fais, ça sera très très basique : champ
spip => contenu...
C'est peut-être l'occasion de faire du XML "propre", à base de
DocBookXML par exemple ...
Bouh!
Si tu préfères que le format d'échange soit celui-là, OK, mais il
faudra que tu t'y mettes ; rien que de voir la liste des tags à
supporter, ça me colle des boutons
J'ai bien dit "à base de", l'idée est de reprendre les tags de
DocBookXML, comme ça un article sorti de SPIP pourra aussi être traité
par tout processeur DocBookXML quel qu'il soit ... et on pourra
peut-être un jour insérer directement dans SPIP un article au format
DocBookXML ...
N'etant pas un specialiste et n'ayant pas les competences pour
developper tout ca je me sens particulierement bien place pour faire
quelques suggestions :-))
Il me semble qu'il faudrait que la structure de base de ce systeme
soit *prevue* (i.e. : pas forcement tout d'implante au depart) pour
permettre de repondre a 3 besoins :
#1: Le doublage d'un article dans un meme site SPIP (A -> A)
Creer le double modifiable d'un article au sein du meme site
#2: La synchronisation (partielle) de deux sites SPIP (A -> B)
Envoie (push) ou recupere (pull) un article d'un site SPIP vers
un autre. Utile pour tous ceux qui n'ayant pas ADSL creent un
article d'abord en local (EasyPHP ou autre) avant de le mettre
online.
#3: La mise a disposition d'articles (A -> tous)
Permettre a chacun d'offir l'export de son article pour que tout
autre site SPIP puisse le recuperer et l'integrer facilement.
Certainement moins utile dans un premier temps, mais peut etre
interessant pour vraiment partager des infos (notamment en
contexte de risque de censure).
#1: Le doublage d'un article dans un meme site SPIP (A -> A)
Creer le double modifiable d'un article au sein du meme site
yep
#2: La synchronisation (partielle) de deux sites SPIP (A -> B)
Envoie (push) ou recupere (pull) un article d'un site SPIP vers
un autre. Utile pour tous ceux qui n'ayant pas ADSL creent un
article d'abord en local (EasyPHP ou autre) avant de le mettre
online.
la seule difficulté est sur ce point #2 : on ne peut pas faire du "pull" où
le site "en ligne" irait chercher l'article "en local" ; donc c'est un cas
où il faut faire du "push".
#3: La mise a disposition d'articles (A -> tous)
Permettre a chacun d'offir l'export de son article pour que tout
autre site SPIP puisse le recuperer et l'integrer facilement.
absolument
Certainement moins utile dans un premier temps, mais peut etre
interessant pour vraiment partager des infos (notamment en
contexte de risque de censure).
Censure ou publication d'un même article sur plusieurs sites : ça faisait
partie du programme politique initial
1) Un nouveau squelette par défaut fournit les "sources" d'un article
publié : le texte est copi-collable grâce à un truc comme
[(#TEXTE*|htmlspecialchars)].
Pourquoi pas.
2) dans l'espace privé, à l'endroit de "créer/modifier l'article", un bouton
"recopier un article" propose un formulaire :
URL du site [ ] (laisser vide pour recopier en local)
n° de l'article à copier [ ]
Non, c'est l'inverse qu'il faut : "créer une nouvelle version"
à partir de l'article original. De plus "créer une nouvelle
version" est plus utile que simplement "recopier l'article".
3) Quand on valide, l'article n du site distant est recopié en local dans
l'article qu'on est en train d'éditer, avec ses images, ses docs joints
(et leurs blablas), ses auteur(s) [y compris leur bio + logo], et ses
mots-clés (en option seulement) [ne pas oublier la balise #EXTRA]
Ca me semble peu intéressant de faire ça au niveau article.
La synchronisation de rubriques a plus de perspectives.
D'autre part l'aspect "import/export" est indépendant de la
problématique "versioning".
Philippe Gouillou wrote:
> #2: La synchronisation (partielle) de deux sites SPIP (A -> B)
> Envoie (push) ou recupere (pull) un article d'un site SPIP vers
> un autre. Utile pour tous ceux qui n'ayant pas ADSL creent un
> article d'abord en local (EasyPHP ou autre) avant de le mettre
> online.
>
> #3: La mise a disposition d'articles (A -> tous)
> Permettre a chacun d'offir l'export de son article pour que tout
> autre site SPIP puisse le recuperer et l'integrer facilement.
> Certainement moins utile dans un premier temps, mais peut etre
> interessant pour vraiment partager des infos (notamment en
> contexte de risque de censure).
La syndication des articles répond déjà aux besoins 2 et 3
quand il n'y a pas besoin de modifier les mirroirs.
JLuc
- La copie d'article depuis un autre site, ça n'a aucun intérêt sans une
gestion des droits, des possibilités (ou non) de modification, de
l'indication des sources. Il faudrait donc que le site d'origine indique
son choix d'un type de copyright (copie autorisée sans modifications; copie
et modifications autorisées...), cela pour chaque site/auteur/article...
Sur le site "copiant" il faudrait alors indiquer la source (les différentes
sources successives?) et bloquer selon les cas les modifications de cet
article.
Tu confonds le dispositif technique, qui permettrait de recopier un article,
et le dispositif juridique, qui condamnerait une recopie/modification non
autorisée. Ce mix n'est pas une bonne idée (cf. le débat sur les DRM). En
effet, si tu veux vraiment pomper un texte publié sur le net, tu peux le
faire indépendamment de l'existence de cette moulinette ; simplement, si
toi, en tant que webmestre, ne veux pas donner accès au source des articles
que tu as publiés, tu n'actives pas le machin (interface de configuration de
spip). Si tu veux donner accès au source en marquant en gros dans le texte
"ATTENTION CE TEXTE EST SOUS LICENCE DMZZ", tu changes le squelette pour
qu'il inclue cette mention...
Ah oui, et récupérer le(s) auteur(s) d'origine.
Ca je l'avais mentionné, of course. Et les docs attachés, et les images,
etc.
- Le seul intérêt pour une telle usine à gaz serait un minimum
d'automatisation. Genre synchroniser des rubriques entières d'un site dans
un autre site.
Ca n'est qu'un pas de plus, si on veut "recopier/synchroniser cette
rubrique"...
J'ai pas trop suivi l'affaire (sorry, coup de bourre ces temps ci mais
pour moi, dupliquer un article ou un bout de site, ça peut être intéressant
pour bosser dans son coin sur une copie locale, puis balancer ses modifs
sur le "vrai" site.
Pour ça, un dump de la base n'est pas la solution car on risque de bousiller
des forums, articles et autres trucs faits entre temps.
Dans ce contexte, l'idéal et donc de disposer d'un système
d'import/export d'articles, forums, rubriques ou autre à un format plus
souple que l'actuel xml utilisé dans le dump.
Personellement, dans ce genre de trucs, j'ai tendance à pencher pour
xml, mais des serialize avec quelques bricoles autour marcheraient peut
être aussi bien.
À+, Pif (qu'espère ne pas être à coté de la plaque)
pour moi, dupliquer un article ou un bout de site, ça peut être intéressant
pour bosser dans son coin sur une copie locale, puis balancer ses modifs
sur le "vrai" site.
Il y a ça, oui ; il y a aussi :
- la duplication d'un article à l'intérieur du même site permet de faire une
sorte de versioning ;
- et parfois quand on te demande l'autorisation de recopier un article, tu
n'es plus obligé de faire du copier-coller.
- par ailleurs la duplicaiton d'une rubrique n'est qu'une extension de ce
truc
#2: La synchronisation (partielle) de deux sites SPIP (A -> B)
Envoie (push) ou recupere (pull) un article d'un site SPIP vers
un autre. Utile pour tous ceux qui n'ayant pas ADSL creent un
article d'abord en local (EasyPHP ou autre) avant de le mettre
online.
Egalement très utile dans une optique professionnelle où on a un site de
production et un site de recette, cas ultra classique (et en plus
parfois même un site de développement pour le "bac à sable"). La
synchronisation manuelle est assez chiante à faire, surtout dès qu'on a
des documents joints.
les histoires de versioning de Nicolas & une relecture du projet initial de
SPIP & un besoin temporaire me ramènent vers notre histoire de "recopier cet
article". Voici ma suggestion du matin
Je saisis pas trop ta suggestion Fil.
Tu pourrais dire comment elle se relie au projet initial ?
Version 1.6.
Je retrouve un vieux problème de la 1.4. qui avait disparu :
après la validation d'un événement, on ne revient nulle part à l'écran (mais les changements ont correctement été enregistrés).
