CMS Multi-Sites

[shenron76]

Bonsoir,

Je suis sur un projet de développement d'un CMS "maison" permettant de gérer plusieurs sites Internet hébergés sur un même serveur dédié mais sur des ftp différents.

Tout ce qui suit est hébergé sur un même serveur dédié partitionné en plusieurs ftp.

FTP n°1 : jadministre.com

Contient le CMS et tout le système de gestion

FTP n°2 : unsiteinternet2.com (géré par webmaster2)

FTP n°3 : unsiteinternet3.com (géré par webmaster3)

FTP n°4 : unsiteinternet4.com (géré par webmaster4)

...

Sur jadministre.com (FTP n°1), que je gère, une interface permet à webmaster1, webmaster2 et webmaster3 de se connecter à leur espace admin et d'administrer leurs sites unsiteinternet2.com, unsiteinternet3.com et unsiteinternet4.com.

Pour cela, je suis le seul à avoir les droits d'accès à un module sur jadministre.com permettant de créer des modules de gestion des différents sites.

Pour créer un module, je stocke dans une BDD les champs de formulaire qu'il doit contenir, le type de vérification à effectuer à la saisie de ces champs (on doit saisir un texte ou une url, une adresse email...). Par exemple les champs de formulaire de type text sont stockés dans al table "chps_txt". En résumé tout est dynamique dans le CMS que je tente de concevoir, de la gestion du contenu d'un site à la création sur-mesure de ce système de gestion.

Ce qui me paraît complexe c'est au niveau de l'affichage du contenu sur unsiteinternet2.com, unsiteinternet3.com et unsiteinternet4.com dans la mesure où chaque donnée est contenue dans une entrée d'une table. Il faut générer énormément de requête pour afficher le contenu souhaité.

Par exemple, je suis webmaster2, je me connecte sur jadministre.com je veux donc gérer l'affichage d'un lien sur unsiteinternet2.com. Un lien s'affichant sous la forme <a href="xxx" title="yyy">zzz</a> , il me faut donc un champs de formulaire pour gérer le contenu de "href", un champ pour gérer le contenu de "title", un champ pour gérer le texte dur du lien. Comme ce module de gestion est généré dynamiquement, les champs de formulaire qui s'affichent sont donc stockés dans la BDD: une entrée qui contient le champ de type text pour le "href", une pour le "title" et une pour le texte en dur.

Côté Front-Office (sur unsiteinternet2.com), il me faut donc 3 requêtes pour afficher dynamiquement mon lien :

- une requête SELECT pour extraire le "href"

- une requête SELECT pour extraire le "title"

- une requête SELECT pour extraire le texte en dur

Avez-vous une autre alternative ?

Est-ce possible ?

Ce type de système peut-il poser problème en ce qui concerne la sécurité ?

Que pensez-vous de ce type de "super-CMS" ?

Y-en a-t-il déjà sur le marché ?

Avez-vous compris ce que je voulais réussir à faire ?

Merci d'avance de me permettre d'avancer sur ma réflexion...

[paolodelmare]

C'est évidemment possible. Je développe ce type de solutions pour certains clients qui ont plusieurs sous domaines ou domaines.

Ça finit par générer pas mal de requêtes, mais ça reste très raisonnable, et la génération des pages reste très rapide. De plus, un système de cache et les optimisations de bases donnent d'excellents résultats.

Par contre, j'évite de gérer différents clients sur un même backend. Ça complique la gestion de la sécurité, notamment avec des sites qui offrent des fonctionnalités parfois très différentes.

Mais ça se fait couramment sur toutes les plateformes de blogs.

Wordpress par exemple, dispose d'une option multisites (anciennement dans wp mu)

[shenron76]

Enfin quelqu'un qui semble comprendre ma problématique :-)

Merci pour ta réponse,

Ça finit par générer pas mal de requêtes, mais ça reste très raisonnable, et la génération des pages reste très rapide. De plus, un système de cache et les optimisations de bases donnent d'excellents résultats.

Qu'entends-tu par "pas mal" de requêtes ? Comment développes-tu la structure de tes BDD, chaque champs qui doit s'afficher côté back-office est-il stocké dans une entrée d'une de tes tables ?

Par contre, j'évite de gérer différents clients sur un même backend. Ça complique la gestion de la sécurité, notamment avec des sites qui offrent des fonctionnalités parfois très différentes.

Qu'entends-tu par back-end ?

J'aimerais discuter avec toi de ce sujet ...

Dans l'attente,

Bonne journée

[Ernestine]

Salut,

Personnellement, ce que je ferais, c'est une seule et unique table appelée "champ". Puis en dur dans le code, un jeu de constantes par exemple :

define(CHAMP_TYPE_TEXT, 0);
define(CHAMP_TYPE_ENTIER, 1);
define(CHAMP_TYPE_DOUBLE, 2);

ou même (plus précis) :

define(CHAMP_TYPE_MAIL, 3);
define(CHAMP_TYPE_URL, 4);
define(CHAMP_TYPE_CODEPOSTAL, 5);

etc...

Et dans la table "champ", je mettrais une colonne "type_champ" (de type INTEGER), qui, pour chaque entrée, recevrait la valeur de l'une des constantes définies dans le code. Ca permettrait de stocker la totalité des champs de tous les formulaires de tous les sites dans une seule table, et de savoir, pour chaque champ, de quel type il s'agit (et par là même de savoir quel type de vérification effectuer, etc)

Plutôt qu'un jeu de constantes, il serait peut-être même encore plus judicieux de créer une table à part entière dans la base de données (une table "type_champ") et sur la table "champ" faire une clé étrangère pour la mettre en relation avec la table "type_champ".

[paolodelmare]

Premièrement, je développe avec un framework python (django), je ne te serais pas d'une grande aide au niveau implémentation php.

Je travaille en définissant des blocs de contenus dans une classe. Par exemple, un bloc texte va contenir le texte proprement dit, un classe et un id css.

Chaque page contient des blocs de contenus agencés selon le bon vouloir du rédacteur. Les pages peuvent contenir des champs communs (les méta par exemple, ou le statut de publi).

Le tout est traduit en db (par le framework) avec des relations adéquates.

Chaque type de champ dispose de ses propres validateurs (c'est dans le framework).

Donc on se retrouve avec une table par type de bloc de contenu.

Le design pattern est un mvc (en toute rigueur c'est un modele template view)

Quand une requête est reçue, le script détermine dans une liste de patterns d'url la plus adaptée, lui fait correspondre une vue.

La vue va piocher dans la db en fonction du modèle les données nécessaires et alimente un template .

Par backend je désignais l'interface d'admin (auto générée par le framework)

Modifié 10 Février 2011 par paolodelmare