Forum

Bonjour,

Je pose la question à propos du module Pages, mais je suppose qu'on pourrait l'étendre à tous les autres modules. Est-ce qu'il est possible, en passant par ftp de faire passer des fichiers d'un site PHPBoost à un autre, hébergé ou non sur le même serveur, de façon à éviter le laborieux copier-coller ? Je n'ai pas voulu essayer de peur de conséquences irréparables. Je préfère demander des avis autorisés plutôt que d'avoir à réparer .

ques fichiers veux tu transférer?
Toutes les pages créées sont enregistrées dans la bdd donc je ne vois pas trop le but...

Détailles plus s'il te plait

Je pose donc la question autrement :

1) Tu possèdes plus d'un site PHPBoost (chez le même hébergeur ou pas) ;
2) Tu t'aperçois que tu as créé une partie de l'arborescence de l'un de tes sites qui aurait plus sa place sur un autre ;
3) Tu as bien sûr la possibilité de reproduire cette arborescence à l'identique sur le site de destination puis de copier un à un le contenu de chaque fichier sur le site de départ et de le coller dans le fichier correspondant sur le site d'arrivée ;
4) Mais tu aimerais connaître un moyen d'obtenir le même résultat de manière plus sûre, et surtout plus rapide, en déplaçant les dossiers et fichiers en question sur ton espace en y accédant en ftp ;
5) Avec un web manager tu fais ça aisément si les données sont contenues dans une structure traditionnelle de dossiers et de fichiers ;
6) Mais comment faire si les données sont contenues dans une base de données comme c'est le cas avec PHPBoost ? Est-ce qu'il est prévu, dans une version ultérieure, de gérer ça depuis l'interface d'administration, ainsi que c'est déjà possible pour les opérations de maintenance et de sauvegarde de la base de données ?

J'ajoute que je suppose que cela doit déjà être possible dans le cadre de phpMyAdmin à l'aide des fonctions d'import et d'export, y compris en provenance et à destination d'autres supports que PHPBoost, mais ce serait bien que l'application propose de manière interne à l'interface d'administration de PHPBoost et sécurisée une solution de déplacement simplifiée qui se limite à PHPBoost.

Édité par LMdF Le 23/03/2008 à 14h05

ben a part faire une copie de la table de la bdd je ne vois pas trop comment faire, p'etre quie ben.popeye aura une autre solution.

Tu peux restaures des tables précises, mais prendre seulement par exemple 2 article dans toute la table je crois pas, attendons de voir...

C'est en effet cela ma question .

En gros tu voudrais exporter qu'une partie des pages, comme une catégorie par exemple ?

Oui, ou même quelques pages, voire une seule, depuis un module vers le même module, mais situé sur un autre site, qu'il se trouve chez le même hébergeur ou chez un autre. Bref, disposer de la même mobilité entre sites qu'à l'intérieur d'un module. C'est facile en ftp, ou même avec un web manager, quand on a affaire à une application qui ne gère que des fichiers texte, mais ça se complique quand les données sont enfermées dans un SGBD, comme c'est le cas pour PHPBoost avec MySQL.

Ce n'est pas possible pour le moment.



On ne peut exporter que la totalité d'un module. Si par exemple tu as un module article et que tu veux importer des pages d'un autre module article, il va forcément y avoir des problèmes.



Supposons pour cela que tu ais sauvegardé de la base de données, les articles qui t'intéressent. Ils sont alors stockés sous forme de SQL dans un fichier texte. Si tu fais exécute ce fichier, normalement, çà devrait tout rajouter (les nouveaux articles) à ton autre site. Le problème est que phpboost comme tout système utilisant une base de données gère les relations entre les articles et les catégories via un système de clé (c'est un identifiant numérique) et là, rien ne dit que la clé n'est pas déjà utilisé. Il risque donc d'y avoir plein d'erreurs, et au final, tu n'auras pas les nouveaux articles et tu en auras peut-être même détruit.



Donc, pour le moment, il n'y a pas de moyen pour n'exporter qu'une partie de la base de données à part bien sûr la méthode que t'utilises, à savoir la copie manuelle, qui je te l'accorde est rébarbative.



Seulement, il faut bien se dire que la copie partielle n'est normalement pas une opération à faire, la copie totale, elle permet la sauvegarde ou la migration du site. Une copie partielle, va elle dupliquer les données, il faut donc éviter à tout prix.

Merci horn pour ces précisions qui confirment ce que je pensais.







Quand tu dis « pour le moment », est-ce que ça dépend de la programmation de PHPBoost ou du fonctionnement de la base de données ? Autrement dit, est-ce qu'au niveau du CMS il y aurait théoriquement moyen - j'imagine moyennant une grosse programmation qu'il n'est pas possible de fournir en ce moment - de pallier ce que ne prévoit pas la base de données ou est-ce qu'il faut attendre que celle-ci le propose parmi ses fonctionnalités ?

Ce problème, ne vient pas de phpboost, il est lié à la façon dont les données sont représentées dans les systèmes de gestion de bases de données.

Il n'existe donc actuellement pas d'outils d'Import/Export d'une partie seulement de la base de données. C'est un développement extrêmement lourd à mettre en place, et par conséquent, il n'est pas à l'ordre du jour.

Cependant, il n'est pas à exclure que dans les versions futures de phpboost, un tel système d'Import/Export soit intégré dans certains modules.

Voilà!

Le problème se situe particulièrement sur les identifiants de chaque entrée qui sont uniques. Si on copie un morceau de table, on peut par exemple avoir déjà la page numéro 12 et la réimporter ce qui est carrément impossible. Cela pose donc de gros problèmes qui, comme le disait horn, ne dépendent pas que de nous.

C'est parfaitement clair. Merci à tous les contributeurs.

A cela s'ajoute des dépendances avec les membres et les commentaires, les identifiants ne correspondront pas forcément et les collisions risquent d'être nombreuses..
De plus ce genre de cas ne se pose que pour un nombre extrêmement réduit de personnes. Cela correspond davantage à un développement spécifique, qui de plus n'est pas si évident que ça..