Creiamo il nostro primo modulo su Magento 2

Introduzione

Nel mondo delle piattaforme di ecommerce open-source Magento è una soluzione che garantisce sicurezza e affidabilità; la sua natura open-source ha permesso lo sviluppo da parte di terzi dei moduli per personalizzare il normale comportamento della piattaforma. Se seguono le opportune logiche di strutturazione, i moduli vengono integrati autonomamente nel sorgente di Magento. Questo ci consente di integrare il nostro codice nel normale flusso di controllo.

La logica di strutturazione dei moduli è il motivo di questo articolo. Con l’avvento di Magento 2 dobbiamo armarci di tutte le nostre conoscenze e andare alla scoperta del nuovo framework.

In questo articolo vedremo la struttura di base dei moduli su Magento 2 e lo faremo con l’aiuto di un esempio; creeremo un modulo che non fa nulla di che se non essere “visto” da Magento 2.

Prima di iniziare

Diamo per scontato di avere a disposizione un installazione di Magento 2, nel caso è possibile trovare informazioni a riguardo sulla documentazione ufficiale.

Tuffiamoci in Magento2

Per creare un nuovo modulo su Magento 2 è necessario creare due file registation.php e module.xml. Se supponiamo di voler creare il modulo Example, una volta stabilito il Namespace (il nostro sarà Bitbull) ci basta creare la seguente struttura nel progetto

• app
  • code
    • Bitbull
    • Example
      • etc
      • module.xml
      • registration.php

Magento 2 non utilizza più il code pool (community, core e local) come sulla precedente piattaforma, tutti i moduli dei vari vendor vengono inseriti all’interno di app/code.

Nel file registration.php creato va dichiarato il tipo di componente sviluppato; le possibili dichiarazioni utilizzabili sono presenti come costanti nella classe \Magento\Framework\Component\ComponentRegistrar e servono per

• moduli
• tema
• pacchetto lingua
• librerie

Noi dobbiamo dichiarare un modulo e nel file registration.php inseriremo:

<?php
use \Magento\Framework\Component\ComponentRegistrar; 
ComponentRegistrar::register(
ComponentRegistrar::MODULE,
    ‘Bitbull_Example’,
    __DIR__
);

In questo file abbiamo definito il nuovo componente come modulo, con nome ‘_Bitbull_Example_’ e path del sorgente uguale alla posizione attuale del file (app/code/Bitbull/Example).

Il secondo file che dobbiamo creare è module.xml, questo definisce il modulo stesso, ogni modulo deve autodichiararsi specificando il suo nome, la versione e le possibili dipendenze.

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
<module name="Bitbull_Example" setup_version="1.0.0"/>
</config>

Magento per la sua seconda versione ha aggiunto dei file per la definizione degli schema per XML ( i file xsd, XML Schema Definition) in modo da poter validare i file e dichiarare il contenuto degli stessi.

Come detto in precedenza e definito in module.xsd il componente può definire le dipendenze da altri moduli, questo è permesso all’interno del tag sequence. Ecco un esempio direttamente da Magento

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
    <module name="Magento_Catalog" setup_version="2.0.3">
        <sequence>
            <module name="Magento_Eav"/>
            <module name="Magento_Cms"/>
            <module name="Magento_Indexer"/>
            <module name="Magento_Customer"/>
        </sequence>
    </module>
</config>

Con questo sistema è possibile definire l’ordine di caricamento del modulo, in particolare il modulo _MagentoCatalog non può essere caricato prima degli altri definiti nel tag sequence.

Torniamo a noi, Magento 2 a differenza del predecessore ha suddiviso le configurazioni di un modulo all’interno di diversi file xml, quindi non è più presente un monolitico config.xml con tutte le definizioni all’interno. Ora ogni singola tipologia di configurazione ha un suo file xml con il suo file xsd definito.

Una piccola nota sui file xsd: possiamo definire due tipologie diverse di inclusione

• module xsd
• framework xsd

La prima permette di utilizzare i file xsd dichiarati all’interno dei moduli utilizzando la seguente struttura:

urn:magento:module:Magento_Flow:flows/content.xsd

Nell’esempio troveremo il file xsd all’interno del path flows/content.xsd dichiarato nel modulo “_Magento_Flow_” (il path è quello dichiarato nel file registration.php).

La seconda permette di usare i file xsd presenti nel framework magento

urn:magento:framework:Api/etc/extension_attributes.xsd

La logica del path è come nel precedente esempio con l’unica differenza che i file si trovano sotto il namespace \Magento\Framework\Api in lib/internal/Magento/Framework.

La dichiarazione di “urn:magento” è stata sostituita al path relativo degli xsd per ragioni di inclusione; dato che i moduli possono essere installati con composer e stare nella cartella vendor questo portava a dei link non validi (per maggiori dettagli sull’argomento consultare XML schema resolution – Alan Kent, da notare anche l’utile commando per aggiungere la gestione dei urn xsd a PhpStorm).

Torniamo al nostro esempio, una volta creati i nostri due file dovremo abilitare il modulo, per farlo useremo la command line interface (CLI) di magento che si trova sotto bin/magento.

Questa contiene molti utili comandi, tra i quali citiamo l’installazione di Magento 2, gestione della cache, gestione degli indici, generazione automatica di classi (sì, Magento 2 ne fa tanto uso, ma dato l’argomento troppo vasto per questo articolo ci limitiamo a citarlo senza approfondire) e tanto altro. Possiamo visualizzare la lista dei comandi disponibili chiamando dalla root del progetto:

php bin/magento list

dall’elenco possiamo notare un comando per vedere lo stato dei moduli installati, lo eseguiremo a breve. Prima di farlo, come buona norma durante lo sviluppo, occupiamoci di disabilitare la cache (se abilitata) tramite il comando:

php bin/magento cache:disable

Non indugiamo oltre, il nostro primo modulo sta per nascere

php bin/mangeto module:status

una volta eseguito, saranno elencati in una prima parte i moduli abilitati e nell’ultima quelli non attivi

List of enabled modules:
Magento_Store
...
List of disabled modules
Bitbull_Example

Per attivarlo ci basta chiamare:

bin/magento module:enable Bitbull_Example

a questo punto il comando eseguito ci chiede di chiamare setup:upgrade, questo esegue una serie di operazioni necessarie tra le quali quella di installazione/aggiornamento degli script di setup dei moduli. Se non eseguiamo il comando richiesto verrà visualizzato un messaggio d’errore (sia sull admin che sul frontend) al quale non potremmo dire di no.

Una volta eseguito

bin/magento setup:upgrade

possiamo aver conferma dell’effettiva abilitazione guardando il file app/etc/config.php, dove al suo interno troveremo (come uno degli attributi chiave dell’array modules) il nostro modulo con valore 1 ad indicare l’abilitazione. Inoltre possiamo vedere il modulo anche dall’admin accedendo tramite il menu a Store > Configuration > Advanced – Advanced, apparirà la lista dei moduli con in nostro Bitbull_Example.

It’s alive! It’s alive!

Conclusioni

In questo articolo abbiamo dato uno sguardo alle basi di partenza per costruire i moduli su Magento 2. Inizializzando la struttura che permette di riconoscere il nostro codice all’interno della piattaforma e di caricarlo al momento opportuno a seguito delle sue dipendenze. Il framework è tutto nuovo e da studiare un passo alla volta. Fortunatamente per noi Magento 2 mette a nostra disposizione una documentazione, per guidarci sui vari aspetti dello sviluppo. Spero l’articolo sia stato utile e vi invito a seguirci ancora per addentrarci ancora di più alla scoperta del nuovo framework.