 e la maggior parte di noi Magento developers ha iniziato a sporcarsi le mani con la nuova piattaforma.

Sono tantissimi gli argomenti da studiare e affrontare per prendere in mano Magento 2 e molti richiedono un lungo periodo di apprendimento che non sempre abbiamo a disposizione.

Per questo motivo ho pensato che possano tornare utili degli esempi veloci di codice per affrontare situazioni reali lasciando a voi il compito di approfondire la teoria che c’è dietro, soprattutto per chi, come me, ha bisogno di partire dal codice per capire meglio i concetti sottostanti.

Partiamo quindi dall’argomento del titolo: aggiungere una checkbox al checkout; sembra una cosa semplice vero? Cosa sarà mai aggiungere una checkbox durante il processo di checkout. Non fatevi ingannare dalle apparenze, Magento è cambiato molto ma regala ancora alcune 

 dei vecchi tempi. Per farvi intuire di cosa sto parlando basta andare ad esaminare il file 

/Magento/Checkout/view/frontend/layout/checkout_index_index.xml

Anche solo in base a dove dobbiamo posizionare la nostra checkbox cambierà non di poco la via da prendere per arrivare alla soluzione. Ho costruito l’esercizio con lo scopo di andare a toccare più argomenti possibili e questo mi ha costretto a dividere l'articolo in 2 parti.

Vogliamo che l’utente possa indicare, durante lo step di spedizione, se vuole la fattura o meno e nel caso decida di volere la fattura, dobbiamo rendere visibile e obbligatorio il campo Società.

Prima di andare ad occuparci della parte frontend e quindi dove e come posizionare la nostra checkbox per la richiesta fattura, andiamo a vedere come aggiungere questo dato sul database all’interno della tabella degli ordini, utilizzando uno script di installazione.

creato la struttura di base del nostro modulo Magento 2

; aggiungiamo lo script di installazione 

bitbull-team/m2-checkout-customization/Setup/InstallSchema.php

<?php
use Magento\Framework\Setup\InstallSchemaInterface;
use Magento\Framework\Setup\ModuleContextInterface;
use Magento\Framework\Setup\SchemaSetupInterface;

/**
* Class InstallSchema
* @package Bitbull\CustomCheckout\Setup
*/
class InstallSchema implements InstallSchemaInterface
{

   /**
    * @param SchemaSetupInterface $setup
    * @param ModuleContextInterface $context
    */
   public function install(SchemaSetupInterface $setup, ModuleContextInterface $context) 
   {
       $installer = $setup;
       $installer->startSetup();

       $installer->getConnection()->addColumn(
           $installer->getTable('sales_order'),
           'invoice_checkbox',
           [
               'type' => \Magento\Framework\DB\Ddl\Table::TYPE_SMALLINT,
               'nullable' => false,
               'default' => '0',
               'comment' => 'Request invoice'
           ]
       );
       $setup->endSetup();
   }
}

Tutti gli script di installazione e aggiornamento devono implementare  

Magento\Framework\Setup\InstallSchemaInterface

Magento\Framework\Setup\SchemaSetupInterface

 è l’interfaccia che fornisce la connessione al database tramite il quale eseguire la nostra modifica.

Magento\Framework\Setup\ModuleContextInterface

 non viene utilizzato ma se ci troviamo nel caso di dover fare un aggiornamento anziché un’installazione è qui che troviamo le informazioni relative al modulo come la versione corrente del setup specificata nel file 

 per determinare se applicare o meno il nostro aggiornamento.

<?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_CustomCheckout" setup_version="0.1.0">
    </module>
</config>

, basterà abilitare il modulo ed eseguire la procedura di aggiornamento come mostrato di seguito:

bin/magento module:enable Bitbull_CustomCheckout
bin/magento setup:upgrade

A questo punto andiamo a inserire la nostra checkbox all’interno dell’indirizzo di spedizione aggiungendo il file di layout **

 **le modifiche al layout dichiarate nel file saranno così aggiunte da Magento all’insieme delle layout rule.

Di seguito le dichiarazioni di layout che servono ad ottenere il risultato voluto:

