Scrivo questo articolo su un argomento che non è particolarmente appassionante, né complesso, né vasto eppure ci sono inciampata almeno due volte con grande frustrazione e so per certo che non è successo solo a me. Quindi scrivo qualche riga così di sicuro non me lo dimenticherò più.

L’argomento è la cache del footer di Magento 1, dal punto di vista di un frontend developer che crede di aver a che fare con una richiesta molto semplice e malauguratamente abbassa la guardia.

L’obiettivo è mostrare un footer diverso in pagine diverse dello stesso ecommerce Magento

Insomma una richiesta che non sembra essere nulla di preoccupante.

Ecco allora che il frontend developer non esita e inserisce a colpo sicuro qualcosa del genere:

<default>
  <reference name="footer">
    <block type="cms/block" name="footer-info">
      <action method="setBlockId">
      <block_id>footer-info</block_id>
      </action>
     </block>
   </reference>
</default>

<checkout_cart_index>
  <reference name="footer">
     <remove name=”footer-info”>
  </reference>
</checkout_cart_index>

 che si vedrà in tutte le pagine e poi le modifiche al footer che servono nell’handle specifica.

Se la cache di Magento è disabilitata nessun problema

. Vi verrano a disturbare appena qualcuno la abilita.

Se invece la cache è abilitata infatti l’utente vedrà il footer in tutto il sito nel modo in cui lo visualizza la prima volta

Rischio di essere scontata e aggiungo che quindi: sono cachati anche tutti i blocchi che aggiungerete dentro a 

 e non funzionano neanche eventuali elementi dinamici che potrebbe venirvi in mente di inserire in questo blocco tipo language switcher o riepiloghi del carrello.

, cosa che si può senz’altro fare ma non ci piace molto.

Se siete frontend come chi scrive, e quindi non è il vostro mestiere riscrivere le classi, potete anche cavarvela facilmente da xml con:

Come dicevo questa soluzione non ci piace perchè, anche se magari di poco, peggiora le perfomance e ce n’è una migliore:

<reference name="footer">
 <action method="setCacheKey">
     <key>your-own-unique-cache-key</key>
 </action>
</reference>

 è l’identificativo della cache di ogni blocco, 

al blocco footer di default è associata un’unica chiave

, per questo una volta “salvata” una versione del footer con quella chiave ve lo mostra sempre uguale.

Con il metodo setCacheKey potete però specificare una chiave cache specifica per ogni blocco footer diverso da quello standard, in questo modo le performance sono salve e il vostro footer cambia come richiesto!

È una soluzione che consente teoricamente di scalare all’infinito e quindi avere un footer diverso per ogni pagina del sito, anche se in qualche caso limite ( ad esempio un footer diverso per ogni categoria su un sito con moltissime categorie ) potrebbe essere necessario ricorrere ad un rewrite per evitare di specificare tantissime cache key manualmente, ma rimangono comunque buone possibilità di cavarsela senza disturbare nessun collega backend dev.

Il footer di Magento 1 è un blocco cachato

, 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

La decisione di Google di <a href="https://chrome.googleblog.com/2016/08/flash-and-chrome.html" target="_blank">non supportare più ufficialmente Flash in Chrome</a> a partire dalla versione 55, che verrà rilasciata a Dicembre, rappresenta un classico esempio di teoria del caos. Come infatti 

“il batter d’ali di una farfalla in Brasile può provocare un tornado in Texas”

, così la decisione di rimuovere Flash – una tecnologia ormai considerata unanimemente obsoleta – andrà a creare qualche fastidio ai merchant che utilizzano il browser di Google per gestire il proprio catalogo Magento 1, nella fattispecie per caricare le immagini dei propri prodotti. Questo perché a suo tempo Magento decise di adottare una soluzione basata su Flash per implementare l’uploader che tutti conosciamo:

Dobbiamo ricordare che le prime versioni di Magento risalgono al 2009, in quel periodo i browser erano lontani dal trovare uniformità negli standard per quanto riguarda qualsivoglia tipo di API e Flash era l’unico strumento in grado di garantire compatibilità cross-browser.

Oggi le cose sono cambiate, le <a href="https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications" target="_blank">File API</a> e XMLHttpRequest sono utilizzabili in modo uniforme su tutte le versioni recenti dei browser più diffusi, tant’è che anche Magento 2 ha utilizzato sin da subito un uploader Flash-free.

