Le principe de ces modules est que ça crée des clients particuliers (à qui on donne une clé d'accès). Il peuvent alors voir/créer/modifier leurs produits dans une page dédiée et l'admin valide. Ils peuvent également suivre leurs commandes/sav etc. Il faut créer un entrepôt par vendeur et associer ses produits à son entrepôt (ce qui permettra de calculer correctement les frais de port)

Il y aurait beaucoup à faire sur cette classe (piquée à Joomlà à l'origine) mais cela dépend aussi de comment vous avez paramétré vos préférence de recherche. Si vous voulez principalement matcher sur les titres/auteurs mettez un poids à 0 sur les descriptions par exemple. Vous pouvez aussi forcer "mot exact" mais tant pis pour ceux qui font des fautes de frappe...

@herve_02 Maintenant peut être qu'on gagnerais pas grand chose, Mariadb a peut être un système de cache..

@eolia Le soucis avec le système actuel est que toutes les images doivent avoir les même dimensions et pour des livres ce n'est pas possible, il y a du portrait, du paysage, des carrés et donc la génération automatique des images fait qu'on se retrouve avec des bandes blanches partout pour que ca rentre dans le format. oui je sais png et la transparence, je vais refaire l('image de mon "client") Le script devient tellement compliqué avec des if partout que je me demandais si ce ne serait pas plus simples avec quelques options imagemagick. J'ai tellement pris l'habitude en 25 ans de linux à tout faire par des scripts et des outils que c'est devenu une sorte de seconde nature. Pour les photos des auteurs(fournisseurs) , comme c'est le même dossiers (et pas sous dossiers) j'ai fais mon script avec imagemagick (3 lignes). pour les produits comme c'est 3/4/5/6/3456.jpg je suis pas chaud avec un script qui parcours... pour le moment. J'ai un apache-php-mariadb sur un debian et dans mes trucs j'utilise exec dès que je peux. le code est petit très court et très rapide puisque du compilé. En ce moment s'execute un script qui va watermarquer 2770 fichiers avec les infos de la base de données sur chaque page c'est moins de 200 lignes de code, y compris lecture de la base de données, lecture de la taille des pdf le positionnement centré haut et bas à X mil. du bord de pages de watermarck, la gestion de la police, sa taillle et sa couleur, individualisé sur toutes les pages et compression des fichiers. Et sur un fichier pdf de 20 pages de texte cela prends 1.5 secondes. On peut même dans ps_configuration enregistrer les options à passer aux scripts. avec les options "de bases" dès l'install. Mon idée est pourquoi écrire du code qui réinvente en php (ou autre, c'est pareil avec python) ce que le système sous-jacent fait en 3 lignes. MAIS c'est vrai que cela implique un(ou des) systèmes sous-jacent qu'il faut connaître et pratiquer. delivengo utilise ghostscript. mondial relay (je crois) à besoin de soap et curl (peut être à travers php) je me souviens pas, je fais trop de choses. Les choix sont toujours difficiles à faire et quand les choix impliquent d'autres c'est encore plus compliqués. Mais de mon point de vue, il vaut mieux utiliser les outils qui existent déjà et se concentrer sur d'autres choses que de réinventer la roue. Maintenant je comprends parfaitement le soucis de rétro-compatibilité avec l'existant et avec les modules qui s'installent et attendent probablement certains choses... Pour l'exemple du contrôleur produits et l'image médium. si on en n'a pas besoin, de cette image, il faut l'avoir qd même sinon ca ne marche pâs je me suis arraché les cheveux un paire d'heures avant de comprendre pourquoi j'avais perdu toutes les images, juste parce que pour gagner du temps et de la place, j'avais décoché les images dont je ne me servais pas. et je ne comprenais pas puisque les images devaient se régénérer toutes seules (il m'a aussi fallu du temps pour comprendre avec les rewrites d'apache et ma conf qui ne permettait pas les .htaccess) . comme medium n'existait pas c'est comme s'il n'y avait pas d'images. Mais je ne veux rien révolutionner, juste arriver à faire ce qu'on me demande et si possible sans bouzin ou les lignes se comptent en paquet de 1000. Je vais devoir des catalogues thématiques pdf.. se sera bien entendu latex qui le fera et mes scripts écriront du code latex. qui compilera tout seul les pdf. C'est dur d'être "chef" et la critique étant super facile... mais mon "client" est ravi du choix de phénix, C'est un super produit et je veux aider autant que je peux. je commencerais (à part ce que je dois faire pour que cela fasse ce qu'on me demande) par gérer les warning php et alléger les errors_logs . C'est un tout petit début.

D'ailleurs je vais rajouter le timestamp $img_time (comme pour les images catégories) car si on met à jour le fournisseur 1 avec une nouvelle image, celle-ci s'appellera toujours 1.jpg Dans le thème: <img src="{$img_sup_dir}{$supplier.image|escape:'html':'UTF-8'}-medium_default.jpg?rand={$img_time}" alt="" width="{$mediumSize.width}" height="{$mediumSize.height}" />

@eolia Oui on n'aura plus les balises mais on aura perdu la "sémantique", ce qui est un bien grand mot puisque ce n'est que de la mise en forme pour le cas du CD si tout le temps on a cd titre titre C'est facile mais ce n'est pas toujours le cas.. je vais m'arracher les cheveux (ce qu'il en reste) Disons que le l'on peut faire des "modèles" et utiliser 'ou pas' les modèles. Ceux qui vendent des cd, des dvd, des produits dérivés, peut faire un modèle cd, un modèle dvd et laisser le reste en "normal" ensuite si on fait tourner et qu'il n'y a rien à faire on a juste un return après le document.querySelectorAll(tag) s'il ne ramène rien, vue comment presta tourne, cela ne se verra même pas. je vais le mettre en œuvre sur notre boutique. je vais "hardcoder" dans le javascript la mise en forme et la récup des tags et laisser le javascript dans le bon dossier d'un module product par exemple. cela devrait le faire L'avantage de cela est qu'il est moins chronophage de rentrer ses produits et cela "oblige" à être sémantique. on est certains d'avoir la même mise en forme partout. c'est un peu du html sémantique

@eolia cooollll de toute façon tout sera mieux que le presta 1.7.7.x qui gère la boutique actuelle. Le BO est cassé en mille morceaux (il parait que la migration 1.4 -> 1.7.7 a été violente et douloureuse... peut être plus de 20 modules de tous zorizons) parfois lorsque l'on active ou désactive un module, on arrive sur une page .json pour faire tomber en marche comme je voulais la nouvelle version de paypal (oui je suis un malade mental d'avoir mis a jour un module sur une boutique au BO un peu cassé (il manque des icones cela casse toute la mise en page, il faut plus de 10 secondes pour acceder à une page de config) donc pour le faire tomber en marche j'ai du lire du code et taper directement dans ps_configuration et tenter de trouver les bonnes variables. tout le reste sera un parcours de santé

@eolia oui c'est pour cela que je travaille à l'ancienne mais à la mode phénix,; et si je suis "chiant" c'est parce que j'aime bien faire les choses et je préfère demander le temps que j'acquiers l'expérience de bien faire, pour peut être, qui sait proposer aussi du code à reverser. là je travaille dans mon coin à ajouter une barre de catégorie en horizontal, sans faire de module mais en utilisant le module blockcatégorie du thème de base. avec le moins de modifs possibles... ensuite je viendrais me faire humilier ici en expàosant ce que j'ai fait en tout cas largement merci du code que je vais étudier avec la révérence d'un padawan, ce qui va me permettre de gagner de longues heures j'ai aussi commandé un bouquin bootstrap et jquery.... lorsque j'avais fait mon site de suivi d'instruction en famille j'avais codé tout seul mon ajax, mais à rome on fait comme les romains.

J'ai peut-être répondu trop vite dans mon dernier message car je ne suis finalement pas sûr de comprendre; De toute manière si un module veut implanter son propre controller front l'url simplifiée aura TOUJOURS la forme /module/<nom-du-module>/<nom-du-controller> et c'est d'ailleurs case sensitive