Hello,
J'effectue en ce moment des tests de la sauvegarde partielle par rubrique.
1) ca à l'air top. Pratique, ergonomique, moderne.
2) je débute les tests mais j'ai l'impression que dans mon cas, les auteurs ne sont pas exportés.
Ma table spip_auteurs contient un minimum d'infos : id_auteur nom bio.
Pas de mail pas de statut, etc. C'est peut etre cela qui perturbe SPIP.
BoOz
En effet, l'identification des auteurs entre les deux sites est sujette à bien des variantes, j'ai préféré ne rien faire: les articles deviennent anonymes lorsqu'ils sont fusionnés avec une autre base d'auteurs.
Bref, tu peux prendre ton cas pour une généralité 
Committo,Ergo:Sum
Committo,Ergo:sum wrote:
BoOz a écrit :
Committo,Ergo:sum wrote:
2) j'ai l'impression que dans mon cas, les
auteurs ne sont pas exportés.En effet, l'identification des auteurs entre les deux sites est sujette à bien des variantes, j'ai préféré ne rien faire: les articles deviennent anonymes lorsqu'ils sont fusionnés avec une autre base d'auteurs.
Ok, alors je vais bosser sur un patch qui se fondera sur le nom.
Tu as des écueils à me signaler avant que je ne pète tout ?
Identifier des auteurs à partir de 2 bases distinctes
est assez balaise si ya pas des contraintes fortes ou des contrôles
lors de la création des auteurs.
Comme veut le dire ESJ je crois, ça dépend beaucoup
des protocoles de création d'auteurs/situations/sites/bases.
Surtout pour des situations ou l'import fait partie d'un fonctionnement
normal, et où ça doit être répété, ce serait bien que cette fonction
de "reconnaissance d'identité" soit soit paramétrable
(genre cases à cocher reconnaître par l'email identique
ou par le nom identique (ou par ...une sqlexpr ?))
ou surchargeable.
JL
JLuc wrote:
Surtout pour des situations ou l'import fait partie d'un fonctionnement
normal, et où ça doit être répété, ce serait bien que cette fonction
de "reconnaissance d'identité" soit soit paramétrable
(genre cases à cocher reconnaître par l'email identique
ou par le nom identique (ou par ...une sqlexpr ?))
ou surchargeable.
Oui, on pourait commencer par les traiter comme les mots-clés, c'est à je crois en matchant sur le nom, et en prevoyant une surcharge pour plus tard.
C'est ce que je vais tenter sauf contre ordre ici.
Ca me perturbe un peu d'avoir une fonctionnalité incomplète proposée par le core.
Le bug sur le rubricage me fait aussi hésiter à travailler cela sur le plugin snippet, qui gere deja l'export d'articles + auteurs + mots-clés (en matchant le nom / titre) par rubrique.
Mais il faudra rajouter le traitement des <imgxx>, donc pas immédiat et redondant.
Je ne sais pas trop quoi faire en fait.
BoOz
Le bug sur le rubricage me fait aussi hésiter à travailler cela sur le plugin snippet, qui gere deja l'export d'articles + auteurs + mots-clés (en matchant le nom / titre) par rubrique.
C'est vrai que les besoins sont très proche et qu'une solution unique pourrait être intéressante.
Il faudrait peut-être découper en une API d'interfaces CRUD unitaires sur les différents types de données, qui pourraient alors être utilisées de manière universelle. Les formats XML du plugin Snippets peuvent servir de base de travail.
N'y-a-t-il pas déjà eu des travaux de ce type, notamment pour les plugins qui permettent de faire un miroir de deux sites ?
-Nicolas
Il faudrait peut-être découper en une API d'interfaces CRUD unitaires
Je trouve que CUTBI (c'est une très bonne idée).
Il me semble que inc/modifier est ce qui s'en rapproche le plus, mais
il n'offre que la partie U de ton acronyme (Create / Read / Update /
Delete) ?
-- Fil
Fil a écrit :
Il faudrait peut-être découper en une API d'interfaces CRUD unitaires
Je trouve que CUTBI (c'est une très bonne idée).
Il me semble que inc/modifier est ce qui s'en rapproche le plus, mais
il n'offre que la partie U de ton acronyme (Create / Read / Update /
Delete) ?
C'est bien la signification de l'acronyme. Une telle interface, quelle que soit l'implémentation, devrait être un point de passage obligé pour tout accès aux données, ce qui assure de ne gérer des contrôles et actions déclenchées qu'en un seul endroit.
Ce n'est pas forcément un chantier simple, mais il va à priori dans le bon sens pour améliorer la cohérence d'ensemble.
Une fois que l'on aura cela, il sera sans doute simple d'ajouter une couche XML-RPC, Atom Publishing Protocol (APP), REST, etc. pour des accès distants ce qui permettra encore plus d'enrichir SPIP, avec des outils externes.
-Nicolas