Per cui non c’è da disperarsi, la soluzione a questo problema è abbastanza semplice e consiste nell’installare il seguente modulo:

<a href="https://github.com/openstream/No-Flash-Image-Uploader" target="_blank">https://github.com/openstream/No-Flash-Image-Uploader</a>

Si tratta di un modulo che sostituisce in modo trasparente l’uploader nativo, sia per la galleria di immagini in scheda prodotto sia nel file manager del cms, che una volta installato non richiede alcuna configurazione.

E’ poco invasivo, in quanto usa una sola rewrite (per la classe 

), per cui il rischio incompatibilità con altri moduli di terze parti è ridotto al minimo.

Seppure non sia aggiornato da un po’, è testato e funzionante sulle ultime versioni di Magento 1. Noi abbiamo avuto modo di verificarlo direttamente sulle versioni Community 1.9.1.0 e 1.9.2.4 ed Enterprise 1.14.1.0.

Installarlo è molto semplice, se si utilizza Composer (e si dovrebbe, 

 anche su Magento 1), è sufficiente aggiungere questa dipendenza nel proprio composer.json:

<pre class="brush: jscript; title: ; notranslate" title="">"require": {
...
"openstream/dull-uploader": "v1.1.2"
...
}
</pre>

Se già si utilizza il repository <a href="https://packages.firegento.com" target="_blank">packages.firegento.com</a> non è necessario altro, alternativamente si può aggiungere il suo repo direttamente:

<pre class="brush: jscript; title: ; notranslate" title="">"repositories": {
...
{
"type": "vcs",
"url": "https://github.com/openstream/No-Flash-Image-Uploader"
}
...
}
</pre>

Se invece non si utilizza Composer, è possibile semplicemente <a href="https://github.com/openstream/No-Flash-Image-Uploader/archive/v1.1.2.zip" target="_blank">scaricare lo zip</a>, estrarlo e copiare le cartelle 

Questa è una soluzione semplice ed efficace che abbiamo individuato per un problema noioso che si presenterà da qui a qualche mese (se, come me, utilizzate <a href="https://www.chromium.org/getting-involved/dev-channel" target="_blank">il Dev channel di Chrome</a>, Flash è già stato rimosso).

Vale anche la pena ricordare che sostituire l’uploader in Flash ha anche il vantaggio di rimuovere i problemi che solitamente si presentano con l’upload delle immagini quando il sito è protetto da autenticazione http basic (una delle cause tipiche del messaggio “Upload HTTP Error”).

Se conoscete altre soluzioni al problema sentitevi liberi di segnalarle nei commenti.

Google Chrome abbandona Flash – alternativa all’uploader di Magento 1

E’ noto che la ricerca di base presente su Magento non è per nulla efficiente, poiché non restituisce i risultati attesi sia dal punto di vista dei termini trovati che del loro ordine in termini di rilevanza.

Il campo di ricerca è preferito rispetto alla navigazione per categorie, di conseguenza il corretto funzionamento di questo strumento diventa un fattore strategico per un e-commerce. Per questo motivo la sua ottimizzazione è un problema che presto o tardi ci verrà sottoposto.

In passato per ovviare a questo problema nei vari progetti abbiamo utilizzato server predisposti con 

/ElasticSearch oppure abbiamo acquistato dei moduli a pagamento come quello di 

Tuttavia il primo approccio per quanto performante non è immediato nella configurazione e personalizzazione mentre il secondo, per quanto un modulo possa essere ricco di opzioni, non riesce a coprire tutte le casistiche.

Se anche voi avete avuto esperienze analoghe e state cercando qualcosa di più convincente forse siete nel posto giusto.

 di integrazione di Magento che nel momento in cui scrivo è alla versione 1.6.1.

L’impatto iniziale è proprio quello di un modulo 

, probabilmente se avete effettuato delle personalizzazioni al campo ricerca rispetto al tema di default dovrete sistemarlo un po’ graficamente, tuttavia in questo senso, la presenza di un selettore DOM per stabilire dove far comparire i risultati nel layout di categoria  rende molto versatile il suo utilizzo nei vari progetti.

A livello di performance, utilizzando le API si sposta il problema dell’indicizzazione da un’altra parte almeno parzialmente, infatti nonostante sia possibile, se si ha un catalogo di 5000 o più prodotti, sconsiglio di indicizzare direttamente l’indice predisposto dal modulo che si occupa della sincronizzazione con Algolia. Utilizzate invece il sistema di 

 che fornisce il modulo stesso. Per la stessa ragione omettete questi indici da procedure di integrazione che prevedono alla fine un 

