Un blog sur les logiciels libres

Des articles basés essentiellement sur VirtueMart, Joomla, Talend...

janvier 30 2009

Améliorer les performance de Virtuemart : Constat

Tagged Under : , ,

Dans le cadre professionnel, il m’est arrivé à moi et à mes collèges de créer des boutiques en ligne, basées sur Joomla / VirtueMart, proposant plus de 15000 produits.

Après avoir réalisé des modifications nous permettant de tenir un tel catalogue, nous avons voulu les proposer à la communauté via le forum officiel de VirtueMart. Malheureusement, étonnement, notre demande a été ignorée pendant plusieurs mois.

L’un des problèmes majeurs, était le nombre de requêtes SQL nécessaires aux parcours de l’arborescence VirtueMart.

L’arborescence produit est stocké dans la table #__vm_category_xref dont voici le schéma simplifié :

  • category_parent_id : identifiant de la catégorie parent
  • category_child_id : identifiant de la catégorie enfant

Imaginons que votre site soit découpé en catégories de la manière suivante :

  1. CMS
    1. Joomla
      1. Joomla 1.0
      2. Joomla 1.5
      3. Joomla 1.6
    2. Drupal
    3. EZ Publish
    4. Typo 3
  2. E-Commerce
    1. VirtueMart
    2. Magento
    3. OS Commerce

Ce découpage est bien en dessous de l’arborescence que nous avons à gérer pour nos sites e-commerce.

Pour récupérer, l’arborescence et l’afficher il nous faut d’abord récupérer les catégories sans enfants (« CMS » et « E-Commerce »). Pour chacune de ces catégories, il faut voir si ces dernières ont des enfants et les afficher. Cet algorithme continue de manière itérative…

On voit bien que le nombre de requêtes SQL nécessaire est exponentiel. Certes, il y a le cache, mais ce dernier n’est pas toujours utilisable (ie : en back office).

Pire, imaginons que la page affichant la catégorie « CMS » doivent afficher l’ensemble des produits contenus dans la catégorie « CMS » et dans ces enfants directs et indirects, le tout trié par prix.

Ce problème explique en partie la lourdeur de l’arborescence du back-office par défaut de VirtueMart , lorsque le catalogue produit est volumineux.

J’expliquerais en détail la méthode que nous souhaitons soumettre à la communauté dans un prochain billet.

janvier 29 2009

Comment rendre VirtueMart plus souple ….

Tagged Under : , ,

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 ».

<?php

$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 :

<?php
// 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.

Artisteer - Joomla Theme Generator