Cette article s’attache à donner plus de détails sur le fonctionnement du Setup proposé par Magento. Il ne s’agit pas ici du Setup d’installation de Magento mais de la facilité offerte par Magento pour installer et mettre à jours vos modules (ainsi que ses propres modules).
Avant d’aller plus loin, vous devez absolument avoir lu l’article qui présente ce mode Setup ainsi que l’article sur le modèle EAV.
Accéder au Setup sans le versionning
C’est très pratique le versionning (à chaque changement de version de votre module, Magento vérifie s’il n’y a pas un script à lancer) mais cela peut être très contraignant durant la phase de développement, lorsque justement vous être en train de tester votre script: vous devez constamment jongler entre les 2 versions associées à votre script (version initiale, version cible) pour que Magento exécute votre script.
Pour ma part, je recrée les conditions du script dans une méthode Action d’un contrôleur de test, que je peux ainsi appeler à loisir, sans passer à chaque fois par la modification de version. Une fois le code de mon « script » validé à travers les appels à cette méthode Action, je peux alors créer le script de mise à jour correspondant, qui – lui – dépendra du versionning.
Voici le template de ma méthode Action permettant de recréer les conditions d’un script de Setup:
public function testAction() {
$install = new Mage_Eav_Model_Entity_Setup('<modulename>_setup');
...
}
Je n’ai pas réussi à faire plus simple… 
Notez que que je recrée ici un environnement de Setup nécessaire pour gérer des entités EAV. Si vous n’avez pas besoin de gérer d’entités de ce type, vous pouvez utiliser la classe Mage_Core_Model_Resource_Setup à la place de Mage_Eav_Model_Entity_Setup (la seconde héritant de la première, vous pouvez aussi ignorer cette remarque et utiliser la classe Mage_Eav_Model_Entity_Setup quelque soit le type d’entité que vous souhaitez gérer).
Voilà! A partir de là, tout ce que vous mettrez dans cette méthode Action devra être recopié dans votre script de Setup !
Créer/Modifier/Supprimer un attribut
Le modèle EAV, personnellement, je trouve ça excellent (oui, je sais, il est aussi bourré d’inconvénients mais c’est très pratique quand vous devez gérer des entités qui ont des attributs qui diffèrent en fonction … de l’entité). Mais ce n’est clairement pas aussi facile à gérer qu’une entité basée sur le modèle Relationnel.
Dans un modèle relationnel, lorsque vous souhaitez modifier la définition d’un attribut d’une entité, vous savez où chercher: vous modifiez directement les caractéristiques SQL du champ représentant votre attribut dans la table représentant votre entité. Easy!
Mais dans un modèle EAV, la définition de votre attribut est éclaté sur plusieurs tables: eav_attribute principalement, puis 1 table dépendant du type de l’attribut. Je ne parle pas ici des attributs de type « select » ni des groupes d’attributs… La modification de la définition de votre attribut est donc plus délicat. Heureusement, Magento met à disposition quelques méthodes bien pratiques.
Créer un nouvel attribut
Votre entité existe déjà mais vous devez lui ajouter un nouvel attribut? Rien de plus simple avec la méthode suivante:
$install->addAttribute("catalog_product", "attribut_test", array(
'type' => 'decimal',
'label' => 'Attribut Test',
'input' => 'text',
'global' => Mage_Catalog_Model_Resource_Eav_Attribute::SCOPE_STORE,
'required' => false
));
Le tableau passé en paramètre est exactement le même que celui présent pour chaque attribut de la fonction getDefaultEntities de votre classe de Setup (voir Article sur le modèle EAV): il définit l’ensemble des configurations possibles pour votre attribut.
Ici, nous avons ajouté un attribut « attribut_test » dans l’entité « catalog_product » (vous devriez le voir avec la console d’administration), de type « decimal » : cela veut dire qu’à chaque ajout d’un produit possédant cet attribut, une nouvelle ligne sera créée dans ‘catalog_product_entity_decimal‘.
Modifier un attribut
Oups, mon attribut ne devait pas s’appeler ‘attribut_test‘ mais ‘attribut_patate‘!
Pas de souci: utilisez la fonction updateAttribut:
$install->updateAttribute("catalog_product", "attribut_test", array(
"attribute_code" => "attribut_patate",
"frontend_label" => "Attribut Patate"
));
Votre attribut devrait maintenant avoir l’identifiant ‘attribut_patate‘ (regardez dans la console d’administration).
Ce que je trouve dommage avec cette méthode, c’est que le tableau que l’on transmet en paramètre n’est pas tout à fait le même que celui qu’on utilise pour la méthode addAttribute: les noms des paramètres ne sont pas les mêmes. Ici, il s’agit en fait du nom des champs (colonnes) de la table ‘eav_attribute‘.
Dans l’exemple, j’ai dû utiliser le paramètre ‘frontend_label‘ alors que lors de la création de l’attribut, le paramètre s’appelait ‘label‘. Il y a un petit souci de cohérence…
Modifier le type d’un attribut
La méthode updateAttribut peut être aussi utilisée pour changer le type de votre attribut – puisque le type est un champ de la table ‘eav_attribute‘. Plus précisemment, il s’agit du champ ‘backend_type‘:
$install->updateAttribute("catalog_product", "attribut_patate", array(
"backend_type" => "int"
));
Désormais, notre attribut ‘attribut_patate‘ est désormais de type int au lieu de decimal => cela signifie que tous les futurs enregistrements de produits ayant cet attribut auront leur données stockées dans la table ‘catalog_product_entity_int‘ au lieu de la table ‘catalog_product_entity_decimal‘.
Attention: si des produits possédaient déjà des valeurs pour cet attribut AVANT le changement de type, c’est à vous de les recopier de ‘catalog_product_entity_decimal‘ vers ‘catalog_product_entity_int‘.
Supprimer un attribut
La suppression d’un attribut est très simple:
$install->removeAttribute("catalog_product", "attribut_test");
Malgré sa simplicité, la suppression d’un attribut est « propre »: toutes les données associées à cet attribut sont supprimées, ainsi que ses associations à des jeux d’attributs.
C’est important de le savoir!
Etape du Setup
Lorsque vous passez par le mode d’installation habituel, c’est à dire en créant un script de Setup, peut-être vous êtes vous demandés à quel moment ce script d’installation est appelé par Magento par rapport au processus normal d’affichage d’une page (qui est: index.php => Mage::run() => FrontController::dispatch => routage => Controller::methodAction).
Dans la méthode run() du composant ‘core/app’, l’appel à _initModules() – appelé avant le dispatch – est là pour effectuer le chargement des modules, puis l’application des Mises à Jour (Mage_Core_Model_Resource_Setup::applyAllUpdates()) qui va entraîner l’exécution des script d’installation. On voit donc que les scripts sont appelés très tôt dans la chaîne de traitement Magento.
Désinstallation d’un module
Il n’existe pas de script de désinstallation d’un module!
Lors de la désinstallation d’un package via le Magento Connect Manager, celui-ci parcourt l’ensemble des fichiers définis par le package et les supprime, mais cela s’arrête là ! Donc, si votre module a ajouté des éléments en base, ils resteront là et ne seront pas supprimés. Je trouve ça plutôt moyen de la part d’un outil aussi bien pensé que Magento…
D’autant plus que cela ne me semble pas très compliqué d’ajouter ce type de fonctionnalité: lors de la création de votre package, il suffit d’indiquer le script à exécuter pour compléter la désinstallation, et cela permettrait d’avoir déjà une désinstallation efficace !
A proposer à l’équipe de Varien…
Voilà, j’en ai finit pour l’instant avec le setup de Magento. Mais je viendrai modifier progressivement cet article en fonction de mes découvertes dans ce domaine! Je vous invite donc à vous abonner à cet article si ce sujet vous intéresse.
Revenir au Tutoriel sur les Composants Métiers