, pena il fatto che le stesse potrebbero impiegare diverse ore per terminare.

Il livello di personalizzazione è buono, si può decidere dal modulo che attributi oltre a quelli standard indicizzare e dal pannello di Algolia decidere le priorità tra di essi.

Non si può attribuirne il peso come avveniva per il modulo di Activo e nemmeno la granularità di precisione sui termini simili, tuttavia è un difetto che viene poco sentito, in quanto l’autocompletamento è davvero ben fatto: non si limita a proporre le parole che contengono il termine che stiamo digitando ma fornisce direttamente i relativi prodotti, categorie e e pagine così ci si accorge subito se c’è qualcosa di sbagliato piuttosto che di analogo al termine che si sta cercando.

Una menzione speciale al fatto che il modulo indicizza anche le categorie e le pagine; questo è un valore aggiunto non indifferente per e-commerce che ha un albero di categorie molto profondo.

Fino a qui sono certo di avervi almeno convinto a dargli una possibilità, tuttavia ci sono anche alcune note dolenti, cominciando dal prezzo.

Per utilizzare Algolia si hanno a disposizione 4 piani mensili, di cui il primo è gratuito a patto di lasciare visibile il logo di Algolia nelle ricerche e comunque è sufficiente solo per cataloghi con un massimo di 10.000 record, utile quindi solo ad e-commerce con un catalogo non troppo ampio.

E’ presente una configurazione del modulo con cui disabilitare la comparsa il logo di Algolia nei risultati dell’autocompletamento per i piani non gratuiti, se non lo si volesse rendere visibile.

Quello più economico è 59 USD al mese (o 49 USD al mese se si fa l’abbonamento annuale) tra quelli 

, e comprende il supporto clienti con tanto di consigli di implementazione e tuning per

migliorare la rilevanza dei propri risultati. Tuttavia e non è detto che tutti i clienti siano ben disposti alla spesa periodica per questa funzionalità.

Infine un paio di consigli: utilizzate una API KEY per ambiente (anche la vostra macchina di sviluppo) per evitare che sincronizzi indici di altri ambienti; Algolia è predisposto a questo nella sezione API KEY.

Impostate inoltre che le immagini visibili nella preview siano la small image dei prodotti, di default è la base image che sembra non funzionare correttamente.

E voi l’avete provato? avete qualche alternativa che sia allo stesso tempo perfomante e plug & play? Scrivetecelo nei commenti!

Ho aggiunto le informazioni aggiornate sul pricing segnalatomi da Gianluca nei commenti

Algolia su Magento

In Bitbull, quando partiamo con lo sviluppo di un nuovo progetto, per prima cosa ragioniamo su come “fare a pezzi” il progetto stesso, ovvero identifichiamo i componenti software che è necessario integrare per dare vita all’applicazione.

Il vantaggio principale che offre questo approccio è il 

, facilmente reperibile da repository pubblici, testato e manutenuto dalla community di sviluppatori, oppure da repository privati. La conseguenza è una 

pacchettizzare e rendere disponibili anche i propri moduli

, seguendo uno standard condiviso. Inoltre risulta agevole l’

aggiornamento dei singoli componenti a nuove versioni.

Nel mondo PHP il concetto di “aggregazione di componenti di codice riutilizzabili e disponibili su repository” non è recente: in passato era molto in voga l’utilizzo di PEAR che è un sistema di distribuzione di librerie PHP open-source, raccolte in un repository ufficiale quasi considerato un framework.

La principale differenza pratica tra PEAR e Composer è che il primo viene configurato globalmente sulla macchina in cui è installato e quindi le stesse librerie sono disponibili per tutti i progetti (con evidenti esplosioni di euforia degli sviluppatori che si trovano a gestire i conflitti di versione tra progetti diversi), mentre il secondo prevede sia delle configurazioni globali a livello di macchina, sia configurazioni locali di progetto.

Inoltre PEAR è decisamento obsoleto, come indicato già due anni fa da <a href="http://fabien.potencier.org/the-rise-of-composer-and-the-fall-of-pear.html" target="_blank">Fabien Potencier nel suo blog</a>.

Scegliamo un tool in base alla flessibilità e alla propensione al rinnovamento e quindi, ad oggi, ci focalizziamo su Composer!