<item name="invoice-checkbox" xsi:type="array">
   <item name="component" xsi:type="string">Magento_Ui/js/form/element/boolean</item>
       <item name="config" xsi:type="array">
        <!–customScope is used to group elements within a single form (e.g. they can be validated separately)–>
           <item name="customScope" xsi:type="string">shippingAddress.custom_attributes</item>
           <item name="template" xsi:type="string">ui/form/field</item>
           <item name="elementTmpl" xsi:type="string">Bitbull_CustomCheckout/form/element/invoice-check</item>
       </item>
       <item name="provider" xsi:type="string">checkoutProvider</item>
       <item name="dataScope" xsi:type="string">shippingAddress.custom_attributes.invoice-checkbox</item>
       <item name="description" xsi:type="string">Richiedi fattura</item>
       <item name="sortOrder" xsi:type="string">121</item>
   </item>
   <item name="company" xsi:type="array">
       <item name="component" xsi:type="string">Bitbull_CustomCheckout/js/invoice-input</item>
       <item name="sortOrder" xsi:type="string">122</item>
   </item>
</item>

Queste righe definiscono direttive importanti che andiamo ad analizzare una ad una.

<item name="component" xsi:type="string">Magento_Ui/js/form/element/boolean</item>

 viene usato per la nostra checkbox. Se non viene specificato sarà usato quello di default 

Senza entrare troppo nel dettaglio, per poter capire come modificare ed estendere i 

 offerti da Magento 2 per il frontend bisogna avere una conoscenza base di Knockout, il framework utilizzato per costruirli.

A tal proposito suggerisco la lettura del 

 che contiene già tutto il necessario sia per renderizzare la nostra checkbox che per poter osservare "l'aggiornamento" del valore assunto.

Per poter cambiare la visibilità del campo società sulla base dello stato della checkbox dobbiamo sovrascrivere lo 

<item name="company" xsi:type="array">
   <item name="component" xsi:type="string">Bitbull_CustomCheckout/js/invoice-input</item>
   <item name="sortOrder" xsi:type="string">122</item>
</item>

 ci permette di modificare l’ordinamento di default dei campi input della form dell’indirizzo di spedizione; il valore utilizzato, 122, fa sì che il campo società sia posizionato subito dopo la nostra checkbox che ha 

Purtroppo non vale lo stesso per la form dell’indirizzo di fatturazione; in un prossimo articolo vedremo perché e come aggirare il problema.

vendor/bitbull-team/m2-checkout-customization/view/frontend/web/js/invoice-input.js

define([
   'underscore',
   'Magento_Ui/js/form/element/abstract',
   'jquery'
], function (_, Abstract, $) {
   "use strict";
   return Abstract.extend({
       defaults: {
           visible: false,
           required: false,
           listens: {
               visible: 'setPreview',
               '${ $.provider }:data.reset': 'reset',
               '${ $.provider }:${ $.customScope ? $.customScope + "." : ""}data.validate': 'validate',
               '${ $.provider }:${ $.customScope ? $.customScope + "." : ""}customAttributes.invoice-checkbox': 'setVisible'
           }
        },
	    initialize: function () {
	        this._super();
	        this.visible(false);
	    },
	    setVisible: function () {
	        var visible = this.source.shippingAddress.custom_attributes['invoice-checkbox'];
	        if (visible) {
	            this.validation['required-entry'] = true;
	        } else {
	            this.error(false);
	            this.validation = _.omit(this.validation, 'required-entry');
	        }
	        this.visible(visible);
	        this.required(visible);
	        return this;
	    }
   });
});

Con il codice sopra rendiamo visibile, obbligatorio e aggiungiamo il campo alle regole di validazione della form dell’indirizzo di spedizione a seconda del valore della nostra checkbox.

Il tutto è possibile sottoscrivendo il metodo setVisible ogni volta che cambia il valore della nostra checkbox accessibile tramite 

this.source.shippingAddress.custom_attributes["'invoice-checkbox'"].

<item name="config" xsi:type="array">
	<item name="customScope"  xsi:type="string">shippindAddress.customAttributes</item>
	<item name="template" xsi:type="string">ui/form/field</item>
	<item name="elementTmpl" xsi:type="string">Bitbull_CustomCheckout/form/element/invoice-check</item>
</item>

 ci permette di raggruppare un insieme di input per poter applicare azioni di gruppo sugli input field appartenenti a questo stesso scope.

 definiscono il template Knockout utilizzato per fare il rendering del nostro input field, nel nostro caso rispettivamente 

