Uno degli strumenti più interessanti che Magento2 ha messo a disposizione degli sviluppatori frontend è Require.js.

, cioè una libreria che si occupa di caricare le risorse e gestire le dipendenze tra i moduli. Molto utile perché permette non solo di generare correttamente l’albero delle dipendenze senza stare a curare l’ordine dei file, ma anche perché carica gli script solo se e quando è necessario, senza far lavorare inutilmente il browser.

Magento2 integra nativamente Require.js. Per ogni modulo o tema è possibile aggiungere un 

 che contiene tutte le configurazioni di require ed è soggetto al sistema di fallback. Esso permette di aggiungere nuovi moduli, estendere e sostituire quelli esistenti.

Su Magento2 e Require ha scritto anche Alan Storm in un bel <a href="http://alanstorm.com/magento_2_and_requirejs/" target="_blank">post che consiglio di leggere</a>.

Bando alle chiacchiere, iniziamo a scrivere il nostro primo modulo require per Magento2. L’obiettivo è creare un semplice stream nella home page del sito con le ultime foto caricate su Instagram.

Prima di tutto creiamo un modulo per Magento2. Come si fa? Ce l’ha spiegato Mirko 

 nella root del nostro tema o nella cartella view/frontend del nostro modulo:

<pre class="brush: xml; title: ; notranslate" title="">var config = {
"paths": {

"InstagramWidget": "Bitbull_InstagramWidget/js/InstagramWidget"

La <a href="http://requirejs.org/docs/api.html#modulenotes" target="_blank">direttiva paths</a> di Require serve a definire il path del modulo che vogliamo caricare e il nome che andremo ad usare per identificare la nostra risorsa. E’ molto utile perché ci consente anche di sostituire qualsiasi modulo di Magento2 sovrascrivendo il comportamento di default che quel modulo va ad implementare (<a href="http://devdocs.magento.com/guides/v2.1/javascript-dev-guide/javascript/custom_js.html#js_replace" target="_blank">Vedi documentazione</a>).

Creiamo il nostro script InstagramWidget.js che si occupa di chiamare le API di instagram, recuperare le ultime foto inserite e iniettarle nel DOM:

<pre class="brush: jscript; title: ; notranslate" title="">define(["jquery"], function($) { ... });
</pre>

Il metodo <a href="http://requirejs.org/docs/api.html#define" target="_blank">define()</a> di Require definisce il modulo e ne specifica le dipendenze, nel nostro caso soltanto jquery che è un oggetto require già definito da Magento2.

Il primo argomento è l’array delle dipendenze, il secondo una funzione che verrà eseguita solo quando le dipendenze saranno state tutte caricate.

All’interno di questa funzione vediamo un’altra novità che Magento2 ci mette a disposizione: la <a href="https://jqueryui.com/widget/" target="_blank">Widget Factory di JQuery Ui</a>, che serve a creare plugin jQuery configurabili, riutilizzabili ed estendibili.

<pre class="brush: jscript; title: ; notranslate" title="">define([
"jquery"
], function($){
$.widget('InstagramWidget.js', {
//DO STUFF
});
return $.InstagramWidget.js;
});
</pre>

Tutti i <a href="http://devdocs.magento.com/guides/v2.1/javascript-dev-guide/widgets/jquery-widgets-about.html" target="_blank">Widget inclusi nell’interfaccia di Magento2</a> sono costruiti con la Widget Factory e possono essere estesi all’occorrenza.

Ora dobbiamo passare dinamicamente al widget una serie di informazioni: sicuramente il nome, l’id del canale e il token. Poi potremmo voler configurare il numero di foto da mostrare o qualsiasi altra cosa ci sia stata richiesta.

Creiamo un template phtml con il markup di base dello stream e inizializziamo il Widget con le configurazioni che ci servono (Per recuperare i dati del canale Instagram esiste una procedura un pò contorta che potete trovare <a href="https://www.instagram.com/developer/authentication/" target="_blank">qui</a>).

 all’interno del tag script. E’ uno dei piccoli “tocchi magici” di Magento2 e serve per inizializzare un componente Javascript su un elemento html. [Questo è solo un esempio con dati statici, in un altro articolo a seguire vedremo come renderlo dinamico.]

Riprendiamo il nostro widget e vediamo che nell’oggetto 

 ci ritroviamo tutte le configurazioni che gli abbiamo passato dal template, pronte per essere usate all’interno dello script.

<pre class="brush: jscript; title: ; notranslate" title="">define([
"jquery"
], function($){
$.widget('InstagramWidget.js', {
_create: function() {
var config = this.options;
console.log(config);
this.getStream(config.token, config.userid, config.num_photos);
},

    getStream: function(token, userid, num_photos) {
          // DO STUFF 
    }
});

Abbiamo inserito con Require.js un nuovo script all’interno di un tema o modulo Magento2, abbiamo creato un widget con la Widget Factory di jQuery Ui e gli abbiamo passato le nostre configurazioni. Manca la parte che fa la chiamata ad Instagram e ci mostra le ultime foto caricate sul canale, purtroppo questo non lo fa Magento2 per noi (il modulo completo lo trovate <a href="https://github.com/bitbull-team/magento2-module-instagramwidget" target="_blank">qui sul repo</a>).

Il modulo è ancora un work in progress ma potete già installarlo all’interno dei vostri progetti. Come già detto, manca la parte backend, quindi per poter modificare le configurazioni dovrete sovrascrivere il template all’interno del tema.

Per installarlo, aggiungete nel composer.json le seguenti righe:

<pre class="brush: jscript; title: ; notranslate" title="">...
"require":{
...
"bitbull/magento2-module-instagramwidget": "dev-master"
},
...
"repositories":[
{
"type": "vcs",
"url":"https://github.com/bitbull-team/magento2-module-instagramwidget.git"
}
]
</pre>

Questo è solo un piccolo esempio delle novità che Magento 2 ha introdotto per gli sviluppatori, da qui potete partire per sviluppare altri widget. Sentitevi liberi di segnalarci i vostri progetti nei commenti.

Sviluppare un Widget con Magento2 e RequireJs

Un buon utilizzo dei log, nelle integrazioni o nelle funzionalità di una certa consistenza, può fare la differenza nell’individuazione e risoluzione di problemi sia in fase di sviluppo che in produzione.

Magento 2 include di default Monolog, uno strumento molto interessante che, rispetto a Magento 1, permette di indirizzare l’output a destinazioni diverse da file di testo (socket, inbox, database e web services). Ciò semplifica tutti gli scenari nei quali i server in cui l’applicazione viene eseguita siano effimeri, e i log debbano essere raccolti in maniera centralizzata ad esempio su 

. Si evita quindi l’inclusione manuale di dipendenze come 

 o l’aggiunta di un layer intermedio come 

, su Magento 2 è necessario scrivere qualche riga in più di codice. Come ogni cosa, va incluso come dipendenza della classe. Dal momento che 

, utilizzeremo quest’ultima per l’inclusione.

/**
 * @var Psr\Log\LoggerInterface
 */
protected $logger;
 
public function __construct(
    Psr\Log\LoggerInterface $logger
) {
    $this->logger = $logger;
}

A questo punto si possono usare i metodi debug, info, notice, warning, error, critical, alert e emergency all’occorrenza.

Troveremo il nostro messaggio nel file var/log/system.log, il che è perfetto per provare che il tutto funzioni, ma non necessariamente ciò che desideriamo. Il più delle volte, infatti, loggare su file separati è preferibile, se non necessario. La domanda è quindi: come si fa?

Specificare un file diverso da system.log si può fare; rispetto a come si faceva su Magento 1 è più prolissa ma pur sempre semplice.

Il readme di Monolog suggerisce la seguente modalità:

$logger->pushHandler(new StreamHandler('path/to/your.log', Logger::WARNING));

Per rimanere fedeli al DI pattern di Magento 2, dobbiamo però fare qualche modifica. Dichiariamo nel costruttore la dipendenza dalla classe factory di StreamHandler per poterne creare un’istanza.

/**
 * @var Monolog\Logger
 */
protected $logger;
 
public function __construct(
    Monolog\Logger $logger,
    Monolog\Handler\StreamHandlerFactory $streamHandlerFactory
) {
    $this->logger = $logger;
 
    $this->logger->pushHandler($streamHandlerFactory->create(
        ['stream' => 'var/log/custom.log']
    ));
}

Ora abbiamo un oggetto logger il quale dirigerà l’output su un file specifico. Siamo riusciti a fare ciò che facevamo anche su Magento 1, ma manca ancora qualcosa. Se vogliamo utilizzare il logger da più classi all’interno dello stesso modulo, dobbiamo di volta in volta aggiungere due oggetti nel costruttore ed assegnare un handler con il percorso corretto al logger. C’è un modo per essere più sintetici?

Centralizzare l’assegnazione dell’handler

Al fine di effettuare in un punto soltanto l’assegnazione dell’handler al logger, implementeremo una classe che chiameremo 

. Questa avrà per parametro il nome del file verso cui verranno direzionati i log e permetterà in ogni momento di ottenere un’istanza del logger.

namespace Bitbull\LoggerExample\Helper;
 
class LoggerProvider
{
    /**
     * @var Monolog\Logger
     */
    protected $logger;
 
    public function __construct(
        Monolog\Logger $logger,
        Magento\Framework\Filesystem $filesystem,
        Monolog\Handler\StreamHandlerFactory $streamHandlerFactory,
        $filename = 'system'
    ) {
        $this->logger = $logger;
 
        $vardir = $filesystem
            ->getDirectoryRead(Magento\Framework\App\Filesystem\DirectoryList::VAR_DIR)
            ->getAbsolutePath();
 
        $this->logger->pushHandler($this->streamHandlerFactory->create(
            ['stream' => $vardir . 'log' . DIRECTORY_SEPARATOR . basename($filename) . '.log']
        ));
    }
 
    public function getLogger()
    {
        return $this->logger;
    }
}

A parte una piccola aggiunta per ottenere in maniera più sicura il percorso della directory var, il codice è lo stesso di cui sopra. In aggiunta abbiamo il parametro filename, che permetterà di utilizzare un filename specifico ma avrà come default system.

Ora possiamo richiedere un’istanza di LoggerProvider ogni volta in cui ci serve il logger, e conservare solamente quest’ultimo nella classe.

/**
 * @var Monolog\Logger
 */
protected $logger;

public function __construct(
    Bitbull\LoggerExample\Helper\LoggerProvier $loggerProvider
) {
    $this-&gt;logger = $loggerProvider-&gt;getLogger();
}

La modalità di utilizzo del logger quindi non varia.

Ora dobbiamo soltanto creare un LoggerProvider per ogni filename di cui necessitiamo, e poi iniettarlo nelle classi corrette. Questo viene fatto tramite il file di.xml, posizionato nella cartella etc del modulo. Per chi non conoscesse la struttura base di un modulo Magento 2, consiglio la lettura dell’articolo di Mirko "[Creiamo il nostro primo modulo su Magento 2]({{< ref "/blog/creiamo-il-nostro-primo-modulo-su-magento-2/index.md" >}})".

Dunque, per ogni filename, creiamo un virtual type:

<virtualType name="IntegrationALoggerProvider" type="Bitbull\LoggerExample\Helper\LoggerProvider">
    <arguments>
        <argument name="filename" xsi:type="string">integration_a</argument>
    </arguments>
</virtualType>

Infine specifichiamo, per ogni classe che necessiterà di includere un logger, quale tra i virtualType che estendono LoggerProvider vogliamo venga iniettato.

<type name="Bitbull\LoggerExample\Model\IntegrationA">
    <arguments>
        <argument name="loggerProvider" xsi:type="object">IntegrationALoggerProvider</argument>
    </arguments>
</type>

Abbiamo visto le differenze tra Magento 1 e 2 per ciò che riguarda il logging. Il livello di complessità è leggermente maggiore, ma ha vantaggi importanti. Il logger provider è uno spunto interessante e come strumento potrebbe essere inserito in un modulo core da utilizzare in diversi progetti. Questo perché risulta particolarmente interessante nel momento in cui abbiamo diversi moduli o diverse classi che direzionano l’output in file diversi.

La parte più interessante è probabilmente quella relativa alla centralizzazione dell’inizializzazione del LoggingProvider. Questo ci permette potenzialmente di direzionare il logging a piattaforme diverse (elasticsearch, amqp, ecc) in base a configurazioni di sistema o variabili d’ambiente. C’è inoltre la possibilità di agire in base al livello di errore, ad esempio inviando email di notifica su eventi di tipo critical, SMS sugli alert, e via dicendo.

Logging su Magento 2

, la ricerca nativa di Magento non brilla per efficienza e per attinenza dei risultati, motivo per cui nel corso del tempo si sono affacciate sul mercato soluzioni di varia natura per sopperire a questa mancanza.

Uno dei recenti ingressi in questo panorama è 

, startup italiana ma con base negli States (anche se il team è distribuito in giro per il mondo, un motivo in più 

 :D). Tooso è un motore di ricerca verticale per l’ecommerce, che propone un approccio alternativo alla ricerca nel catalogo: applicando 

il motore di ricerca “impara” dall’attività degli utenti

 cercando di restituire risultati via via più attinenti, con l’obiettivo dichiarato di 

rendere inutili gli strumenti di raffinamento dei risultati di ricerca

 (filtri, ordinamenti, paginazione ecc ecc).

Inoltre, mette a disposizione nativamente le funzionalità di typo correction e autosuggest.

Il modello di pricing è freemium: fino a 200.000 query l’anno è gratuito, dopodiché costa 0,01$ a query. Il che lo rende molto appetibile per ecommerce di piccole dimensioni, che praticamente a costo zero possono ritrovarsi la ricerca sul proprio sito notevolmente migliorata, ma che al contempo possono contribuire ad accelerare l’”apprendimento” del motore di ricerca. Una classica dinamica win-win quindi.

Da pochi giorni è stato rilasciato su Magento Connect il modulo di integrazione per Magento sviluppato da Bitbull:

https://www.magentocommerce.com/magento-connect/tooso-search-integration.html

Al momento Tooso è in fase di beta privata, per diventare early adopter è necessario contattare lo staff all’indirizzo 

. Una volta ottenuta una API key, è sufficiente inserirla nella pagina di configurazione sotto System -> Configuration -> Tooso Search Engine, dopodiché è possibile attivare il modulo impostando a 

Una volta attivato, il modulo sostituisce in modo trasparente la ricerca nativa di Magento, per cui qualunque ricerca effettuata tramite la search bar da quel momento in poi mostrerà i risultati restituiti da Tooso, compreso il suggest sul campo di ricerca.

Tooso è un prodotto ancora molto giovane ma sicuramente promettente, e il modello di pricing lo rende più accessibile di altre soluzioni più affermate, per cui potrebbe valere la pena provarlo. Se vi dovesse capitare di farlo, fateci sapere la vostra esperienza!

Rilasciato il modulo Magento per l’integrazione con Tooso Search

Di Satispay si è sentito parlare molto di recente, ma per chi non lo sapesse si tratta di una soluzione tutta italiana per ricevere ed inviare pagamenti tramite il proprio smartphone. I vantaggi? Trasferimenti istantanei costi bassissimi.

Per la precisione i trasferimenti sono gratuiti tra privati, e verso gli account business hanno una commissione di 0.20€ solo le transazioni sopra i 10€. Chiunque gestisca un ecommerce avrà capito al volo quanto vantaggiosa questa soluzione sia, se comparata ad altri strumenti come Paypal o POS virtuali.

Per voi abbiamo un’ottima notizia oggi: Bitbull ha rilasciato l’estensione ufficiale per l’integrazione di Satispay con Magento, le versioni supportate per ora sono dalla 1.7 alla 1.9. Con alcuni semplici passaggi potrete quindi installarla e accettare pagamenti tramite Satispay nel vostro ecommerce, migliorando l’esperienza dei vostri utenti e riducendo i costi di incasso.

Trattandosi di un’estensione gratuita la modalità più semplice è tramite Magento Connect, la pagina dell’estensione è la seguente:

https://www.magentocommerce.com/magento-connect/satispay.html

Per chi preferisce Composer o Modman, ulteriori dettagli sono nel repository dell’estensione:

https://github.com/bitbull-team/magento-module-satispay

Si tenga presente che in entrambi i casi è buona pratica installare l’estensione prima in ambiente di test.

La configurazione è semplicissima, basta andare su Sistema > Configurazione > Metodi di Pagamento, e lì inserire il proprio security token (per questo è necessario essere iscritti come business users su Satispay) e attivare l’estensione.

Una volta attivata l’estensione, apparirà l’opzione 

 nel checkout. Dopo aver confermato l’ordine si verrà reindirizzati su una pagina dove sarà possibile confermare il numero di telefono a cui si vuole addebitare l’importo. Di default sarà popolato il numero inserito nell’indirizzo di fatturazione.

Sull’app collegata al numero confermato a questo punto apparirà una notifica, che chiederà di confermare o rifiutare la richiesta di pagamento. Una volta fatto ciò lo stato sarà aggiornato di conseguenza sull’ecommerce, nel giro di pochi istanti.

Se è davvero così semplice, perché non provarla?

Bitbull

Moduli

Sviluppare un Widget con Magento2 e RequireJs

Logging su Magento 2

Rilasciato il modulo Magento per l’integrazione con Tooso Search

Satispay per Magento – Pagamenti semplificati