Lorsque je suis amené à travailler sur VirtueMart, solution libre de e-commerce basé sur le CMS Joomla, je suis contraint de modifier directement le code original afin de l’adapter à mes besoins.
Le code perd alors toute compatibilité avec la version communautaire.
En dehors de cela, en raison de cette absence de modularité, il est difficile d’échanger des modifications de Virtuemart à la communauté, sans passer par l’approbation de la communauté VirtueMart. La communauté perd ainsi en « dynamisme ».
En conséquence, j’ai émis une suggestion sur le forum officiel de VirtueMart.
Techniquement, le support de plugin sous VirtueMart ne me semble pas très difficile, la notion de plugin étant déjà présente sous Joomla.
Il faut tout d’abord commencer par créer un nouveau dossier de « plugin ». Pour cela, il suffit de rajouter un dossier « virtuemart » dans le répertoire « plugins » de Joomla.
Par la suite, il faut définir un ensemble d’événements durant lesquels les extensions pourront être déclenchées.
Je propose dans un premier temps (car j’aurai personnellement besoin de ces événements) :
- insertion de produits (onProductInsert),
- modification de produits (onProductUpdate),
- suppression de produits (onProductDelete),
- insertion de catégories (onCategoryInsert),
- modification de catégories (onCategoryUpdate),
- suppression de catégories (onCategoryDelete),
- passage de commande (onCheckoutProcessed).
Une fois, les événements définies, il faut modifier le code source du composant Virtuemart, pour déclencher les événements des plugins aux moments opportuns.
Par exemple, pour déclencher l’événement « onCategoryInsert », lors de la création d’une catégorie, il faut rajouter le code suivant dans la méthode « add » de la classe « ps_product_category ».
$vmLogger->info(
$VM_LANG->_('VM_PRODUCT_CATEGORY_ADDED').
': "'.vmGet($d,'category_name').'"'
);
/* Ca commence */
JPluginHelper::importPlugin('virtuemart');
$mainframe->triggerEvent(
'onCategoryInsert',
array($category_id)
);
/* Ca termine */
return true;
?>
En fait, la méthode importPlugin, a des fins d’optimisation devrait plutôt être chargée au démarrage du composant virtuemart, en front et en back office.
Ensuite, la création de plugins pour VirtueMart devient possible.
Évidemment, le plugin doit avoir pour « folder » ou « group » la valeur « virtuemart ».
Voici un exemple d’interception de l’insertion de catégories :
// no direct access
defined( '_JEXEC' ) or die( 'Restricted access' );
jimport( 'joomla.plugin.plugin' );
/**
* Generate a category tree for performance
* optimization (skeleton of a future plugin)
*
*/
class plgVirtuemartCategorytree extends JPlugin
{
function plgVirtuemartCategorytree(&$subject, $config) {
parent::__construct($subject, $config);
}
function onCategoryInsert($category_id) {
echo '<h3>'.$category_id.'</h3>';
}
}
?>
Ce plugin se content d’afficher l’identifiant de la catégorie insérée. Ce plugin, en l’état n’a bien entendu aucun intérêt. C’est juste une démonstration illustrant le fonctionnement des plugins.
Si vous êtes intéressé par cette modification, merci d’appuyer ma demande sur le forum.
Avez-vous? déjà modifier le moteur de recherche de virtuemart pour qu’il puisse aussi chercher dans les article de joomla??
Non, je ne l’ai pas fait. Désolé
thanks!
im sorry what was the version of your joomla?
It was first made with Joomla 1.0.
La modularité de virtuemart est un TRES gros problème.
Sans vouloir casser du sucre sur le dos des développeur du composant (que j’utilise sur plusieurs sites), il faut avouer que le principe de virtuemart est très loin de celui de joomla. La chose la plus « choquante » c’est la présence de publicité vers le composant payant d’export/import de fichier csv.
En outre, comme défauts majeurs, on peut citer le grotesque de la fonction catalogue, le traitement des demandes d’information très difficilement customisables, le moteur de recherche extrêmement flou, et j’en passe et des meilleurs.
Ta proposition me semble être une très bonne idée à mon sens et on peut regretter l’absence totale d’intérêts des développeurs pour ta proposition sur le forum virtuemart.
Vu ton niveau, un fork de virtuemart serait nettement plus judicieux que d’attendre des modifications de structure qui ne viendront pas.
Bon courage.
J’aimerais justement développer un plugin pour générer une alerte auprès de l’admin dès que le stock atteind un certain seuil.
Je sais que cela correspond déjà à la feature 1321 (https://dev.virtuemart.net/cb/issue/1321). Je ne sais pas trop où ça en est, je n’ai pas contacté gregdev, mais surtout j’en ai besoin pour la version actuelle de Virtuemart, la 1.1.3, pas la 1.2 à venir !
Je pense donc que tes évènements pourraient être très utiles.
)
Par contre, je pense qu’ils devraient être désactivables dans le cas où le webmaster n’en aurait pas besoin.
Ainsi à chaque :
JPluginHelper::importPlugin(‘virtuemart’);
$mainframe->triggerEvent(
‘onCategoryInsert’,
array($category_id)
);
je l’entourerais d’un if sur une variable spécifique (ou pas, c’est à voir !) à l’évènement. Cela permettrait de ne pas lancer de limiter le nb de triggers. Idéalement, il faudrait trouver un moyen pour éviter l’appel du if systématiquement, une sorte de DEFINE mais pour un bout de code. (un équivalent au préprocesseur du C finalement
Concernant Virtuemart, le code est ce qu’il est. Dès qu’un projet a un peu d’historique, on voit forcément des bouts pas très propres. Maintenant quand je vois le travail effectué, je dis bravo.
Concernant un fork, pourquoi pas c’est un avantage du libre. Mais ça serait dommage d’en user un peu trop rapidement. Je ne connais pas vraiment la mentalité des mainteneurs, vous ont-ils paru autistes ou hostiles sans raison à des évolutions ?
@serval2412 : Par définition, grâce au fonctionnement classique de Joomla, un plugin peut être activé ou non par le webmaster.
i would like to know if you have some exemple for i see the result of your core hack? tank you.
Hi. Sorry, but it is not visual.
Bonjour
Je développe un joomla / virtuemart pour un site associatif
J’ai besoin d’avoir 2 champs personnalisés (adresse de livraison à partir d’une liste déroulante, et la date de livraison avec un calendrier cliquable – ou une liste déroulante), et ces champs ne sont pas des champs par produits, mais des champs
demandés pour chaque commande, par exemple, je commande 2 choux et du pain, alors je dois dire où et quand je veux ma commande
J’ai été en mesure d’inclure les champs dans
templates/checkout/get_final_confirmation.tpl.php,
mais aucune idée de comment:
- stocker ces données dans la base de données existante ou une nouvelle table
- Envoyer ces données dans l’e-mail
J’ai beaucoup surfé et lu, sans trouver de réponse à ma question
Auriez-vous avoir la gentillesse de m’aider, au moins pour me donner une piste de départ?
Un grand merci d’avance