Un tool molto utile per andare a conoscere meglio i nostri 

 e avere quindi la controprova che tutti sia settato correttamente è l’estensione per chrome 

A questo punto arriviamo all’ultimo pezzo che ci permette di passare il dato dal frontend al backend:

bitbull-team/m2-checkout-customization/view/frontend/requirejs-config.js

config:{
      mixins: {
          'Magento_Checkout/js/action/set-shipping-information': {
           'Bitbull_CustomCheckout/js/action/set-shipping-information-mixin': true
          }
      }
  }

I mixins hanno un comportamento simile ai Plugin con il before nel javascript, dove noi possiamo andare ad attuare le nostre modifiche prima dell’azione originale, set-shipping-information in questo caso incaricata del salvataggio dell’indirizzo di spedizione.

/*jshint browser:true jquery:true*/
/*global alert*/
define([
   'jquery',
   'mage/utils/wrapper',
   'Magento_Checkout/js/model/quote'
], function ($, wrapper, quote) {
   'use strict';
    return function (setShippingInformationAction) {
       return wrapper.wrap(setShippingInformationAction, function (originalAction) {
           var shippingAddress = quote.shippingAddress();
           if (shippingAddress['extension_attributes'] === undefined) {
               shippingAddress['extension_attributes'] = {};
           }
           shippingAddress['extension_attributes']['invoice_checkbox'] = shippingAddress.customAttributes['invoice_checkbox'];
           // pass execution to original action ('Magento_Checkout/js/action/set-shipping-information')
           return originalAction();
       });
   };
});

 inseriti da Magento nella maggior parte delle interfacce affinché possano essere aggiunti dati nuovi; nel nostro caso si tratta di salvare il valore della checkbox.

La nostra avventura non è finita e, nella speranza di avervi dato input utili e chiari, continuerà come promesso nella prossima puntata sul lato backend.

https://github.com/bitbull-team/m2-checkout-customization

https://github.com/magento/magento2/issues/1864

http://magento.stackexchange.com/questions/135969/magento-2-how-to-add-a-custom-field-to-checkout-and-then-send-it

http://devdocs.magento.com/guides/v2.0/howdoi/checkout/checkout_form.html

http://devdocs.magento.com/guides/v2.1/howdoi/checkout/checkout_new_field.html

https://github.com/magento/devdocs/issues/844

Magento 2 tips & tricks: aggiungere una checkbox al checkout

Nonostante l’approccio nello sviluppo frontend delle email non sia ancora cambiato a distanza di anni, Magento 2 ha introdotto alcune tecnologie “recenti” nella gestione del frontend delle sue email transazionali.

In questo articolo vedremo le tecnologie e le scelte adottate da Magento2 per lo sviluppo delle email, analizzandone pregi e difetti.

Le email di Magento 2 (per numero e tipologia) sono rimaste pressochè le stesse di Magento 1, sebbene siano state distribuite seguendo la nuova struttura del frontend.

Ecco una panoramica generale dei template email su Magento 2:

E i template di alcuni blocchi interni usati nei template:

Per personalizzare un template email si può procedere in due modi: azione diretta sui file del template o modifica dal pannello backend di Magento.

Dal backend, analogamente a Magento1 è possibile caricare il template standard e personalizzarlo salvando le modifiche all’interno del database di Magento.

Il tool per la modifica delle email da backend è raggiungibile dal menu principale alla voce 

Per personalizzare un template email direttamente lato tema si segue la normale procedura di personalizzazione del tema:

Ipotizzando di personalizzare il template email della email per il nuovo ordine:

vendor/magento/module-sales/view/frontend/email/order-new.html

lo si copia semplicemente sul nuovo tema rispettando la struttura indicata nella documentazione ufficiale:

vendor/[nome_vendor]/[nome_tema]/Magento_Sales/email/order-new.html

La grande novità di questa nuova versione delle email è la rielaborazione degli stili nelle email transazionali. Se in Magento 1 avevamo un template molto standard e minimale con pochi stili inline che definivano più che altro sfondi e bordi per ogni template, in Magento 2 abbiamo la possibilità di definire degli stili specifici per ogni singolo elemento.

