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.

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

Per creare un nuovo modulo su Magento 2 è necessario creare due file 

. Se supponiamo di voler creare il modulo 

, una volta stabilito il Namespace (il nostro sarà 

) ci basta creare la seguente struttura nel progetto

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 

 creato va dichiarato il tipo di componente sviluppato; le possibili dichiarazioni utilizzabili sono presenti come costanti nella classe 

\Magento\Framework\Component\ComponentRegistrar

Noi dobbiamo dichiarare un modulo e nel file 

<?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 ‘

’ e path del sorgente uguale alla posizione attuale del file (

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

 il componente può definire le dipendenze da altri moduli, questo è permesso all’interno del tag sequence. Ecco un esempio direttamente da Magento

Con questo sistema è possibile definire l’ordine di caricamento del modulo, in particolare il modulo 

 non può essere caricato prima degli altri definiti nel tag 

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 

 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

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 

” (il path è quello dichiarato nel file 

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 

” è 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 

, 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 

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:

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:

Non indugiamo oltre, il nostro primo modulo sta per nascere

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

bin/magento module:enable Bitbull_Example

a questo punto il comando eseguito ci chiede di chiamare 

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

possiamo aver conferma dell’effettiva abilitazione guardando il file 

, 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 

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.

Creiamo il nostro primo modulo su Magento 2

Lo abbiamo atteso molto, ma alla fine Magento2 è arrivato. Le novità sono tante, non sarà possibile toccarle tutte con questo articolo. Mi limiterò ad illustrare quelle che forse influenzeranno maggiormente il nostro lavoro di tutti i giorni e quelle che per qualche motivo mi hanno fatto dire “wow”.

Già ad un primo sguardo il pannello di amministrazione di Magento2 si presenta pulito ed intuitivo. Scompaiono diversi moduli che su Magento1 venivano utilizzati di rado come i sondaggi e i tag mentre vengono aggiunte nuove funzionalità che permettono di gestire contenuti e prodotti in modo più semplice da backend. Chi gestisce il negozio avrà dunque la possibilità di compiere in autonomia diverse operazioni che adesso richiedono l’intervento di uno sviluppatore: generare regole custom per creare vetrine, gestire in maniera più agevole le varie tipologie di prodotti, personalizzare la scheda prodotto..

Magento2 facilita molto l’inserimento e la modifica dei prodotti dal pannello di amministrazione. Alcuni esempi? I prodotti configurabili possono essere creati direttamente a partire da quelli semplici aggiungendo attributi e prodotti associati nella tab 

,  un prodotto semplice può diventare scaricabile con un unico flag e ci sono meno campi obbligatori da compilare in fase di creazione.

<div>
Grazie a un comodo widget, il gestore del negozio avrà la possibilità di costruire vetrine di prodotti completamente customizzabili all’interno di pagine CMS e blocchi statici utilizzando semplicemente le regole condizionali.
</div>

Anche sulla gallery dei prodotti ci sono sostanziali novità, le immagini possono essere caricate e riordinate con il drag and drop ed è stato introdotto il supporto per i video, feature richiesta da molti clienti. Magento2 supporta nativamente le Api di youtube e di Vimeo e permette di inserire anteprime personalizzate.

Se lo sviluppatore, grazie a Magento2, sarà sgravato da tutta una serie di incombenze che possono essere gestite in autonomia dall’e-commerce manager, esso si troverà alle prese con un workflow sempre più complesso ed evoluto.

Scompare la tradizionale divisione tra app e skin per far posto ad una più razionale divisione in moduli.

Ciascun modulo contiene all’interno tutti i file di layout, i template e gli asset specifici. Possiamo dire addio al local.xml di 1200 righe che contiene tutte le customizzazioni del tema.

Magento2 integra nativamente una serie di strumenti ormai indispensabili nella cassetta degli attrezzi del frontend-dev.

Innanzitutto, per la gestione degli stili, sono presenti una libreria php [ 

] per eseguire la compilazione dei Less sia lato server che lato client.

La cosa davvero interessante è che Magento2 prevede un meccanismo di fallback per i file less analogo a quello che conosciamo per i template. Questo permette ad un tema di ereditare una parte degli stili del tema “padre” senza portarsi dietro tutto il css, a vantaggio delle prestazioni. Inoltre è possibile utilizzare le stesse variabili tra un tema è l’altro senza dover riscrivere codice.

Altra funzionalità “magica” del preprocessore di Magento 2 è la direttiva //@magento_import. Questa sintassi permette di importare i file .less con lo stesso nome da diverse cartelle (ad esempio da moduli diversi).

Nella root principale di Magento2 troviamo anche il gruntfile.js che si occupa di eseguire tutti i task presenti nella cartella dev/tools/grunt/task e di fare deploy di tutti gli asset statici all’interno della directory pub/static.

La scelta di integrare Grunt nel core di Magento 2 ha scatenato un vivace dibattito all’interno della community, il meccanismo di compilazione è ancora troppo lento e molti sviluppatori chiedono la libertà di utilizzare sistemi più performanti come Gulp [

 ]. Sostituire il task runner non è semplice perchè una parte dei file Less del core di Magento2 utilizzano una forma di compilazione non standard che permette di avere le fallback e la direttiva @magento_import di cui si è parlato nel paragrafo precedente.

La soluzione, ancora acerba, proposta da 

 proprio qualche giorno fa è quella di introdurre Gulp (o qualsiasi altro tool equivalente) dopo il deploy direttamente nella directory pub/static/frontend del tema.

La questione sembra, ancora, ben lontana dall’essere risolta in maniera definitiva e robusta, ma ci sono già diverse strade percorribili per aggirare il problema.

La prima cosa che ho notato quando ho iniziato a mettere le mani nei template di Magento2 è che fa un uso massiccio di flexbox css3. Questo set di proprietà, a mio avviso potentissimo, non è ancora molto usato per la costruzione dei layout a causa della scarsa compatibilità con internet explorer (è supportato parzialmente solo a partire da IE10) e dei possibili problemi di visualizzazione con connessioni lente. Viene invece già sfruttato in sinergia con le media queries per modificare l’ordinamento degli elementi su mobile.

Il tema base di Magento2 usa flexbox proprio per costruire lo scheletro della pagina, non esistono più i template 

 .. ma un’unica struttura di base. Tutti gli elementi di layout sono figli di primo grado del div 

 e vengono disposti in pagina esclusivamente grazie al css. Questo comporta diversi vantaggi: niente codice duplicato, disposizione degli elementi SEO friendly e maggiore semplicità nel gestire comportamenti responsive.

E la retrocompatibilità? Beh non si può avere tutto nella vita 🙂

Se su Magento1 il frontendista aveva una grande libertà a differenza del collega backend, costretto all’interno di logiche molto più schematiche, con Magento2 è arrivata (finalmente?) la disciplina.

Magento 2

Creiamo il nostro primo modulo su Magento 2

Magento2: uno sguardo al frontend