J'ai essayé la fusion de deux sites.
Ça marche plutôt bien, je suis parti d'un site avec que des rédacteurs pour y placer dedans la sauvegarde d'un autre site avec quelques rédacteurs et des rubriques, des articles, des mots-clefs.
Le problème, c'est qu'il m'a mélangé les rubriques, il les à prises dans le désordre, or, mes squelettes se basent sur quelques numéros, 1,2 et 15
or, même si ma rubrique 1est bien la 1, celle qui avait l'ID 15 à pris l'ID 4.
Ça m'ennuyrait de modifier le nom de mes squelettes juste pour ça, alors qu'il n'y avait as de colisions parce que le site d'accueil était sans contenu (à part des rédacteurs)
Bon, ce n'est pas plus génant que ça, j'ai fait un test en local juste pour voir ce que ça donnerait.
Je reste très content du résultat.
J'ai essayé la fusion de deux sites.
Ça marche plutôt bien, je suis parti d'un site avec que des rédacteurs pour y placer dedans la sauvegarde d'un autre site avec quelques rédacteurs et des rubriques, des articles, des mots-clefs.
La première chose à dire c'est que les auteurs ne sont pas importés: comme il peut y avoir conflit dans les noms de login, c'est ingérable.
Le problème, c'est qu'il m'a mélangé les rubriques, il les à prises dans le désordre,
Il n'y a pas de notion d'ordre de rubrique dans Spip, et heureusement sinon la fusion serait impossible.
or, mes squelettes se basent sur quelques numéros, 1,2 et 15
ce que tu sembles déplorer n'est donc pas l'ordre mais la renumérotation (ce qui est moins grave).
or, même si ma rubrique 1est bien la 1, celle qui avait l'ID 15 à pris l'ID 4.
Ça m'ennuyrait de modifier le nom de mes squelettes juste pour ça,
Par principe ce n'est pas bon de mettre de tels numéros en dur dans les squelettes: fondamentalement ça veut dire que tes squelettes ne sont pas diffusables car liés à une installation précise ayant une histoire précise. Si 15 a été transformé en 4, c'est que tu as créé tes rubriques dans un certain ordre que tes squelettes connaissent implicitement; c'est trop peu portable, il faut repérér les rubriques par leur titre.
Le problème, c'est qu'il m'a mélangé les rubriques, il les à prises dans le désordre,
[...]
or, mes squelettes se basent sur quelques numéros, 1,2 et 15
ce que tu sembles déplorer n'est donc pas l'ordre mais la renumérotation (ce qui est moins grave).
or, même si ma rubrique 1est bien la 1, celle qui avait l'ID 15 à pris l'ID 4.
Ça m'ennuyrait de modifier le nom de mes squelettes juste pour ça,
Par principe ce n'est pas bon de mettre de tels numéros en dur dans les squelettes: fondamentalement ça veut dire que tes squelettes ne sont pas diffusables car liés à une installation précise ayant une histoire précise. Si 15 a été transformé en 4, c'est que tu as créé tes rubriques dans un certain ordre que tes squelettes connaissent implicitement; c'est trop peu portable, il faut repérér les rubriques par leur titre.
Merci d'avoir testé cela dit.
Committo,Ergo:Sum
Je n'ai peut-être pas tout suivi, mais
Que deviennent les notations rubrique-15.html, rubrique=15.html ou article-15.html. ?
Envisage-t-on de positionner un pointeur dans la rubrique ou l'article # de la numérotation MySql pour lui indiquer d'utiliser tel ou tel élément ?
Claude
Bonjour
Oui, Claude, c'est bien ça le problème.
Pour régler ce problème de numérotation, il faudrait que je renomme rubrique-15.html en rubrique-4.html
En le faisant, j'aurai des sites avec des squelettes identiques mais pas le même nom.
Mon objectif était de pouvoir mettre à jour mes squelettes de sites sans me prendre la tête
Puisque les auteurs ne sont pas importés (c'est ce qu'il me semblait, sans l'avoir vérifié), je vais faire l'inverse, et importer d'abord le site avec son contenur (rubriques, articles, mot-clefs) puis fusionner avec la sauvegarde qui n'a que des rédacteurs (mais un forum interne bien rempli)
Je n'ai peut-être pas tout suivi, mais
Que deviennent les notations rubrique-15.html, rubrique=15.html ou
article-15.html. ?
Personnellement je n'ai jamais utilisé ça, avant meme de me préoccuper de fusions de sites, parce que ça m'a toujours paru trop frustre. Il y a deux manières de faire les choses de manière indépendante de la numérotation:
- surcharger la fonction PHP déterminant le squelette à utiliser, ce qu'on fait depuis déjà longtemps et c'est finalement stabilisé en définissant une fonction public_styliser dans mes_fonctions.php ou mes_options.php
- définir les squelettes principaux comme en incluant d'autres en fonction des titres. Par exemple si on a autant de squelettes que de secteurs, de meme nom que ceux-ci, le squelette rubrique devient:
on peut éventuellement appliquer un filtre sur #TITRE pour convertir les caractères problématiques (slash en particulier) évacuer les balises éventuelles etc.
Je n'ai peut-être pas tout suivi, mais
Que deviennent les notations rubrique-15.html, rubrique=15.html ou
article-15.html. ?
[...]
- définir les squelettes principaux comme en incluant d'autres en fonction des titres. Par exemple si on a autant de squelettes que de secteurs, de meme nom que ceux-ci, le squelette rubrique devient:
on peut éventuellement appliquer un filtre sur #TITRE pour convertir les caractères problématiques (slash en particulier) évacuer les balises éventuelles etc.
Committo,Ergo:Sum
Bonjour
<INCLURE{fond=#TITRE}>
J'utilise #TITRE dans des critères de boucles, et je n'avais aps pensé à cet utilisation...
C'est la solution que je vais utiliser, elle est pratique et permet de se passer de l'ID rubrique.
Je ne vais pas forcément utiliser #TITRE, mais surement #TEXTE d'un mot-clef, enfin, je verrais... parce qu'il faut gérer les sous rubrique et que je ne veux pas répéter le mot-clef pour chaque sous rubrique.
Je vais y réfléchir, mais ça me semble une bonne solution (pour mon petit problème)
on peut éventuellement appliquer un filtre sur #TITRE pour convertir les caractères problématiques (slash en particulier) évacuer les balises éventuelles etc.
Moui, c'est peut etre portable d'un certain point de vue, mais pas forcement robuste car si tu veux renommer un secteur t'es coincé.
Ce n'est qu'un exemple, mais il est rare de changer un élément aussi structurant dans un site; partant, on sait qu'il faudra aussi renommer le squelette et ce ne sera pas fréquent.
Il manque définitivement la notion de mot cle technique pour ce genre de probleme...
Dans d'autre situations j'utilise effectivement des mots-clés. Pour "dire" qu'ils sont techniques, il me suffit de dire qu'ils ne sont attribuables par personne, meme pas les admins: on donne ce droit à l'install pour les affecter aux rubriques nécessitant des mises en pages spécifiques, et après on gèle en retirant le droit. C'est ce que j'ai trouvé de plus portable.
Moui, c'est peut etre portable d'un certain point de vue, mais pas
forcement robuste car si tu veux renommer un secteur t'es coincé.
Il manque définitivement la notion de mot cle technique pour
ce genre de probleme...
Oui, mais ça c'est vraiement pas difficile à coder en plugin, suffit
d'adapter gestion_metas par exemple, en une heure tout compris si tu sais
pas comment ça fonctionne, tu as ton champ supplémentaire.
* cedric.morin@yterium.com tapotait, le 14/02/2007 10:13:
Moui, c'est peut etre portable d'un certain point de vue, mais pas forcement robuste car si tu veux renommer un secteur t'es coincé.
Il manque définitivement la notion de mot cle technique pour ce genre de probleme...
+1 !
Sachant que le plugin cfg permet déjà de s'affranchir de mot clef technique de paramétrage global au site, il ne reste plus que les paramétrages locaux (à un article, une rubrique, un site, un auteur...).
En particulier, un administrateur m'a dit dernièrement que pour certains mots clefs techniques, il aurait besoin que seuls certains admins puissent les affecter aux articles...
on peut éventuellement appliquer un filtre sur #TITRE pour convertir les caractères problématiques (slash en particulier) évacuer les balises éventuelles etc.
Moui, c'est peut etre portable d'un certain point de vue, mais pas forcement robuste car si tu veux renommer un secteur t'es coincé.
Ce n'est qu'un exemple, mais il est rare de changer un élément aussi structurant dans un site; partant, on sait qu'il faudra aussi renommer le squelette et ce ne sera pas fréquent.
Il manque définitivement la notion de mot cle technique pour ce genre de probleme...
Dans d'autre situations j'utilise effectivement des mots-clés. Pour "dire" qu'ils sont techniques, il me suffit de dire qu'ils ne sont attribuables par personne, meme pas les admins: on donne ce droit à l'install pour les affecter aux rubriques nécessitant des mises en pages spécifiques, et après on gèle en retirant le droit. C'est ce que j'ai trouvé de plus portable.
pas bete !
Après, il faut penser à les exclure dans les boucles (je suppose que {minirezo=non} marche).
moi j'utilisais obligatoire pour ca ...
Mais en fait, je passe maintenant aux mots clés sur les groupes de mot et du coup, je prend le probleme dans l'autre sens :
- mon groupe n°1 est specifique : il determine les types de groupes de mots (technique, public ... rang1, rang2 ..).
- dans mes squelettes, je n'utilise que les groupes ayant un mot clé specifique
- je sais gerer une arborescence de mots, ou plus exactement de groupe/mots en specifiant un "rang" pour les groupes.
Mais bon, il faudrait quand meme bien un petit flag "public/privé" sur les mots pour pouvoir securiser les squelettes sans faire de jointures (bien qu'en général, c'est pas tres grave qu'on puisse voir les affectations des mots clés techniques...).
après, pour les histoires de droits d'attribution, un bon moyen serait d'ajouter une table spip_auteur_groupe_mot et de baser les autorisations dessus.
ca ferait un joli plugin... mais les autorisations ne sont pas vraiment prevues pour.
Il y a aussi moyen de faire un truc tres fin (quel auteur peut affecter quel mot), en dédiant les mots clés sur les auteurs à ca, mais ca donnerait un truc super lourd à gerer.