Chi ha lavorato con i template delle email saprà che lo sviluppo di queste, necessita di “tornare indietro” nelle modalità di sviluppo di almeno 20 anni. Ogni client e webclient infatti ha regole sue nell’interpretazione degli stili e dell’html: a partire dagli standard html e css che non vengono minimamente presi in considerazione a tag e stili css che vengono letti / interpretati / ignorati a seconda del client. Persino la lettura degli stili (o in un file .css, o nel documento all’interno dei tag style o direttamente inline nell’elemento) cambia da client a client.

Fatta questa premessa è facile intuire che lo sviluppo di email complesse e personalizzate è per lo sviluppatore frontend un vero calvario.

Magento 2 cerca di superare questa problematica integrando gli stili in modalità differenti ma usando gli stessi sorgenti.

Vediamo ad esempio il template header delle email di Magento2:

Come è possibile notare Magento 2 richiama due file CSS principali e utilizza tre tag in tutto:

Il primo tag consiste in una variabile che restituisce dei valori provenienti dal campo Template Styles se si personalizza il template email lato backend e da qualsiasi stile presente nel documento inserito all’interno di un blocco commentato. Es:

<!-@styles

.esempio { background: #f00; }
  
@->

Il secondo tag “css” restituisce un file CSS generato a partire dal file LESS omonimo presente in vendor/[nome_vendor]/[nome_tema]/web/css/.

Questo file LESS contiene al suo interno degli import che includono altri file LESS:

Riferimenti più specifici sull’utilizzo dei vari file less e delle variabili e mixins interni si possono trovare all’interno dei file sorgenti tramite appositi commenti e sulla documentazione ufficiale:

http://devdocs.magento.com/guides/v2.0/frontend-dev-guide/templates/template-email.html

Notare la presenza dei file _lib.less, _theme.less e _variables.less che vengono richiamati anche nella generazione dei file css del tema principale.

Il terzo tag “inlinecss” richiama un altro file css generato a partire dal file less omonimo:

vendor/[nome_vendor]/[nome_tema]/web/css/email-inline.less.

In questo caso i file LESS associati sono gli stessi del file email.less tranne per l’ultimo _responsive.less.

Il file CSS specificato nel tag inlinecss non viene però restituito direttamente sul documento: come lascia intendere il nome stesso, il tag racchiude le regole che andranno applicate inline sui tag html grazie ad uno script di terze parti chiamato 

Emogrifier si occupa di interpretare la porzione di codice CSS specificato con inlinecss e applica a ogni tag del documento lo stile inline risultante dalla lettura e interpretazione del codice, calcolando automaticamente il valore risultante dalla cascata degli stili incontrati.

Supponendo di avere una porzione di codice html di questo tipo:

<div class="container">

<div class="container inner-container">

<h1>Title<h1>

<p>Lorem ipsum</p>

</div>

</div>

div { border:1px solid red; }

.container { border: 1px solid blue; }

div.inner-container { border: 1px solid black; }

h1 { font-size:36px; text-transform: uppercase; }


L’output dell’HTML dopo l’intervento di emogrifier diventa:

<div class="container" style="border:1px solid blue;">

<div class="container inner-container" style="border:1px solid black">

<h1 style="font-size:36px; text-transform: uppercase;">Title<h1>

<p>Lorem ipsum</p>

</div>

</div>

Emogrifier legge e applica la maggior parte dei selettori e degli attributi ad eccezione dei pseudo elementi e dei selettori globali. Il resto dipende ovviamente dalle compatibilità specifiche dei vari client per determinati stili.

Sebbene questo nuovo approccio faciliti enormemente il lavoro dello sviluppatore frontend per la compatibilità cross-browser, l’organizzazione di base dei file less lascia un po’ perplessi. Ereditare tutti i less e le variabili del tema principale può creare qualche scompiglio nella visualizzazione delle email. Probabilmente questa soluzione è stata pensata nell’ottica di avere un unico “frontend” e un’unica UI comune per l’intero progetto. Se nella teoria tale condivisione potrebbe risultare vantaggiosa, nella pratica e nella nostra realtà quotidiana questo non accade spesso e ciò rende necessario dover riscrivere parte della struttura e degli stili delle email per separarla dal frontend del sito.

Un’altra problematica molto importante riguarda l’utilizzo di LESS in combinazione con Emogrifier. Ereditando diversi file less dal tema principale oltre a quelli direttamente specificati per le email, il numero totale di file coinvolti potrebbe superare tranquillamente la decina.

Questo rende piuttosto difficile poter sovrascrivere degli stili esistenti o capire come certe regole vengano applicate sugli elementi: trattandosi di stili letti e interpretati dalla libreria Emogrifier e dal client di posta, risulta molto più complesso poter debuggare utilizzando una console di sviluppo cui siamo ormai abituati usare. Sebbene sia comunque possibile, ottenere un file css con un sourcemap, il salvataggio continuo delle email in arrivo e la lettura di queste con una console non può che rendere questo approccio eccessivamente oneroso in termini di tempo rispetto al metodo tradizionale.

Con queste premesse è probabilmente più comodo escludere dal codice l’ereditarietà dei file less del tema, nonostante l’idea di Magento sia quella di obbligare gli sviluppatori a mantenere una uniformità tra email e frontend. Partendo da uno stesso foglio di stile non si può pensare che browser e client di posta interpretino il codice allo stesso modo, se questo è vero come sappiamo anche tra browser stessi, la differenza è decisamente evidente con i client di posta.

Probabilmente arriveremo ad un punto in cui questa differenza non sarà così netta e quindi Magento 2 sarà avvantaggiato, per ora si tratta comunque di una tecnica troppo “moderna” per un mondo così “antico”.

Lavorare con le email in Magento 2

 ricadono quei processi che consentono di eliminare i tempi di 

Uno dei processi più conosciuti è noto con il nome di 

Una introduzione all’argomento si può trovare in un popolare 

 mentre per quel che riguarda Magento consigliamo la lettura di un recente 

Nel nostro articolo descriviamo un processo di zero downtime deployment con Magento 2. Per la verità non sempre si riesce ad eliminare il tempo di downtime, ci sono situazioni in cui è necessario attivare il maintenance mode e vedremo quali sono.

Prima di iniziare la lettura, consigliamo di fare riferimento al nostro precedente 

 perché di seguito li citeremo dandone per scontato la conoscenza.

Il deploy di un progetto Magento 2 è decisamente più complesso rispetto a Magento 1.

Il motivo è dato dal fatto che, per ottimizzare le prestazioni in 

, Magento 2 ha introdotto una serie di passaggi operativi da eseguire nel giusto ordine.

A complicare ulteriormente le cose si aggiunge qualche pecca di gioventù che siamo sicuri sarà risolta in futuro.

I passaggi operativi riassunti nell’elenco seguente sono suddivisi in due fasi principali:

Separare la fase di build da quella di deploy non è sicuramente l’unico approccio possibile ma, considerando quanto può durare la fase di preparazione dei contenuti statici e della compilazione di codice, è quello che preferiamo utilizzare e che ci sentiamo di raccomandare.

Di seguito analizziamo con maggior dettaglio i singoli passaggi.

Ci riferiamo alla cartella radice in cui è installato Magento con 

; è la cartella dove si trovano il file 

Se non è specificato diversamente, tutti i comandi di shell si intendono lanciati da questa cartella.

Questo passaggio prevede di scaricare dal sistema di versioning parte del codice che pubblicheremo in produzione.

Parliamo di “parte del codice” perché, come vedremo, alcune classi saranno generate successivamente e non sono sotto controllo di versione.

Scarichiamo dunque il pacchetto e lo scompattiamo in 

D’ora in poi chiamiamo la versione del codice scaricata 

 che invece rappresenta la versione del codice attualmente in produzione.

La versione da pubblicare può corrispondere al master branch del repository, a un altro branch, a un tag o a una specifica commit.

Una volta scaricata la versione del codice che dobbiamo pubblicare in 

, ci posizioniamo nella cartella e scarichiamo le dipendenza con Composer:

Ci sono un paio di parametri che si possono passare al composer install su cui vale la pena soffermarsi:

Questa fase si rende necessaria solo se la fase di build avviene in un ambiente che, per scelta o necessità, non accede al database di produzione.

In questo caso si parla di build in condizioni di 

Per installare Magento 2, di cui al precedente passaggio abbiamo già scaricato il codice sorgente, occorre aver creato un database dedicato e lanciare il comando seguente:

$ bin/magento setup:install --base-url=http://$SITE_URL/ --db-host=$DB_HOSTNAME 
--db-name=$DB_NAME --db-user=$DB_USERNAME --db-password=$DB_PASSWORD 
--admin-firstname=Admin --admin-lastname=Admin --admin-email=devel@bitbull.it 
--admin-user=admin --admin-password=admin123 --language=it_IT --currency=EUR 
--timezone=Europe/Rome --use-rewrites=1 --session-save=db

Le variabili che iniziano con il simbolo 

 devono essere impostate da un processo esterno come variabili d’ambiente o passate come parametro al nostro eventuale script.

Arrivati a questo punto è possibile impostare Magento in production mode, utilizzando il comando seguente:

Nel caso la fase di build venga eseguita in 

, quindi con un database vuoto non allineato a quello di produzione, occorre utilizzare il parametro 

 che evita che Magento lanci automaticamente il 

Un database vuoto infatti non avrà le eventuali 

 presenti in quello di produzione e il deploy dei contenuti statici si limiterebbe a generare i contenuti per il locale di default. In questa circostanza, dunque, occorre lanciare il deploy dei contenuti statici (e la compilazione) a parte.

Se si esegue la fase di build in isolamento e si è impostato il production mode utilizzando il parametro 

, occorrerà avviare manualmente il deploy dei contenuti statici.

Il deploy dei contenuti statici si effettua con il comando seguente, passando ogni localizzazione necessaria; supponiamo 

$ bin/magento setup:static-content:deploy “it_IT” “en_US”

Questa fase può durare anche decine di minuti, che rappresentano un potenziale downtime, ed è uno dei motivi per cui si sceglie di effettuare la fase di build in un ambiente che non sia quello di produzione.

, occorrerà avviare manualmente la compilazione.

La compilazione in Magento 2 è quel processo di 

 che in developer mode sono invece generate a runtime; per un approfondimento rimandiamo sia alla 

La compilazione può essere avviata con il comando seguente se il progetto è basato su 

$ bin/magento setup:di:compile-multi-tenant

 è riservata a quelle situazioni in cui Magento è utilizzato con più di un website e più di uno store ma a causa di un bug (

) è necessario utilizzarla anche nel caso 

, cioè se si ha un solo website e un solo store.

 invece la compilazione deve essere lanciata con il comando seguente:

In questa versione infatti la compilazione multi-tenant non è ancora supportata.

Come abbiamo accennato nel paragrafo “Download delle dipendenze”, è solo dopo aver generato tutte le 

 che possiamo preoccuparci di effettuare il dump dell’autoloader.

 consente di generare il mapping statico delle classi; in questo caso dunque valgono le considerazioni sulle performance fatte nel paragrafo “Download delle dipendenze”.

), al termine del processo di compilazione è necessario rimuovere il file seguente:

Al termine creiamo un archivio compresso che sarà quello di cui faremo upload sul server di produzione nella successiva fase di deploy.

L’insieme dei file che compongono l’archivio prende il nome di 

Il caricamento dell’archivio compresso sul server può avvenire secondo la modalità che si preferisce, caricandolo o facendo sì che il server lo scarichi da una sorgente sicura.

Una volta caricato l’archivio, scompattiamolo in una sotto-cartella di 

 che tipicamente ha un nome legato al timestamp di riferimento; l’esempio seguente è nella forma 

IMPOSTAZIONE PERMESSI SU FILE E DIRECTORY

Una volta scompattato l’archivio dobbiamo impostare i permessi corretti sui relativi file e sotto-cartelle.

Questa procedura dipende da come è configurato il server perciò senza entrare troppo nei dettagli rimandiamo alla documentazione ufficiale che tratta le diverse casistiche:

Questa fase non è sempre obbligatoria. Lo è se il codice che rilasciamo prevede l’esecuzione di script di upgrade.

Si può verificare la necessità di eseguire script di upgrade con il comando seguente:

Purtroppo l’output è testuale e l’exit code di questo comando non cambia a seconda del risultato, quindi per automatizzare la decisione occorre valutare l’output.

“The module code base doesn't match the DB schema and data”

 dovremo abilitare la modalità di manutenzione e avviare gli script di aggiornamento.

