Travail d'expérimentation sur la mise en oeuvre d'un (presque) multi boutique

[Olivier from Madinina]

Je travaille à la mise en place d'un système multi boutique (via les sous domaines) qui attaque la même BDD pour une segmentation poussée de l'offre de ma boutique (t-shirts). L'objectif est d'avoir des sites très spécifiques à chaque famille générique de produits mais de conserver des fiches clients communes, des paniers communs et une facturation cohérente.

Il y a des modules existants (notamment ceux de Jeckyl) mais ils ne correspondent pas parfaitement à mes attentes.

Je vais indiquer ici la manière dont j'avance dans ce projet. A chacun d'en faire ce qu'il en veut en fonction de ses besoins et de ses compétences. Ce n'est pas un module, il n'y a pas de support, c'est juste la procédure que je vais utiliser pour tenter d'arriver à mes fins ! Par contre, si d'autres veulent se joindre à moi pour faire avancer le truc .... ils sont les bienvenus ;-)

Je pars du principe que je n'ai qu'une seule et unique intallation de PS et que tous mes sous-domaines y font référence via la directive DocumentRoot de chaque sous-domaine dans le httpd.conf.

J'ai 3 problèmes à résoudre :

1/ Affecter un thème à chaque sous domaine. C'est ok.

- Nomer chaque thème (dossier) de la même manière que l'url de votre serveur : SOUSDOMAINE.DOMAINE.TLD (ex: shop1.shop.fr)

- Selectionner le thème par défaut de votre boutique dans le BO (le thème du www)

- Modifier le fichier /config/setting.inc.php :

remplacer

define('_THEME_NAME_', 'votre thème');

par

if($_SERVER["HTTP_HOST"]=="sousdomaine.domaine.tld" || $_SERVER["HTTP_HOST"]=="SOUSDOMAINE.DOMAINE.TLD "){
   define('_THEME_NAME_', 'votre_thème_de_base');
}else{
   define('_THEME_NAME_', $_SERVER["HTTP_HOST"] );
}

2/ Affecter les catégories à un sous domaine principal (juste sous accueil) :

Pour l'instant, je penche pour une solution pas très propre mais qui pourrait fonctionner en attendant mieux :
Il faudra passer par une table qui mettra en relation les catégories et les sous domaines et créer un module pui permettra ce paramétrage dans le BO. Ensuite, il faudra modifier tous les modules qui affichent des listes de catégories/produits afin de s'appuyer sur cette table pour l'affichage.

Un autre axe de recherche serait de s'appuyer sur les "VIEW" de mysql. Il suffirait de créer une VIEW de la table category pour chaque sous domaine. Elle ne contiendrait que les catégories paramétrées dans le module add-hoc du BO et serait créée par lui. Puis substituer la table de base par la vue dans les modules concernés.

3/ Activer ou désactiver les modules selon les thèmes

C'est le problème principal pour le moment. J'ai besoin de ça parce j'utilise des thèmes qui n'ont pas le même nombre de colones. Il faut donc que je puisse activer/désactiver les modules en fonction du thème.

je n'ai pas d'idée pour le moment, mais je ne me suis pas penché sur le problème. Le solution des VIEW mysql pourrait peut etre s'appliquer ici aussi. A moins de cacher les modules dans les thèmes avec des "display: none" ce qui serait de loin le plus simple.



Voilà le topo. Je sais parfaitement que je part sur une voie qui va rendre les mises à jour très délicates. Je prend le partie de l'assumer et de ne plus mettre à jour jusqu'à la version de PS qui proposera le multi boutique. Je travaille sur la dernière version dispo, la 1.3.5 pour être le plus up-to-date possible.

Si des infos concernant la mise en oeuvre d'un multi boutique dans le core PS (date, version) peuvent être données par la team, ce serait sympa. Ca permettrait d'évaluer l'intérêt de partir su ce boulot. Il existe un thread qui en parle ... mais aucune précision n'est donnée.

[Olivier from Madinina]

Bon, il semble que les vues MySQL vont répondre parfaitement à toutes les attentes des points 2 et 3.

Il va falloir tout d'abord créer un sous domaine "maitre" qui travaillera directement suir les tables PS. Lui seul aura accès à tous les produits, toutes les catégories et tous les modules. Ce sous domaine ne sera accessible que pour le BO.

Ensuite, chaque sous domaine FO accèdera non pas aux tables mais à des vues MySQL. Ces vues seront strictement identiques aux tables PS pour tout ce qui ne concerne ni les produits, ni les catégories, ni les modules. Pour ces dernières, les requetes de création des vues seront générés par le module du BO qui gèrera les correspondances produits/catégories - sous-domaines et modules - sous-domaines. Ces vues doivent respecter les conditions les rendant modifiables (ce qui ne semble pas être un problème dans la mesure ou ces vues auront exactement la même structure que les tables PS). Elles seront nomées comme les tables PS mais avec un prefixe qui sera le HTTP_HOST de chaque sous domaine. Ca permettra d'appliquer un filtre dans le /conf/setting.inc.php comme celui de la sélection du thème.