: consente di dichiarare la lista delle dipendenze del progetto e le regole con cui si occuperà di scaricare e installare/aggiornare per noi questi pacchetti software all’interno del progetto.

Composer ha un repository ufficiale delle dipendenze, Packagist (<a href="https://packagist.org/" target="_blank">https://packagist.org/</a>), e un meccanismo nativo di gestione dell’autoload.

Questo il link al sito ufficiale del progetto: <a href="https://getcomposer.org/" target="_blank">https://getcomposer.org/</a>

Per poter utilizzare Composer dobbiamo procedere all’installazione; normalmente installiamo il tool a livello globale della macchina, posizionandolo in una cartella (ad es. usr/local/bin) specificata nella variabile d’ambiente $PATH, in modo che l’eseguibile (assicuratevi che lo sia dando i permessi necessari) sia disponibile ovunque.

Facendo riferimento all’ultima versione disponibile ad oggi e all’ipotesi di posizionare l’eseguibile Composer nella cartella ‘usr/local/bin’, in ambiente Unix (Linux, Mac OSX) sono sufficienti questi comandi:

<pre>$ sudo curl https://getcomposer.org/download/1.2.0/composer.phar -o /usr/local/bin/composer
$ sudo chmod +x /usr/local/bin/composer</pre>

L’approccio alla scomposizione del progetto in dipendenze, con Composer, si concretizza con due principali attività:

 che creiamo nella cartella di progetto e in cui elenchiamo i repository dove andare a recuperare i pacchetti e la lista di tutte le dipendenze, oltre ad alcune informazioni generali ed eventuali configurazioni avanzate sul progetto stesso. In questo file possiamo anche dichiarare degli script da eseguire al termine dell’installazione delle dipendenze.

Possiamo creare questo file manualmente oppure tramite il comando:

Per un approfondimento sullo schema del file composer.json fare riferimento a <a href="https://getcomposer.org/doc/04-schema.md" target="_blank">questo link</a>, per la lista completa dei comandi messi a disposizione dal tool fare riferimento a <a href="https://getcomposer.org/doc/03-cli.md" target="_blank">questo link</a>.

 occorre posizionarsi nella cartella in cui è presente il composer.json e lanciare da terminale il comando:

Questo comando scarica tutti i pacchetti dichiarati, li salva in una cartella chiamata “vendor” e crea un file autoload.php sotto la cartella vendor. Questo file è l’unico che necessita essere incluso negli script del progetto PHP.

Al termine della prima installazione delle dipendenze Composer crea il file 

 in cui vengono dichiarate tutte le dipendenze con indicazione della versione scaricata e installata.

Questo file può essere distribuito agli sviluppatori che vogliono replicare il progetto: sarà per loro sufficiente eseguire un composer install per assicurarsi di utilizzare gli stessi pacchetti e versioni dichiarati nel composer.lock.

Successivamente, in caso di modifica del file composer.json o di necessità di aggiornamento delle dipendenze dichiarate, andrà eseguito da terminale il comando

Questo comando scarica e installa le dipendenze che richiedono aggiornamento, rimuovendo la vecchia versione, e aggiorna il file composer.lock da distriibuire.

Come utilizziamo Composer con un progetto Magento?

Ma veniamo al sodo e vediamo come fare a pezzi un progetto Magento per poi lanciare un comando e trovarci magicamente di fronte un’applicazione funzionante (in realtà non è necessario alcun potere magico).

Parlerò dell’utilizzo di Composer con Magento 1, perchè Magento 2 ufficialmente supporta e incoraggia l’installazione tramite Composer.

Nel caso di un tipico progetto Magento, i “pezzi” a cui mi riferisco sono, ad esempio:

Come vedremo, il nostro progetto diventa a tutti gli effetti un 

 in quanto non conterrà codice PHP ma solo la definizione delle dipendenze di codice necessarie per il suo funzionamento.

Ecco il composer.json di esempio per un ipotetico progetto “magento_composer_example”:

<pre class="brush: jscript; title: ; notranslate" title="">{
"name": "bitbull/magento_composer_example",
"description": "Magento Composer Example Project",
"minimum-stability": "dev",
"authors": [
{"name": "Bitbull", "email": "devel@bitbull.it"}
],
"repositories":[
{"type": "composer", "url": "http://packages.firegento.com"},
{"type": "composer", "url": "http://packages.bitbull.it"},
{"type": "vcs", "url": "git@github.com:bitbull-team/mageploy.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/magento-translations-it.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/custom-example-modules.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/custom-example-theme.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/magento-deploy.git"},
{"type": "vcs", "url": "https://github.com/netz98/n98-magerun.git"},
{"type": "package",
"package": {
"type": "magento-module",
"name": "Acme_Module",
"version": "1.7.9",
"dist": {
"url": "https://bitbucket.org/bitbull/acme_module/get/v1.7.9.zip",
"type": "zip"
}
}
}
],
"require":{
"magento-hackathon/magento-composer-installer": "3.0.6",
"bitbull/magento-core": "1.9.2.4",
"bitbull/magento-cookienotice": "1.0.0",
"bitbull/magento-translations-it": "1.0.0",
"firegento/psr0autoloader": "dev-master",
"bitbull/composer-magento-example-modules" : "dev-master",
"bitbull/composer-magento-example-theme" : "dev-master",
"inchoo/php7": "1.0.3",
"bitbull/magento-deploy": "1.0.0",
"n98/magerun": "1.97.21"
},
"require-dev": {
"aleron75/webgriffe_tph-pro": "dev-master",
"pug-more/mageploy": "1.2.0"
},
"config": {
"secure-http": false
},
"extra":{
"magento-root-dir": ".",
"magento-deploystrategy": "symlink",
"magento-deploystrategy-overwrite": {
"bitbull/magento-core": "copy"
},
"magento-force": true,
"auto-append-gitignore": true
},
"autoload": {
"psr-0": {
"Bitbull": "lib/"
}
},
"scripts": {
"post-update-cmd": [
"Bitbull\Deploy\Magento::generateLocalXml",
"Bitbull\Deploy\Magento::setMaintenanceMode",
"Bitbull\Deploy\Magento::flushCache",
"Bitbull\Deploy\Magento::runUpgradeScripts",
"Bitbull\Deploy\Magento::reindexAll",
"Bitbull\Deploy\Magento::unsetMaintenanceMode"
],
"post-install-cmd": [
"Bitbull\Deploy\Magento::generateLocalXml",
"Bitbull\Deploy\Magento::setMaintenanceMode",
"Bitbull\Deploy\Magento::flushCache",
"Bitbull\Deploy\Magento::runUpgradeScripts",
"Bitbull\Deploy\Magento::reindexAll",
"Bitbull\Deploy\Magento::unsetMaintenanceMode"
]
}
}
</pre>

Vediamo nello specifico il significato delle principali direttive inserite nell’esempio; per la documentazione ufficiale e completa fate riferimento a <a href="https://getcomposer.org/doc/04-schema.md" target="_blank">questo link</a>:

La libreria magento-hackaton/magento-composer-installer

Questa libreria è la prima che includiamo in tutti i nostri progetti Magento poiché è studiata appositamente per installare moduli Magento tramite Composer, risolvendo alcune problematiche di integrazione.

è in grado di riconoscere e processare solo le dipendenze che rappresentano moduli Magento

; nel file composer.json delle singole dipendenze va impostata la tipologia di pacchetto specificando “magento-module”:

<pre class="brush: jscript; title: ; notranslate" title="">{
"name": "bitbull/magento-translations-it",
"type": "magento-module",
}
</pre>

Per noi il core Magento, il tema, tutti i moduli e la libreria che usiamo per le operazioni di deploy sono di tipo “magento-module”.

Per quanto riguarda il core di Magento, una soluzione alternativa è l’utilizzo del plugin <a href="https://github.com/AydinHassan/magento-core-composer-installer" target="_blank">Magento Core Composer Installer</a>, che nasce proprio per gestire il core di Magento come dipendenza installata con Composer, semplificando il mapping e ottimizzando la gestione del .gitignore.

Di default, in fase di installazione delle dipendenze, Composer scarica nella cartella vendor i file delle dipendenze; magento-composer-install replica questi file all’interno della root Magento in modo da creare la struttura di files e cartelle tipica di una installazione Magento standard.

Il metodo con cui rende disponibili i file dipende dalle configurazioni 

<pre class="brush: jscript; title: ; notranslate" title="">{
"extra":{
"magento-root-dir": ".",
"magento-deploystrategy": “symlink”,
"magento-deploystrategy-overwrite":  {
"bitbull/magento-core": "copy"
},
"magento-force": true
}
}
</pre>

Nel nostro caso indichiamo di deployare i moduli magento come link simbolici all’interno della struttura delle cartelle Magento, ad eccezione del pacchetto relativo al core di Magento che viene copiato.

Normalmente utilizziamo Modman per la specifica della mappatura della posizione dei files da replicare (per approfondimenti su modman <a href="https://github.com/colinmollenhour/modman/wiki/Tutorial" target="_blank">leggi questo tutorial</a>). Ulteriori opzioni sono la mappatura esplicita all’interno del composer.json oppure indicare, sempre nel composer.json tra le configurazioni “extra”, il file package.xml del modulo compilato secondo lo standard utilizzato da Magento Connect.

Questa strategia di deploy ha un comodo risvolto pratico.

Per il tema grafico e per i moduli con le personalizzazioni di progetto normalmente lavoriamo su due repository git separati (customer-project-theme e customer-project-modules) e, durante la fase di sviluppo, referenziamo le dipendenze facendo riferimento al branch master (dev-master).

In questo modo, sotto la vendor, abbiamo a tutti gli effetti due repository git su cui effettuare aggiornamenti, commit, ecc… e con la strategia di deploy “symlink” qualsiasi modifica ai pacchetti viene replicata in tempo reale sotto il path della root Magento in modo da poter lavorare senza necessità di effettuare un’operazione di composer update.

Inoltre, per chi come noi utilizza repository git, questa libreria consente di 

aggiungere in automatico al file .gitignore

 i riferimenti a tutti i file dei pacchetti integrati nel progetto come moduli magento (riconosciuti grazie alla configurazione della proprietà type).

<pre class="brush: jscript; title: ; notranslate" title="">{
"extra":{
"magento-root-dir": ".",
"auto-append-gitignore": true
}
}
</pre>

Questa integrazione con git è molto comoda poiché consente di avere nel repository git solo i files composer.json, composer.lock, .gitignore.

Come ulteriore feature la libreria consente di 

gestione dell’autoloading delle dipendenze

, tramite l’applicazione di una patch al core Magento (file app/Mage.php) che risolve l’inclusione del file di autoloading creato da Composer sotto la cartella vendor.

Questo comportamento, attivo di default, può essere disabilitato specificando la seguente configurazione:

<pre class="brush: jscript; title: ; notranslate" title="">{
"extra":{
"with-bootstrap-patch": "false"
}
}
</pre>

Quando creiamo una nuova estensione Magento, sviluppando ad esempio un modulo o il tema del cliente, ci adoperiamo per fare in modo che sia installabile come dipendenza tramite Composer.

Per fare questo è sufficiente includere un file composer.json che identifica il pacchetto, specificandone il nome (composto da vendor-name e package-name) ed eventuali ulteriori dipendenze.

Qui sotto ad esempio il file composer.json del modulo di traduzioni Magento di Bitbull.

<pre class="brush: jscript; title: ; notranslate" title="">{
"name": "bitbull/magento-translations-it",
"description": "Magento core and transactional e-mails translations in Italian",
"license":"MIT",
"type": "magento-module",
"authors":[
{
"name":"Lorena Ramonda",
"email":"lorena.ramonda@bitbull.it"
}
],
"require": {
"magento-hackathon/magento-composer-installer": "*"
}
}
</pre>

Come possiamo notare abbiamo dovuto specificare la proprietà 

 (dove “bitbull” è la vendor name) e la dipendenza con magento-hackaton/magento-composer-installer. Non è stato necessario specificare alcun repository in quanto l’unica dipendenza da soddisfare è recuperabile dal repository Composer ufficiale, Packagist.

Per indicazioni sulla creazione di librerie fare riferimento a <a href="https://getcomposer.org/doc/02-libraries.md" target="_blank">questo link</a>.

Tutte le funzionalità che potrebbero essere messe a fattor comune su diversi progetti vengono soddisfatte con moduli esistenti (community, Bitbull, altri fornitori) , distribuiti come pacchetti singoli, e quindi indipendenti dal progetto su cui è nata l’esigenza di integrazione.

Tutti questi moduli vengono referenziati nel composer.json facendo riferimento, per la versione, ad uno specifico tag.

I moduli custom del progetto (tema e personalizzazioni), come detto, vengono installati facendo riferimento al branch master dei relativi repository per poter essere aggiornati velocemente in fase di sviluppo.

Una volta pronti per il go-live creiamo una release, sia per questi moduli personalizzati sia per il meta-progetto, aggiungendo un tag alla versione corrente e specificandola nel file composer.json del pacchetto.

Scopo finale è avere, nel composer.json del meta-progetto, tutte le dipendenze con riferimento a tag specifici. In questo modo in caso di aggiornamento delle dipendenze non si rischia di integrare nell’applicazione versioni di codice non ancora testate o magari non compatibili.

Per una panoramica completa sulla specifica delle versioni il riferimento è <a href="https://getcomposer.org/doc/articles/versions.md" target="_blank">questo link</a>.

Usare Composer non è complesso, bisogna solo iniziare, e ragionare sempre in ottica di riutilizzo del codice, di pacchettizzazione dei propri sviluppi, di versioning e di flessibilità perché, come abbiamo visto, possiamo veramente integrare tutto il necessario, dal setup al deploy di un progetto.

Inoltre in un unico file abbiamo la visione di tutto quello che è installato nel progetto, una sorta di carta di identità e possiamo automatizzare le operazioni di aggiunta e rimozione di estensioni, riducendo gli errori dovuti inevitabilmente all’intervento manuale.

Composer: come “facciamo a pezzi” un progetto Magento

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?

Satispay per Magento – Pagamenti semplificati

Prima di sviluppare qualsiasi funzionalità è bene verificare che qualcuno non ci abbia già pensato, un dogma piuttosto consolidato per chi si occupa di sviluppo software, noto come “non reinventare la ruota”.

La competenza è quindi, spesso, discernere tra le soluzioni trovate, quelle ritenute più corrette.

Nei casi più sfortunati non ne troviamo nessuna che ci convinca o che ci fornisca anche solo una traccia da cui partire.

È il caso dell’ordinamento delle voci di menù nell’account cliente e dell’ordine di caricamento dei javascript e css nei layout xml.

Qualora volessi aggiungere un mio javascript e accertarmi che venga eseguito prima di altri script di sistema oppure volessi mettere una voce subito dopo Account nell’area cliente, la soluzione che si trova in rete è la seguente ed è comune ai 2 scenari:

Di seguito i file relativi a un modulo che propone un metodo alternativo con relativa spiegazione dei passaggi:

<?xml version="1.0"?>
<config>
    <modules>
        <Bitbull_SimpleOrder>
            <active>true</active>
            <codePool>local</codePool>
            <depends>
                <Mage_Customer/>
                <Mage_Page/>
            </depends>
        </Bitbull_SimpleOrder>
    </modules>
</config>

Essenzialmente dichiariamo l’esistenza del modulo con le dipendenze dei moduli che andremo ad estendere

app/code/local/Bitbull/SimpleOrder/etc/config.xml

<?xml version="1.0"?>
<config>
    <modules>
        <Bitbull_SimpleOrder>
            <version>0.1.0</version>
        </Bitbull_SimpleOrder>
    </modules>
    <global>
        <blocks>
            <bitbull_simpleorder>
                <class>Bitbull_SimpleOrder_Block</class>
            </bitbull_simpleorder>
            <customer>
                <rewrite>
<account_navigation>Bitbull_SimpleOrder_Block_Customer_Account_Navigation</account_navigation></rewrite>
            </customer>
            <page>
                <rewrite>
                    <html_head>Bitbull_SimpleOrder_Block_Page_Html_Head</html_head>
                </rewrite>
            </page>
        </blocks>
        <helpers>
            <bitbull_simpleorder>
                <class>Bitbull_SimpleOrder_Helper</class>
            </bitbull_simpleorder>
        </helpers>
<events>
            <controller_action_postdispatch>
                <observers>
                    <bitbull_simpleorder>
                            <type>singleton</type>
                            <class>bitbull_simpleorder/observer</class>
                            <method>checkForLayoutDisplayRequest</method>
                        </bitbull_simpleorder>
                    </observers>
                    </controller_action_postdispatch>
            </events>
    </global>
    <frontend>
        <layout>
            <updates>
                <bitbull_simpleorder>
                    <file>bitbull_simpleorder.xml</file>
                </bitbull_simpleorder>
            </updates>
        </layout>
    </frontend>
</config>

Non essendoci observer adatti per il comportamento che dobbiamo sovrascrivere vengono effettuati direttamente il rewrite dei moduli base. L’observer dichiarato è stato aggiunto a seguito della scrittura dell’articolo, e ne spiego il funzionamento in coda all’articolo.

app/code/local/Bitbull/SimpleOrder/Block/Customer/Account/Navigation.php

<?php
 
class Bitbull_SimpleOrder_Block_Customer_Account_Navigation extends Mage_Customer_Block_Account_Navigation {
 
    protected $_currentPosition = 0;
 
 
    public function getLinks()
    {
        if(count($this->_links)){
            $this->_links = Mage::helper('bitbull_simpleorder')->sortElementsByPosition($this->_links);
        }
 
        return parent::getLinks();
    }
 
    public function addLink($name, $path, $label, $urlParams = array(), $position = null)
    {
        if (!$position) {
            $this->_currentPosition += 10 + $this->_currentPosition;
            $position = $this->_currentPosition;
        }
        $this->_links[$name] = new Varien_Object(array(
            'name' => $name,
            'path' => $path,
            'label' => $label,
            'url' => $this->getUrl($path, $urlParams),
            'position' => $position
        ));
        return $this;
    }
}

Ed eccoci alla parte interessante del modulo. L’idea prende spunto dalla dichiarazione e gestione dell’ordinamento delle configurazioni del control panel (il sort_order nei system.xml).

Il metodo getLinks non fa altro che richiamare un metodo dell’helper che si occupa di riordinare gli elementi in base all’attributo o chiave “position”.

Il metodo addLink come avrete già dedotto si occupa di aggiungere ai links l’attributo position che dichiareremo nell’xml per il nostro link. Ma non solo: gli elementi già esistenti non hanno una position quindi non funzionerebbe, per questo il primo if serve ad assegnargliene una se non viene passata tramite il parametro position (ovvero tutti gli elementi tranne quelli che dichiareremo noi o sovrascriveremo).

app/code/local/Bitbull/SimpleOrder/Helper/Data.php

class Bitbull_SimpleOrder_Helper_Data extends Mage_Core_Helper_Abstract {
 
    public function sortElementsByPosition($elements){
        if( is_array(reset($elements))){
            usort($elements, array($this, 'cmpArrayPositions'));
        }elseif(is_object(reset($elements))){
            usort($elements, array($this, 'cmpObjectPositions'));
        }
        return $elements;
    }
 
    private function cmpArrayPositions($a,$b){
        return $a['position'] > $b['position'];
    }
 
    private function cmpObjectPositions($a,$b){
        return $a->position > $b->position;
    }
}

l’helper essenzialmente si occupa di ordinare tramite una callback interna allo stesso gli elementi che siano array o oggetti per “position”.

app/code/local/Bitbull/SimpleOrder/Block/Page/Html/Head.php

<?php
class Bitbull_SimpleOrder_Block_Page_Html_Head extends Mage_Page_Block_Html_Head {
     
    protected $_currentPosition = 0;
     
 
    public function addItem($type, $name, $params=null, $if=null, $cond=null,$position = null)
    {
        if(empty($if)){
            $if = null;
        }
        if(empty($cond)){
            $cond = null;
        }
 
        if (!$position) {
            $this->_currentPosition = 10 + $this->_currentPosition;
            $position = $this->_currentPosition;
        }
        if ($type==='skin_css' && empty($params)) {
            $params = 'media="all"';
        }
        $this->_data['items'][$type.'/'.$name] = array(
            'type'     => $type,
            'name'     => $name,
            'params'   => $params,
            'if'       => $if,
            'cond'     => $cond,
            'position' => $position
       );
        return $this;
    }
 
    public function getCssJsHtml(){
        $this->_data['items']= Mage::helper('bitbull_simpleorder')->sortElementsByPosition($this->_data['items']);
        return parent::getCssJsHtml();
    }
}

In realtà il modulo è già praticamente finito, in quanto qui viene proposto il blocco con la medesima logica per ordinare js e css al momento del load, mentre prima erano le voci relative all’account del customer.

Bitbull

Magento 1

Il footer di Magento 1 è un blocco cachato

Rilasciato il modulo Magento per l’integrazione con Tooso Search

Google Chrome abbandona Flash – alternativa all’uploader di Magento 1

Algolia su Magento

Composer: come “facciamo a pezzi” un progetto Magento

Satispay per Magento – Pagamenti semplificati

Riordinare le voci nell’area clienti ed i js e css: the right way

Si fa presto a dire “deploy” !

Primi passi con lo sviluppo front end su Magento