Ecco un esempio di bash script che converte l’output in un exit code: 0 se non c’è nessuna azione da intraprendere, 1 se occorre eseguire gli script di upgrade:

#!/bin/bash  
# use --no-ansi to avoid color characters  
message=$(bin/magento setup:db:status --no-ansi)  
if [[ ${message:0:3} == "All" ]];  
then  
  exit 0 # 0 not required being default exit code; used for clarity  
else  
  exit 1  
fi

La modalità di manutenzione va sempre attivata sulla release corrente prima che questa punti alla nuova release; il comando da utilizzare è:

Se non si lavora in isolamento e non si mantiene il file 

 sotto controllo di versione (perché è lì che viene memorizzato lo stato di abilitazione dei moduli) occorre eseguire il comando che abilita eventuali moduli aggiuntivi:

 abilita tutti i moduli aggiuntivi; se occorre abilitarli selettivamente allora è necessario far seguire a 

 i nomi dei moduli da abilitare separati da uno spazio; ad esempio:

$ bin/magento module:enable Vendor_Module1 Vendor_Module2

Se, come visto in precedenza, è necessario eseguire gli script di aggiornamento, il comando da utilizzare è:

$ bin/magento setup:upgrade --keep-generated

 è necessario per evitare che i file dinamici generati nei precedenti passaggi vengano invalidati.