Il est clair que cette solution va alourdir significativement l'impact de mysql sur les ressources du serveur. Il faudra probablement, si la base est grosse, prévoir un serveur mysql dédié et l'optimiser au niveau du cache et de la config mysql. Pour le moment, je table sur 300 à 500 références max avec une fréquentation inférieure à 500 visites/jour. Ca devrait largement passer sur un dédié d'entrée de gamme.

Il se fait tard, premiers tests demain ! Je crains néanmoins quelques maux de tête !!!

[J. Danse]

Bonjour,

Ce projet est, avant tout, réalisable même si il posera le soucis suivant: les mises à jours seront très dures à réalisées, si pas impossible.

D'autant plus du moment où les demandes sont fortement différentes à la base de Prestashop.

Pour l'info, nous avons réalisés cela en quelques temps, temps que l'on peut estimer à deux mois environ, avec un développeur.

Le résultat est visible ici: http://www.typhus.eu

Actuellement, nous n'avons qu'un thème mais les couleurs sont modifiables selon le partenaire.

De même, actuellement, les modules ne sont pas encore paramétrables selon le dit partenaire, mais cela ne saurait tarder.

Le tout est, aussi, de gérer la partie administrative pour que chaque employé puisse avoir des droits identiques à un autre, mais ne puisse s'oqp que d'une boutique, par exemple.

C'est un projet qui vaut le détour et qui évolue sans cesse, croyez moi !

[Olivier from Madinina]

Le travail a bien avancé.

Un module BO permet de définir les associations suivantes :

Sous-domaine -> Thèmes
Sous-domaine -> Catégories
Sous-domaine -> Modues

Le fonctionnement est basé intégralement sur les vues mysql et la création de 3 tables pour les associations plus une pour le paramétrage. Les données restent donc cohérentes et la structure de PS est conservée.

Seul problème qu'il sera difficile à contourner, la modification du setting.php. Les déclarations de constantes PHP étant , par définition, permanentes il n'est pas possible de les redéfinir et il faut donc intervenir au moment de leur déclaration. La modification consiste à annoter les déclarations du préfixe de BDD et du theme, et d'inclure un script PHP qui détermine ces constantes en fonctions des infos stockées dans les tables de configuration.

Les mises à jours de PS seront possibles, le module vérifiant la structure de la BDD de manière automatique. Il faudra juste veiller à bien réinstaller le setting.php et le script inclu.

Le principe général est validé et les premiers test sont en cours (et encourrageants). Je devrais pouvoir faire une démo d'ici une grosse semaine.

[cedric0508]

Tu as pu faire une démo ?

[Olivier from Madinina]

On a abandonné la solution et privilégié des boutiques indépendantes.

Le soucis touche à la gestion du compte client dans le FO. Le compte client étant commun à toutes les boutiques, les historiques de commande étaient aussi commun. Pour fonctionner, il fallait passer (pour ces pages de FO) par une boutique générique contenant toutes les catégories et les produits pour qu'ils apparaissent. Il fallait aussi passer par là pour le panier et la procédure de commande. Cette boutique générique ayant un design indépedant, il y avait une vraie incohérence du point de vue utilisateur, et ce n'est pas propice au besoin de confiance pour le e-commerce ....


Mais en dehors de ce problème, la partie technique était parfaitement opérationnelle ...

[botmez]

3/ Activer ou désactiver les modules selon les thèmes

C’est le problème principal pour le moment. J’ai besoin de ça parce j’utilise des thèmes qui n’ont pas le même nombre de colones. Il faut donc que je puisse activer/désactiver les modules en fonction du thème.

je n’ai pas d’idée pour le moment, mais je ne me suis pas penché sur le problème. Le solution des VIEW mysql pourrait peut etre s’appliquer ici aussi. A moins de cacher les modules dans les thèmes avec des “display: none” ce qui serait de loin le plus simple.

Voilà le topo. Je sais parfaitement que je part sur une voie qui va rendre les mises à jour très délicates. Je prend le partie de l’assumer et de ne plus mettre à jour jusqu‘à la version de PS qui proposera le multi boutique. Je travaille sur la dernière version dispo, la 1.3.5 pour être le plus up-to-date possible.

Si des infos concernant la mise en oeuvre d’un multi boutique dans le core PS (date, version) peuvent être données par la team, ce serait sympa. Ca permettrait d‘évaluer l’intérêt de partir su ce boulot. Il existe un thread qui en parle … mais aucune précision n’est donnée.

J'ai lancé un topic ici pour ce point: http://www.prestashop.com/forums/viewthread/111487/integration/changement_de_theme_et_cache_de_modules

Possibilité de faire cela avec un CSS -> display:none ?