Module multi boutique pour 1.5 ?

[prestaetmoi]

Bonjour,

 

Je possède une boutique depuis plus d'un an et je viens de passer en 1.5 pour exploiter le multi boutique soit au total 3 (dans le même groupe).

En voulant configurer ma dernière boutique, j'ai voulu modifier l'ID de mon bloc fan et ça me modifie également sur toutes mes boutiques. Idem pour un blog que j'ai acheté sur ADDONS la semaine dernière, quand je désactive un article, ça le désactive sur toutes les boutiques alors même que sur le back, je suis bien sur LA boutique que je souhaite configurer :-(

 

Avez-vous une explication pour permettre de gérer UN module sur plusieurs boutiques ?

 

Merci d'avance et longue vie à la communauté

Eddy

[DevNet]

Bonjour,

 

Le mode multiboutique n'est pas un projet initial dans PrestaShop. Il est arrivé de façon très bancale dans la 1.4, comme une obligation de "surcouche" de développement pour répondre à une minorité d’intéressés. Ce qui signifie qu'un mode multiboutique qui devrait aujourd'hui être la base même d'un fonctionnement, ne représente dans le noyau qu'un ajout de développement sur un ensemble de code qui contient déjà son propre passé.

 

Ceci en résulte malheureusement d'une non prise en charge de cette technique pour tous les "addons/plugins/hack". Si le mode multiboutique avait été présent dès le départ du projet PrestaShop, il aurait été pris automatiquement en compte dans tous les projets annexes se ratachant à PrestaShop.

 

Et ceci aurait évité aux développements de modules de s'en préoccuper. Nous sommes arrivé aujourd'hui à se questionner énormément sur l'utilité d'un multiboutique sur un PrestaShop, et surtout d'en porter les modules pour qu'ils l'utilisent.

 

Passer les modules en multiboutique demande de revoir totalement le code, et c'est énormément d'investissement. Le problème est que PrestaShop ne touche que très peu de grands groupes et professionnels ayant l'utilité de ce multiboutique. En terme de rapport investissements / clients, autant vous dire tout de suite que c'est n'est pas du tout rentable pour l'instant.

 

L'idéal aurait été une prise en charge totale du multiboutique dès le départ, rendant n'importe quel module automatiquement multiboutique, puisqu'il serait géré par le noyau lui même pour cette fonction. Hors... on est loin de ce concept, et encore aujourd'hui il est à la charge de chaque projet de développement, de reproduire ce mécanisme de multiboutique, avec beaucoup d'investissement, et surtout au risque de tout refaire 6 mois après car le noyau change encore.

 

Cordialement

[olea]

@DevNet

Il me parait normal que toutes les fonctions ne soient pas présentes dès le début d'un projet. C'est bien pour cela que des nouvelles versions sortent : pour inclure les nouvelles fonctions.

 

Passer les modules en multiboutique demande de revoir totalement le code, et c'est énormément d'investissement.

Je ne suis pas du tout de cet avis. Les équipes de prestashop ont pensé les multi-boutiques pour que l'évolution des modules soit la moins coûteuse possible. Ca n'est pas une refonte totale des modules.

La problème c'est qu'on n'a pas de doc pour savoir faire au mieux.

 

et, et encore aujourd'hui il est à la charge de chaque projet de développement, de reproduire ce mécanisme de multiboutique, avec beaucoup d'investissement, et surtout au risque de tout refaire 6 mois après car le noyau change encore.

Ca parait logique que chaque module doivent évoluer pour s'adapter aux nouvelles fonctions.

La 1.5.2 est considérée comme stable. Je doute que des évolution du core sur la ligne 1.5 oblige à tout refaire que tu semble le suggérer.

 

@Prestaetmoi,

Les modules qui n'ont pas été adaptés pour le multi-boutique continuent à fonctionner dans un contexte multi-boutique en proposant 1 seule configuration commune à toutes les boutiques.

C'est effectivement un problème, à mon sens, d'avoir des modules dits compatibles 1.5 dont on ne connait pas le comportement dans un environnement multiboutique.

Il faut se tourner vers le support addons ou vers les développeurs concernés pour obtenir une configuration dufférenciée par boutique

[jeckyl]

