Bifurcation depuis
spip / spip
638 validations de retard le dépôt en amont.
-
esj a rédigé
Début de la tâche #685. Spip propose à présent de fusionner la base courante avec les tables principales d'une sauvegarde, moins la tables des types de documents (qui est commune à tous les Spip car en lecture seule) et la table des auteurs (pour éviter les conflits sur les noms de login). Pour une base contenant déjà N rubriques, les secteurs (i.e. les rubriques de premier niveau) de la sauvegarde recevront un numéro supérieur à N, ainsi que leur sous-rubriques dont les champs id_parent et id_secteur seront eux aussi modifiés pour conserver l'arborescence. Idem pour les champs id_rubrique et id_secteur des articles, brèves, forums, et syndications de la sauvegarde. De meme, le champ id_groupe de la table des mots de la sauvegarde tiendra compte de la renumérotation des groupes de mots introduits lors de la fusion. Ce qui n'est pas (encore) fait: * l'importation des documents joints, et a fortiori la renumérotation des pseudo balises emb,doc,img dans les champs SQL; * l'importatio des logos; * la fusion des 2 tables d'auteurs, si nom et/ou login identiques * la fusion des 2x2 tables de mots et groupes de mots si meme titre * l'importation des tables auxiliaires (mots/auteurs d'un article...) En l'état actuel des choses, cette option de restauration est surtout intéressante pour qui possède une collection d'articles sur un site Spip (par exemple en local) et veut importer d'un bloc cette collection sur un autre. En jouant sur le statut d'administrateur restreint (on peut en créer une juste pour l'occasion), il est possible de n'importer qu'une partie d'une site d'origine, puisqu'une sauvegarde effectuée par un administrateur restreint est réduite aux rubriques qu'il administre. Egalement dans ce dépot: * la fonction _q() n'entoure plus de guillemets un nombre * en cas de sauvegarde avortée, on arrive à garder la connexion au site.
esj a rédigéDébut de la tâche #685. Spip propose à présent de fusionner la base courante avec les tables principales d'une sauvegarde, moins la tables des types de documents (qui est commune à tous les Spip car en lecture seule) et la table des auteurs (pour éviter les conflits sur les noms de login). Pour une base contenant déjà N rubriques, les secteurs (i.e. les rubriques de premier niveau) de la sauvegarde recevront un numéro supérieur à N, ainsi que leur sous-rubriques dont les champs id_parent et id_secteur seront eux aussi modifiés pour conserver l'arborescence. Idem pour les champs id_rubrique et id_secteur des articles, brèves, forums, et syndications de la sauvegarde. De meme, le champ id_groupe de la table des mots de la sauvegarde tiendra compte de la renumérotation des groupes de mots introduits lors de la fusion. Ce qui n'est pas (encore) fait: * l'importation des documents joints, et a fortiori la renumérotation des pseudo balises emb,doc,img dans les champs SQL; * l'importatio des logos; * la fusion des 2 tables d'auteurs, si nom et/ou login identiques * la fusion des 2x2 tables de mots et groupes de mots si meme titre * l'importation des tables auxiliaires (mots/auteurs d'un article...) En l'état actuel des choses, cette option de restauration est surtout intéressante pour qui possède une collection d'articles sur un site Spip (par exemple en local) et veut importer d'un bloc cette collection sur un autre. En jouant sur le statut d'administrateur restreint (on peut en créer une juste pour l'occasion), il est possible de n'importer qu'une partie d'une site d'origine, puisqu'une sauvegarde effectuée par un administrateur restreint est réduite aux rubriques qu'il administre. Egalement dans ce dépot: * la fonction _q() n'entoure plus de guillemets un nombre * en cas de sauvegarde avortée, on arrive à garder la connexion au site.