L’Online Store 2.0 è stato annunciato durante l’edizione 2021 di Shopify Unite. Ha notevolmente semplificato l’esperienza dei merchant durante la personalizzazione dei temi, perché consente di creare nuovi template pagina, prodotto e blog direttamente dall’editor del tema. Ha anche introdotto la possibilità di inserire sezioni dinamiche all’interno di tutti questi template, non solo nella homepage.
La migrazione a un tema Shopify 2.0 è una delle richieste più frequenti che stiamo ricevendo, sia da parte di quei merchant che non sono soddisfatti del tema che stanno utilizzando al momento, sia da parte di chi vuole sfruttare a pieno la flessibilità della nuova infrastruttura.
Abbiamo appena completato la nostra prima migrazione, e con questo articolo ci piacerebbe condividere alcune delle lezioni apprese attraverso quest’esperienza.
Come impostare la migrazione
In linea generale, ci sono tre diversi strade che si possono intraprendere per una migrazione a un tema 2.0
- Scaricando una nuova versione del tema attuale
- Migrando manualmente il tema attuale
- Scegliendo un nuovo tema
Per aiutare i merchant a valutare se e come procedere con la migrazione, Shopify ha preparato una checklist (in inglese) molto completa, confrontando i vantaggi e svantaggi di ciascun approccio. Proviamo a riassumere un po’ le tre scelte.
Per qui merchant non soddisfatti sia a livello grafico che a livello funzionale del loro tema attuale e che necessitano delle funzionalità 2.0, ha senso selezionare un tema completamente nuovo. Al momento sono disponibili 81 temi compatibili con l’architettura 2.0 sul Theme Store Shopify.
Se invece si vuole mantenere lo stile del tema attuale, le strade da intraprendere sono due.
La prima prende come punto di partenza la versione più recente del tema già utilizzato dal merchant. Infatti, molti dei merchant già su Shopify utilizzano un tema a pagamento acquistato dallo store ufficiale di temi Shopify. Lo sviluppatore del tema potrebbe aver già rilasciato la versione 2.0 del tema base, con bugfix e ottimizzazione delle prestazioni in termini di velocità e accessibilità. Il merchant può quindi scaricare gratuitamente sullo store la versione 2.0 del tema e poi chiedere a uno sviluppatore di riprodurre le funzionalità custom che erano state aggiunte al tema precedente. Una volta aggiunto e testato il codice custom, bisognerà procedere con il setup tramite editor del tema di tutte le sezioni, colori, menu che sono presenti nel tema attuale, poiché con la nuova struttura non si possono semplicemente impostare con il codice.
La seconda strada invece prende come punto di partenza il codice del tema attualmente pubblicato, e prevede la migrazione manuale di tutti i template dal formato .liquid a quello .json, seguendo la guida ufficiale pubblicata da Shopify. Infatti, le funzionalità dell’Online Store 2.0 come ad esempio le sezioni in tutte le pagine, i metafield dinamici e le App extension sono compatibili solo con i template in formato .json (mentre i temi che possiamo chiamare 1.0 utilizzano template in formato .liquid). Bisognerà quindi lavorare su una copia del tema e manualmente spostare tutta la logica di Liquid e JavaScript di ciascun template pagina, prodotto, collezione o blog in delle nuove sezioni, alle quali poi si farà riferimento nell’oggetto json che sarà parte del nuovo template.
Entrambi gli approcci sono validi e adatti a diversi tipi di migrazione.
Nel nostro caso, per questo primo progetto abbiamo deciso di seguire la prima strada (ri-aggiungere il codice custom ad una nuova versione del tema a pagamento), sia per motivi legati al codice del tema sia perché il nostro cliente era interessato non solo a migrare il tema, ma anche a ottimizzare i processi interni di gestione e compilazione dei dati/contenuti. Questi sono i tre elementi principali che abbiamo preso in considerazione per scegliere l’approccio:
- quantità e qualità del codice custom già presente nel tema
- codice residuo lasciato da app esterne non più utilizzate
- piano di ristrutturazione dati (registrazione di nuovi metafield, riorganizzazione delle opzioni variante, filtri collezione)
Un elemento cruciale di quest’approccio è concordare con il cliente la lista di interventi e feature necessarie per il nuovo tema. Si è trattato di un passaggio particolarmente importante nel nostro caso, poiché uno dei focus era l’automazione di molte delle logiche di front end per ridurre le tempistiche di registrazione prodotti e ottimizzare i processi di logistica dello store.
Cosa abbiamo imparato
Poiché si è trattato della nostra prima migrazione, questo progetto ha incluso una parte di apprendimento empirico, soprattutto nella configurazione della pipeline di sviluppo. Ovviamente è solo il primo mattoncino di conoscenza e sarà sicuramente una buona base per i progetti futuri.
1. Serve davvero un development store?
Ogni volta che comincio un nuovo progetto, inizio sempre con la configurazione di un development store, ed è quindi quello che ho fatto anche in questo caso. Lavorare su una migrazione di un tema 2.0 tra due store comporta una maggiore complessità, soprattutto se si utilizzano i tool di sviluppo consigliati da Shopify: Shopify CLI e integrazione con Github.
In sintesi, se il progetto prevede la riorganizzazione dei dati di prodotto o collezione, consiglierei di creare un development store, tuttavia se si tratta di una semplice migrazione del tema utilizzando gli stessi template prodotto e pagina, è più facile lavorare direttamente su un tema non pubblicato nello stesso negozio.
Quali sono i vantaggi del lavorare su un development store?
- Si possono modificare i dati prodotto senza avere impatto sullo store live, nel quale le vendite possono continuare mentre si lavora sulla migrazione
- Si possono creare nuovi template e assegnarli direttamente ai prodotti e alle pagine dall’admin senza bisogno di aggiungerli al tema live. Facciamo un esempio pratico. Nel nostro caso, abbiamo creato un nuovo template prodotto specifico per i prodotti realizzati su ordinazione, che prevedeva una logica per visualizzare i tempi di consegna sulla base di un metafield prodotto e un form custom per inserire misure come altezza e peso. Nel development store abbiamo potuto creare il nuovo template e renderlo disponibile nell'admin (aggiungendolo al tema pubblicato), dove è stato assegnato a uno dei prodotti. In questo modo abbiamo potuto effettuare un ordine di prova e assicurarci che i dati inseriti nel form e la stringa con i tempi di consegna fossero passati al carrello e ricevuti correttamente nell’ordine.
- Si possono installare e testare app che poi sostituiranno altre app utilizzate nello store live. Ad esempio, abbiamo consigliato la nostra app di traduzioni di riferimento e l’abbiamo configurata nel development store. Al momento del go live, è bastato importare le traduzioni e i file di configurazione nell’altro store e verificare che tutto funzionasse correttamente.
Se si decide di procedere con lo sviluppo sul development store, consigliamo di usare una app come Matrixify per esportare una copia dei prodotti, delle pagine e dei file dallo store live e importarli sul development store di modo da avere un ambiente di test il più possibile simile allo store live. Punti bonus: assicurasi di importare le immagini e i file utilizzando lo stesso nome, in modo che vengano riconosciute anche sul negozio live (più info nel prossimo punto)
2. Strategie per la pipeline Github
Per questo progetto, ho utilizzato il toolkit raccomandato da Shopify: Shopify Theme CLI e l'integrazione con Github, entrambe annunciate in occasione di Shopify Unite l'anno scorso. Lavorare su due store con l'integrazione di Github e il codice nello stesso repository non è molto semplice, ma l'integrazione Github è molto utile per tenere traccia di tutte le modifiche apportate al codice dalle app e tramite l'editor del tema.
Per impostare il flusso di lavoro, ho effettuato l'accesso al negozio utilizzando Shopify theme CLI, ho scaricato la versione 2.0 del tema utilizzando shopify theme pull --theme themeID, l'ho caricato su Github e quindi ho collegato una delle mie branch al development store.
La branch staging è sempre stata collegata al tema pubblicato nel development store, mentre la branch main è stata collegata a un tema non pubblicato nello store live. Nella prima fase di sviluppo, ossia mentre stavo lavorando sul codice base del tema senza iniziare il setup tramite l’editor del tema, ho lavorato sulle diverse feature in locale usando shopify theme serve, e poi pubblicate su un tema nel development store usando shopify theme push --unpublished, di modo da renderle visibili anche al resto del team. Quindi, ad esempio, ho lavorato sulle modifiche al cart nella branch feature/cart-changes, usato shopify theme push —unpublished per aggiungere un tema chiamato Rossella [dev] al development store e chiesto del feedback. Una volta approvate, ho fatto merge della mia branch feature/cart-changes con staging, automaticamente connessa al tema pubblicato nel development store.
Una volta finito di lavorare sullo scheletro del tema, abbiamo iniziato con le impostazioni dall’editor del tema nel development store. Grazie all’integrazione Github, tutte le impostazioni modificate tramite editor di tema venivano automaticamente sincronizzate con la mia branch staging su Github.
A questo punto ho fatto un merge di staging su main, per assicurarmi che le impostazioni restassero attive anche in uno store diverso. E sia le impostazioni che le immagini (tutte quelle con lo stesso identico nome file tra live e development store) hanno funzionato alla perfezione. Ovviamente per controllare le pagine prodotto abbiamo dovuto aspettare il giorno del go live, poiché i dati prodotto non erano ancora stati modificati.
Una volta pronti a fare deployment del nuovo tema, ho smesso di fare merge tra la branch staging e main, per non causare una sovrascrizione delle impostazioni tra i due temi.
3. Assicuratevi di avere abbastanza tempo per il setup del tema e per i fix post lancio
Aver collegato la branch main a un tema non pubblicato sul negozio principale è stato molto utile nel momento del setup di quelle app che non erano installate sul development store, come ad esempio Trustpilot o instagram feed. Uno dei vantaggi dei temi 2.0 è quello di poter aggiungere le app compatibili direttamente dall’editor del tema, senza codice che rischia di essere lasciato sul tema una volta disinstallata la app.
Un consiglio: se state lavorando su un negozio multilingua, dedicate tempo sufficiente a QA e testing delle diverse pagine, soprattutto per quanto riguarda i selettori variante e le traduzioni custom dei colori in pagina collezione e pagina prodotto.
E come sempre, siate pronti a qualsiasi evenienza! :-) Abbiamo imparato ad esempio che alcune app aggiungono codice non appena il tema viene pubblicato. Grazie all’integrazione Github è però facile tenere conto di qualsiasi nuova linea di codice che viene aggiunta al tema e rimuoverla se la app non è necessaria.
Lavorare alla nostra prima migrazione del tema 2.0 è stata un'esperienza di apprendimento importante. La documentazione ufficiale di Shopify, nonché la comunità degli sviluppatori nello Shopify Partner Slack, sono stati fondamentali per aiutarmi a capire tutte le diverse opzioni che avevo per strutturare il mio progetto.
E voi avete già completato una migrazione all’Online Store 2.0 usando il nuovo toolkit che include Shopify Theme CLI e l'integrazione con Github? Come sempre, se avete feedback, potete contattarmi qui: rossella@namastudio.it