Les modules qui n'ont pas été adaptés pour le multi-boutique continuent à fonctionner dans un contexte multi-boutique en proposant 1 seule configuration commune à toutes les boutiques.

C'est effectivement un problème, à mon sens, d'avoir des modules dits compatibles 1.5 dont on ne connait pas le comportement dans un environnement multiboutique.

Il faut se tourner vers le support addons ou vers les développeurs concernés pour obtenir une configuration dufférenciée par boutique

 

Salut,

 

Perso je trouve qu'un module qui n'est pas compatible multi boutique ne devrait pas être considéré comme compatible 1.5 ... mais bon cela n'engage que moi.

[olea]

Perso je trouve qu'un module qui n'est pas compatible multi boutique ne devrait pas être considéré comme compatible 1.5 ... mais bon cela n'engage que moi.

C'est aussi mon avis.

Ou tout au moins, on devrait connaitre le niveau de compatibilité avec ce multi-boutique, qui est la fonction phare de cette 1.5

[DevNet]

Si cette fonctionnalité était si "importante", elle devrait être exploitée par le coeur / modules sans même en parler.

 

Avoir l'option multiboutique c'est une très bonne chose, mais l'avoir en surcharge de projet sur l'existant, c'est moins bien.

 

Actuellement, chaque développeur doit de son côté, travailler tous ses algos en fonction de ça s'il veut rendre son module multiboutique.

 

Hors, si c'était vraiment l'intention de PrestaShop, et l'avenir de ce que doit être le eCommerce de demain, je ne comprends pas pourquoi ce n'est tout simplement pas le moteur principal de PrestaShop, plutôt qu'une simple "fonctionnalité".

 

Inclure ceci réellement dans le moteur éviterait aujourd'hui de se poser la question de savoir si telle ou telle fonctionnalité est multiboutique ou pas. Les modules ne devraient même pas être développé en pensant qu'il doit s'adapter au multiboutique, puisque ça devrait être au moteur de gérer ça.

 

Je ne comprends pas pourquoi il faut ajouter nous même la gestion d'un champ multiboutique à chacune de nos réquêtes sql alors qu'il suffirait que ceci soit pris en charge par le noyau lui même. La Classe DB est la pour ça, et est en mesure de le faire.

 

Comme je l'ai dit, une telle fonctionnalité ne doit pas être simplement la pour l'utiliser et la subir, elle fait partie d'une vraie réflexion en amont.

 

Si PrestaShop souhaite vraiment faire le multiboutique le fer de lance de son noyau, alors plutôt que d'avoir aborder l'amélioration par :

- PrestaShop propose la mise en place d'une boutique eCommerce, avec la possibilité d'utiliser le multiboutique

Il aurait plutôt fallu prendre cette orientation :

- PrestaShop propose la mise en place d'un projet de multiboutique, avec la possibilité de n'utiliser qu'une seule boutique.

 

Toute la différence est là ! Et surtout tous les projets de développements qui s'y rattachent en subissent les conséquences.

 

A cela s'ajoute une nouvelle donnée qui n'est pas négligeable pour une agence web :

- Le multiboutique n'intéresse qu'une minorité d'utilisateur PrestaShop, puisque cette fonctionnalité est aujourd'hui utilisée et souhaitée par des entreprises à fort potentiel commercial, qui ne représentent que 5% des commerçants ayant opté pour PrestaShop.

 

Donc personnellement, je suis entièrement d'accord avec toi Olea pour dire que c'est un passage obligé, et que cette évolution est la bien venue. Mais il ne faudrait pas que cette évolution soit reposer sur les épaules des développeurs de modules, mais qu'elle soit définitivement présente dans tous les traitements, module ou pas.

[coeos.pro]

d'où l’intérêt de spécifier pour les modules disponibles pour les versions 1.5 de prestashop :

 

compatible multi boutique : vous pouvez enregistrer 1 configuration par boutique.

 

Et même si les utilisateurs exploitant le multi-boutique est une minorité, l'argument "multi-boutique" est un argument de poids pour prestashop donc à mon avis il faut rester dans cette optique et mettre en avant le multi-boutique pour les modules réalisés.

[prestaetmoi]

