Hack lourd sur OpenCart

[Malaiac]

Ayant choisi OpenCart un peu par défaut, faute de solutions convaincantes ailleurs, j'ai beaucoup de développement supplémentaire à réaliser dessus.
Cette question s'adresse à ceux qui ont fait des customisations extensives, que ce soit coté front ou back office :
Quelle méthode ?

1/ Travailler les développements comme des extensions ? + : permet de mettre à jour au prix d'une réinstallation des dévs, + propreté du code, - réinstaller les extensions à chaque mise à jour (sachant que les vmod je suis pas fan, puisqu'on est à la merci d'un changement de code dans le core)
2/ Commencer par convaincre l'équipe OpenCart d'ajouter une API de "hooks" qui permettraient aux développements de se comporter commes des plugins ? Sachant qu'il y a déjà vmod qui remplit (à moitié) ce besoin
3/ Hacker direct dans le noyau, et faire le sacrifice de futures mises à jour ?
4/ Dépouiller le noyau de tout ce qui est spécifique pour recoder la partie view ?
5/ Autre ?

[Canou]

6/ Moi je vais à la plage

[Malaiac]

Mais euh

Sur opencart.com, on m'a conseillé de regarder du coté de Override Engine, qui permet de remplacer les classes OpenCart

[gob33]

Override Engine ne permet pas de faire de petits ajouts simples comme vQmod, il faut subclasser.
Procéder comme pour des extensions: toutes les modifs du source dans des vqmods.
Les API dans des fichiers modèles. Les nouveaux fichiers à part.
Inutile de procéder comme dans osCommerce pour refaire une nouvelle usine à gaz, c'est du MVC, il suffit de bien séparer ce qu'on veut faire.

[lucho69]

bonjour
je ne sais pas si vous êtes eCommerçant ou développeur, mais choisir un moteur de eCommerce par défaut est triste
Nous sommes nous mêmes une agence Web, nous utilisons les grands moteurs ecommerce du marché avec une préférence très nette pour Opencart : propreté du code, qualité du référencement, disponibilité des modules et j'en passe (bref vous l'aurez compris, opencart on aime )

Bien que techniciens, connaissant bien le codage, nous évitons au maximum de modifier le coeur du système, sinon pourquoi s'appuyer sur un moteur ???
90% de nos modifs sont dans /view/
Et bien si nos modifs dépassent les réglages de TPL, un VQMOD bien utilisé permet de modifier les scripts php de /model/ de /controller/ voir même de Javascript
clairement, VQMOD est à contrôler à chaque mise à jour de versions
Mais contrairement à certains moteurs de eCommerce, qui gèrent les hooks mais qui sortent une version corrective toutes les semaines, Opencart est très stable, j'ai encore des clients en 1.4.7 (upgrade effectués uniquement pour les points sécurité)

Par contre le besoin de développement spécifique pour un projet, quand aucun module ne répond, oui , on peut taper dans le dur, et là le choix Opencart se justifie
On a par exemple en projet un site de vente de produits 100% customisés où le client construira son produit (dans la mode) , on ne voulait pas de modules existants custo en Flash (pb iPad iPhone) , un développement bien construit en gardant bien trace de toute les modifs ne touche pas par exemple au coeur du processus de commande Opencart, on ne touche que à la mise en panier de produits

je vais surement horrifier les eCommerçants qui me lisent, mais un besoin non déjà répertorié, voir développé, est au final assez rare, le eCommerce est mature ...
on a lancé le concept du "boucher drive" basé sur Opencart, une vingtaine de boutiques vont rejoindre, toute la partie "spécifique" qui au final n'est que la mise à dispo du colis, on s'est appuyé sur un module parfait de livraison sur calendrier avec un bon contact avec son développeur.
modif coeur = zéro

[gem56]

Après avoir effectué un hack lourd (et sale, hyper pressé) touchant autant la partie cliente que admin, préparation de panier paysans hebdomadaire à retirer dans des dépots, 3 interfaces d'admins suivant les profils des producteurs (hyper simplification pour les +60 ans !) et délégation de droits pour certaines manips, squeeze du checkout en 6 phases (pas de livraison, pas de paiment, une seule phase de choix de dépot), commandes modifiables par le client tout le long de la semaine, gestion de produits vendus au kilo (prix estimé à la commande, et produit pesé à la préparation des commandes), mailling client et producteurs avec pièces attachées, modifications des tables product, order, order_product, manufacturer et ajout de 8 tables.
Dès que j'ai un peu de temps j'espére aussi finir le portage sous postgresql et ajouter des transactions au moins sur les mises à jour de commandes.
Tout ça pour dire que je vais quand même faire un diff entre ma version (partie d'une 1.5.4.1) avec les versions suivantes pour intégrer les mises à jour qui m'intéressent !

[lucho69]

en effet, en te lisant, tu as fait fort dans les fonctionnalités

tiens nous au courant sur tes avancées... la fonction : 3 admin suivant les profils "Producteurs" est une option hyper intéressante ...