Il comando per eliminare dati di cache è il seguente:

Usare questo comando anziché rimuovere manualmente i contenuti dal file system ci garantisce che, nel caso in cui la cache non sia memorizzata su file system ma su sistemi esterni come Redis, il flush avvenga correttamente.

L’ultimo passaggio consiste nel far diventare la nuova release quella corrente.

Zero downtime deployment con Magento 2

Migrare i dati dalle precedenti versioni di Magento al nuovo Magento 2 è un tema molto richiesto nella community, molte persone cercano consigli, suggerimenti e recensioni sull’uso del tool sviluppato e mantenuto nel


 (anche il team di Magento chiede a chi ha usato il tool di compilare un sondaggio per conoscerne i pareri e suggerimenti). In questo articolo ci occuperemo di scoprire, installare e dare qualche consiglio su questo strumento, così da avere una panoramica per utilizzarlo e avere qualche suggerimento da poter seguire. Non daremo spazio all’intero processo di porting di un ecommerce alla nuova piattaforma; migration plan, moduli proprietari, personalizzazioni e i temi sono tutti parte della guida alla migrazione che potrete trovare 

Come anticipato nell’introduzione, ci occuperemo della migrazione dei dati, ovvero giocheremo solo con i database dei nostri Magento, perciò come regola generale “diamoci dentro con le copie di sicurezza dei db”.

Come prerequisiti per questo articolo dovremmo avere un’installazione di base (funzionante) di Magento 2 e l’accesso ai database di Magento 1 e 2.

Nota: Personalmente per lo sviluppo della configurazione da usare nella mia migrazione ho preferito importare il database di Magento 1 sullo stesso DBMS di Magento 2, questo perché essendo su un’altra macchina avrei aggiunto dei tempi di esecuzione in più a discapito dello sviluppo.

Per prima cosa procuriamoci il tool da utilizzare nella nostra installazione. Per farlo ci basta seguire la 

. Da tener presente che ogni versione di Magento 2 può avere la sua versione di migration-tool, questo è dovuto alle modifiche fatte durante i vari upgrade dei moduli.

Io ho preferito installarlo tramite il repo github aggiungendo la dipendenza al file composer.json. Una volta installato potete verificare se è presente il comando migrate nell’output di bin/magento

$ bin/magento | grep migrate
migrate
 migrate:data                              Main migration of data
 migrate:delta                             Migrate the data is added into Magento after the main migration
 migrate:settings                          Migrate system configuration


Iniziamo a vedere l’organizzazione del modulo per farci un idea più precisa di come lavorare con il tool.

Bitbull

Magento 2

Magento 2 tips & tricks: aggiungere una checkbox al checkout

Lavorare con le email in Magento 2

Zero downtime deployment con Magento 2

Migrazione dati da Magento 1 a Magento 2

Personalizzare il menu di Magento 2

Primi passi con l’utilizzo delle API di Magento 2

La compilazione del Less in Magento2

Installare la traduzione italiana di Magento2

Gli application mode in Magento 2