Je ne suis pas d'accord, le multi boutique a été conçu pour gérer plusieurs boutique mais pas seulement pour avoir un facilité de gestion pour gérer toutes les boutiques sur UN seul back non, mais pour gérer les stocks en commun et ça, c'est 90% de mon utilisation car ça permet de gérer plusieurs boutiques avec un stock mutualisé et ça fonctionne relativement bien.

Maintenant, le soucis se porte sur les modules, quand on dit qu'un module est compatible 1.5, il doit être compatible MULTI BOUTIQUE et si c'est pas le cas, dans ce cas, un entreprise créatrice de modules, ne doit pas s'affranchir de ce titre !

 

Je pense que PRESTA doit faire un effort aussi en apportant une aide précieuse à ces développeurs, en prévoyant par exemple, lors de l'installation d'un module, de choisir sur quelle boutique on veut l'installer ? Comme ça, on a des modules qui s'installent pour chaque boutique et qu'on peut donc personnaliser individuellement

[J. Danse]

Bonsoir,

 

Je ne vais pas apporter grand chose au débat du multi-boutique et surtout de la fonctionnalité/surcharge qui a été développé mais je vais mettre mon grain de sel concernant les modules et le développement.

 

Normalement, je dis bien normalement, les modules qui sont compatible 1.4 et qui utilise assez simplement l'objet "Configuration" pour stocker les paramètres du module sont compatible 1.5 et qui plus est multi-boutique. Par exemple, un module qui stockerait simplement un ID (Google Analytics, Virement bancaire, ...). Tout ceci est automatique, sans aucune intervention de développement.

 

La classe ObjectModel instaure un procédé assez similaire: pour être mutli boutique, la propriété statique "definition" (tableau de valeurs, pour rappel) comprendra désormais une valeur 'multilang_shop' => true ou encore 'associations' => array('type' => 'shop') [Attention, il me reste encore une petite analyse à faire pour en être bien certain !). Et, donc, il s'agit d'introduire une nouvelle table ayant comme nom l'objet suffixé de _shop , également.

 

Je vais essayer de faire une bonne grosse analyse des possibilités qui sont présente pour l'ensemble des données (Configuration, Module, Classe, FrontController, AdminController, ...) lors de la création d'un module 1.5 directement. De même, je verrais comment rendre un module 1.4 compatible sans trop d'efforts.

 

Et, bien entendu, tout ça sera mis directement dans la doc, niveau technique !

 

N'hésitez donc pas à demander des précisions sur tel ou tel spécificité, ... Si ce n'est pas encore dans la doc', ça le sera ! ;-)

[Djolhan]

Pour ma part, en tant qu'agence, je vois d'un assez mauvais oeil l'arrivée du multiboutique pour plusieurs raisons.

 

1 - un module est normalement vendu comme UNE licence pour UNE boutique, avec le multiboutique, cela devient une licence globale. Donc, perte franche au niveau des ventes théoriques.

 

2 - Le multiboutique, cela veut dire, plusieurs boutiques, plusieurs designs et donc, plusieurs intégrations possibles. Donc, potentiellement, plus de support à effectuer auprès de tous les clients qui n'ont pas beaucoup de compétences en intégration.

 

3 - Un module simple comme GG analytics est effectivement facile à upgrader pour suivre les versions, mais un module de blog qui demande des fonctions bien plus complexes n'est pas une partie de plaisir à modifier lorsque l'on passe d'une version 1.4 à une 1.5, et encore pire quand on doit palier au défauts de conceptions de cette dernière mouture. Je pense notamment à l'absence de controleur pour la gestion du rewrite qui sera bientôt implémenté pour la 1.5.3, mais qui du même coup, demandera encore du temps pour réadapter le module à ces fonctionnalités qui changent constamment. C'est le principe des rustines en quelque sorte, rien de génial en terme de développement. Et je ne parle même pas de la rétrocompatibilité avec les 1.5.1 et 1.5.2 et ne pas oublier non plus, les petits bouts de css modifiés qui impactent aussi le coté intégration.

 

Alors, pour moi, le multiboutique, c'est encore d'autres bugs de plus pour les modules les plus complexes et c'est des coûts de développement toujours plus élevés quand les utilisateurs demandent des modules de moins en moins chers et pire, avec la possibilité de les mettre sur 2, 10, voir 100 boutiques pour un prix unique...