 Buon pomeriggio a tutti, come già sono stato introdotto, sono Luigi Deschio e da circa un anno sono al Senior Software Engineer Press Automatic, principalmente sono uno dei mantegneri del progetto commerce blocks e il nostro obiettivo è quello di portare i blocchi e il site editor all'interno dell'esperienza of commerce. Quindi da circa un anno che lavoro a stretto contatto con i blocchi con Gutenberg e l'obiettivo di questo talk sarà quello di condividere tutto quello che so, condividere tutti i vantaggi del site editor dal punto di vista sia di un utente che di uno sviluppatore. Quanti di voi utilizzano un page builder che non sia Gutenberg? Ok, abbastanza. Proverò almeno di a commincervi a provarlo e poi non so, potete mandarmi feedback. Ok, quindi innanzitutto parleremo dei core blocks, quindi se utilizzate WordPress, se utilizzate Gutenberg sicuramente avrete utilizzato i core blocks. Successivamente vedremo da cosa è formato un blocco base, un semplice blocco. Successivamente parleremo del site editor e perché è importante per WordPress, per il futuro dell'ecosistema. Poi vedremo come è facile iniziare con lo sviluppo di un blocco perché in questi due giorni ho visto che molte persone tendono difficoltà ad approcciarsi con uno sviluppo di un blocco e vedremo che è davvero molto facile. Prima di parlare dei blocchi è giusto dare una definizione di blocco. Interessante la definizione del blocco protocolo al quale è un protocolo a cui sta collaborando anche automatic. Secondo questo protocolo i blocchi sono alla base che possiamo precarare i pagini sul web moderno. Sono sezioni riattengolari che contengono una serie di feature e funzioni. A volte vengono chiamati anche componenti o widget, soprattutto se avete sviluppato i React o Angular sicuramente siete a conoscenza del concetto di blocco. Lo scopo di questo protocolo è che potenzialmente questi blocchi possono essere i sessi blocchi senza nessuna modifica che possono essere utilizzati su più editor che non sia solo Gutenberg. Automatic sta collaborando a questo progetto, a questi API. Ok, ce l'ho fatta. Qui in immagine trovate due esempi di blocchi che trovate prestalati in Gutenberg, sono blocchi che sicuramente avrete avvisto almeno una volta e diciamo sono i blocco testo e blocco immagini. Nella sidebar laterale potete vedere alcune possibilità di costumizzazione, per esempio per il blocco testo possiamo modificare il coloro del testo, il background, il coloro del link, la grandezza dei caratteri, mentre per il blocco immagina possiamo modificare i bordi. Possiamo invece poter farli tundi. Quindi capite che livello di costumizzabilità di questi blocchi è davvero molto molto alto. Ok, grazie. È così alto il livello di costumizzato dei blocchi, tante che è nato il MOBA, Museum of Block Art, a cui invito tutti a andare a visitare. Fondamentalmente i blocchi vengono definiti come pezzi d'arte e questa immagine qui è stata creata semplicemente con dei blocchi che trovate prestalati in Wordpress. È interessantissimo, se andate su questo sito potete copiare e incollare il codice che si trova su MOBA e per magia questa immagine apparirà anche sul vostro editor in Gutenberg. Ovviamente non c'è solo questa, questa immagine ma c'è veramente come se fosse un museum virtuale, quindi c'è davvero un'intera galleria. Ok, adesso vedremo, diciamo, velocemente da cosa è formata un blocco base, un semplice blocco. Quindi un blocco si può dividere, diciamo, il blocco si divide in due parti. Lato editor, cioè quando appunto lavorate a stritto contatto con Gutenberg, quando è pubblicata un post o una pagina. Lato front-end, cioè quando è pubblicata la pagina andata a vedere il reale front, quello che vedrà il visitatore del sito web. Questo è il block JSON, cioè tutti metadata che le proprietà, le caratteristiche del blocco. Per esempio possiamo vedere che il nome, il titolo, l'icona, la categoria, non si attene presente quando aggiungete un blocco, ci sono i vari categorie. Ovviamente ci sono tantissime altre, tantissime altre proprietà a cui invito andare a vedere se iniziate a lavorare con dei blocchi. Questo è come avviene la registrazione di un blocco alla WHP. Come vedete è davvero molto semplice la registrazione di un blocco. Viene invocata la funzione register block type, qui viene passata la folder dove si trova il blocco. Successivamente la registrazione avviene anche lato JavaScript. In questo caso ci sono due chiavi, una edit e un'altra save. Se avete famiglietà con React questo è JSX. Nell'edit si può descrivere come il blocco si deve comportare nell'editor. Mentre il save è la funzione che serve a salvare le informazioni e le database nella colonna post content di WordPress. Quindi fondamentalmente vengono salvati gli attributi che poi in automatico vengono srealizzati da WordPress. Questo è il post content come vedete. È un esempio di blocco che abbiamo visto prima. È un paragrafo che contiene lo style background. Tutte queste informazioni vengono strate nel database in modo tale che queste informazioni vengono salvate in modo tale che vengono caricate da WordPress quando l'utente visita la pagina, sia lato frontend che lato editor. Abbiamo visto diciamo che i blocchi sono un'esperienza importante per il post, il page editor. Adesso vediamo perché per quanto mi riguarda il site editor è davvero il futuro di WordPress. Una cosa che mi ha sempre corpito di WordPress è il motto e il concetto che WordPress deve essere un software disegnato per tutti che empatizza la accessibilità, la performance e la facilità di utilizzo. Secondo zappi e report, il 70% delle non applicazioni saranno sviluppate con no code tool entro nel 2050. Quindi per questo è nato il site editor. Portare l'esperienza del post page editor al next level, quindi portare la missione di WordPress a livello successivo. Quindi possiamo dire che il site editor, la modalità di modifica completa del sito, consiste in una raccorta di funzionalità inter-collelate che sblocca la possibilità di modificare l'intero sito usando i blocchi. Questa opzione consente di sfruttare l'esperienza familiare e flessibile dell'editor a blocchi in più punti. Quindi fondamentalmente la stessa esperienza che avete quando scrivete un post, scrivete una pagina e la avete per modificare tutto il sito web. Quindi cosa vuol dire? Adio page builder custom. Finalmente abbiamo un'esperienza nativa in WordPress. Questa è una cosa molto importante, soprattutto per il concetto di back-word compatibility che è il riso famoso WordPress e per cui penso è uno dei motivi per cui è uno dei CMS più utilizzato al mondo. Il fatto che qualunque cosa, che qualunque API ufficiale viene sopportata a lifetime, quindi mi è capitato di leggere su internet che dopo un aggiornamento di WordPress si rotta il sito web perché utilizzava una versione vecchia di un page builder oppure un page builder non è stato aggiornato. Con Gutenberg questo non succede. UI x40 vuol dire che finalmente c'è un tool kit di design, c'è le settings, le troviamo le settings, l'user experience è corente in tutta l'esperienza. Quindi le settings le trovate sempre nella sidebar a destra. Come abbiamo detto aggiungere i blocchi sarà sempre la stessa esperienza per la pagina sia per modificare tutto il sito. E poi soluzioni custom, una leciandosi internet molti sviluppatori hanno paura che diciamo con no code tool diciamo non ci sarà più bisogno di sviluppatori e questo è un letto che è anche una preoccupazione della community of work. Ora se Gutenberg vuole sostituire sviluppatori ma non è così. Immaginate se siete un'agenzia, potete sviluppare un blocco che quindi è un pacchetto di funzionalità e lo stesso blocco lo potete ricondividere facilmente per più clienti. Anzi si favorisce tape la possibilità di avere più soluzioni casso in un modo più facile, soprattutto scalabile. Adesso, non so se avete presente Wordpress.org, sicuramente se avete installato Wordpress, questo è un tema blocking, è possibile modificare il tema grazie al site editor. Questa è una piccola live demo che ho fatto. Sto modificando l'on-page, ci sto cambiando il testo, sto facendo customizzazioni, come vedete l'esperienza è davvero molto facile per chiunque, sia per un utente alle prime armi che per uno sviluppatore. Adesso sto cambiando il testo, è possibile cambiare il background, è possibile cambiare la disposizione degli elementi con un drag-and-drop, sto cambiando i bordi. E fondamentalmente è importante capire come sia pixel perfect questa esperienza perché una volta che clicco save, le stessi modifiche uno a uno sono immediatamente disponibili l'auto front-end. E questo è possibile grazie ai blocchi del site editor. Voi potete pensare che ho modificato soltanto il on-page, ma non è così, Perchè una prossima slide, per esempio adesso posso cercare il concetto di template, quindi adesso ho selezionato il template page to load e quindi adesso posso modificare la pagina to load. Quindi tutte le pagine sono facilmente modificabili. Anche qui sto cambiando il background, esperienza pixel perfect, cioè vuol dire quando clicco salva l'anteprima che vedo qui sarà identica a risultato finale. Possiamo andare avanti? Ok, uno dei side effects di page-builder custom è le performance leggo su internet che chiunque si lamenta delle performance e page-builder, ma invece per Gutenberg, per il progetto Gutenberg, le performance sono al primo posto. Questo è un lighthouse test che ho fatto su WordPress .org che ho modificato nei video precedenti e come potete vedere lo scorrecento su tutto. Quindi le performance sono importanti per il team di Gutenberg e per tutti i team che lavorano con i blocchi in automati. Vi ho parlato di VCommerce Blocks e di quello che stiamo facendo e stiamo lavorando tantissimo per rapportare questa esperienza del site editor in VCommerce. Come potete vedere abbiamo il blocco mini cart e possiamo aggiungere un ladder, possiamo modificarlo e possiamo aggiungere sotto alla pagina di shop le varie categorie, tutto tramite user interface. Una cosa che ho saputo quando ho lavorato in automati è che prima i temi diciamo dovremmo impreventare il carrello. Mentre adesso grazie a questo blocco, qualunque bloc team è compatibile con VCommerce e questo a mio avviso è una cosa pazzesca. Questo è un altro concetto di un altro finito veramente interessante dei blocchi e le salvaration. Fondamentalmente i blocchi si adattano alle salvaration quindi immagino un teme developer potrebbe iniziare a sviluppare un bloc team e un bloc team avrà più variation quindi un tema con una variation sarà deployato su un sito di un cliente e lo stesso tema con una diversa variation sarà deployato su un sito di un altro cliente e come potete vedere questo rende la scalabilità, diciamo i progetti, i temi, i blocchi veramente scalabili. Ok vediamo come creare un blocco. Se siete sviluppatori web, se avete utilizzato React Angular, sapete benissimo che è veramente facile iniziare un progetto, un costituto e framework, almeno il codice iniziale. Noi abbiamo questa sfilazione da create React app e questo comando fa, diciamo, crea tutto il codice boilerplate per iniziare a focalizzare, quindi crea tutto il codice boilerplate e il sviluppatore può focalizzarsi soltanto sulla creazione di un blocco quindi se siete sviluppatori web, niente configurazioni custom webpack, niente linting, tutto nativo, tutto già pronto. Questa è una piccola demo che ho fatto, semplicemente lancio il comando, mi verrà chiesto il titolo del plugin, la categoria del plugin e tutte queste informazioni servivano per generare un corretto boilerplate per facilitare appunto la developer experience. Ok, è un'altra cosa interessantissima che è un bus pazzesco per la developer experience e l'attore loading. Questo è il codice che mi ha generato il comando che abbiamo visto prima, aggiungo il blocco di testo e come ho fatto una modifica e la modifica senza l'accionamento della pagina è apparsa su Lator, adesso sto modificando CSS e la modifica appare in automatico anche su Lator. Quindi noi mettiamo la developer experience al primo posto, developer developers, è un meme molto famoso nella community di sviluppatori e in questo momento come diciamo noi puntiamo tanto nella community e vogliamo tanto che i sviluppatori iniziano a sviluppare i blocchi. Qui sono alcuni link che ho messo per l'iniquità per creare un blocco, il blocco può essere un validatore di un blocco per vedere se un blocco è possibile caricarlo all'interno di WordPress.org e soprattutto ho messo il link alla documentazione. Ci stiamo lavorando, ancora la documentazione, sappiamo che non è perfetta ma davvero ci stiamo investendo davvero tanto tempo per creare una giusta developer experience. Questi sono i miei contatti, mi trovate GigiTux ovunque su internet. Vi consiglio se avete feedback di qualunque tipo di aprire un issue su Gutenberg. Ogni cosa in Gutenberg è ancora in discussione, nulla è scritta nella pietra, quindi è importante avere feedback iterare sui concetti che si stanno adesso se avete idee aprite issue, sia su Gutenberg sia su commerce blocks è importante. I feedback sono la chiave del successo del progetto di Gutenberg e della filosofia dei blocchi. Quindi vi consiglio anche di generare il canale WordPress Slack e l'assesso per il canale VCommerce. Pensate che il 23 novembre c'è una sessione che terrò io sul Slack sul canale VCommerce al quale potete accedere i channel developers e qui risponderò tutte le domande di qualunque tipo sui blocchi in quanto appunto come sto cercando di rivadire è davvero importante che i sviluppatori iniziano a sviluppare blocchi. Vi ringrazio per l'ascolto e se avete domande sono qui diciamo per rispondere. Grazie. Prima delle domande una piccola cosa da noi per l'Italia. Grazie. Allora abiamo domande? Sì. Ciao, intanto volevo sapere. Prima ho visto che nella parte di costruzione dei blocchi c'è una divisione tra l'edit e il save. Siccome i blocchi sono pensati per essere pixel perfect tra la parte di back end e il front perché c'è questa divisione quant'è che ha senso che la parte di edit si è differente poi da quella che viene effettivamente salvata. Ok, bella interessante domanda e il save è semplicemente un modo per dire a volte presto come salvare le informazioni ok? Quindi semplicemente sono le informazioni che vengono sorrate che vengono sorrate che vengono sorrate all'interno del database. Poi l'editor diciamo è la parte del JavaScript che viene che viene caricato sul lato editor e poi c'è anche un'altra parte che è un altro JavaScript un file JavaScript che invece in realtà dipende dall'approccio perché poi puoi avere un blocco server side render it un blocco client side render it quindi nel caso vuoi un client side render it, il front end sarà gestito ad un file JavaScript. Se vuoi un file, se vuoi un blocco server side render it invece sarà PHP. Quest'importante è in patting bu commerce blocs, stiamo lavorando tantissimo sul concetto di server side con l'internaziona quindi se avete lavorato con remix, con i framework diversi e tutti questi concetti insistono e diciamo siamo cercando di portare questi concetti in wordpress, in bu commerce o delle demo dopo sul concetto di traduzione ovviamente tutte queste demo sono disponibili su kutemberg sul nostro ripo di bu commerce blocs. Diciamo la sfida per quanto riguarda l'iterazione quindi avere un blocco server side ma comunque dinamico è davvero grossa perché per quanto riguarda i server act component sia il back end che il front end è tutto scritto in JavaScript mentre qui adesso ci troviamo con un back end in PHP e un front end in JavaScript quindi è un po' più complicato ci stiamo lavorando, pensiamo di trovare una, c'è abbiamo una soluzione adesso la stiamo validando, stiamo vedendo le performance ma tutti gli esperimenti che stiamo facendo sono tutti open source quindi se sei interessato al concetto di traduzione, se sei interessato al concetto di diciamo di capire come funzionano i blocchi, le varie possibili implementazioni il lado front end per aumentare le performance, ti possono condividere tutte le issue, tutte le purrequests anche se vuoi vedere solo qualche demo. Quindi. Ok, altre domande? Per quanto riguarda la sovraschitura nei child posso che è un'altra filosofia anche per la gestione dei temi ci sarà ancora una certa libertà con yook o in altro modo di andare a intervenire su quello che viene assolutamente importante, le sensibilità non sarà delegato solo alle le opzioni del blocco. Assolutamente non ha l'essensibilità e continuerà a essere una parte coro del progetto WordPress, cioè l'essensibilità oltre alla compatibilità lifetime è uno dei motivi per più WordPress e il CMS è utilizzato quindi stiamo lavorando, c'è esistono già dei filtri sia lato PHP sia lato JavaScript per appunto customizzare i blocchi dopo se voi ti posso far vedere un esempio non so se è mai lavorato con il query loop bloc. Ok ti posso far vedere una demo di vcommerce blocs come stiamo creando una variazione di quel blocco semplicemente ok mi fa piacere che se voi dopo ti faccio vedere ti faccio vedere semplicemente noi stiamo creando delle customizzazioni on top di quel blocco quindi non stiamo facendo copiancola del codice ma semplicemente solo aggiungendo customizzazioni. In volta WordPress 6.1 il mio team si è occupato appunto di creare un filtro all'interno del query loop bloc per passare un query custom quindi adesso ti aggancio ok mi fa piacere che il nostro lavoro è apprezzato e però come ho già ribadito è importante che tutta la community apre issue diciamo espone i propri problemi per esempio su vcommerce blocs vi posso assicurare che dopo due giorni c'è una risposta al massimo possiamo dirvi non fa parte della nostra roadmap però sicuramente vi risponderemo soprattutto per quanto riguarda vcommerce blocs la roadmap è completamente pubblica se andate sul developer vcommerce.com c'è un post che indica la roadmap dell'ultimo quarter i nostri obiettivi quindi c'è anche una persona che ha che ha chiesto dei feedback sul product query diciamo ci abbiamo risposta in tempo un giorno quindi ma anche in Gutenberg se si aprite un issue sono sicuro che qualcuno vi risponderà e perché appunto è un progetto comunitario non è solo di automatic Gutenberg e di tutti è open source e bisogna validarlo lo so che su alcune cose c'è ancora da migliorare ne siamo consapevoli però deve essere un effort di tutta la community quello che non solo di automatic non solo di piccoli sviluppatori deve essere un effort comunitario quindi davvero per qualunque issue che avete aprite un'ultima domanda no ok sì sì sì scusa su l'ultima ciao la mia più che una domanda sia una provocazione diciamo queste funzionalità con del put site editing c'è diciamo descritto oggi alcuni page builder blasonati le fanno da anni e lo stesso Gutenberg diciamo come progetto iniziale diciamo esiste da vari atti anni però molti sviluppatori come soluzione lo code no code continua a preferire dei page builder adesso diciamo mi convinci che il prodotto sia matura per fare questo sasto diciamo da un page builder di terze parti ad un soluzione nativa come appunto a Gutenberg è il momento giusto diciamo mi convinci di questo ok ci prova di piccola verità non ho mai utilizzato un page builder al di fuori di Gutenberg ho letto review diciamo video visto benchmark ma ho letto comunque di molte volte che vorre si veniva rilasciato una versione si rompeva tutto il sito perché page builder diciamo non era non supportava uno filter uno action di wordpress oppure le performance come ti ha fatto vedere wordpress è un tema blocchi cioè le performance sono assurde accento su tutto il test light house e ti dirò la verità dipende alla sua attuale dipende cioè quello che ti posso dire che di provarlo se tu hai qualche idea su cui migliorarlo hai qualche case valido portalo su su github aiutaci a rendere appunto a rendere Gutenberg il progetto site del site editing migliore grazie anche tui feedback come ci ha detto di essere un effort di tutta la community non di essere soltanto un effort di automatico perché credo che soprattutto adesso che stanno scendendo un sacco di no code tool è giusto che anche wordpress abbiamo un tool no code o penso soprattutto opensource il discorso di che guttenberg sia che guttenberg diciamo sia un po lento nei sviluppi credo che sia normale perché essendo progetto opensource ci sono tante migliaia di conversazioni non so che tu sei uno sviluppatore ma se c'ha una code review in un team molto piccolo richiede molto tempo immaginiamo in un progetto gigantesco come gigantesco come guttenberg quindi ti posso ti consiglio di provarlo e di non lo so le prime versioni guttenberg sono state un po della versione wordpress 5.0 a questa cattiva nomea ma è cambiata tantissimo e per questo anche stiamo migliorando la developer experience perché vogliamo che i sviluppatori si focalizzano soltanto su clare blocco non configurare un tool di configurazione sono sviluppatore ma non amo configurare nulla mi piace solo scrivere codice per raggiungere l'obiettivo quindi io vi do guttenberg come un framework per esempio come detto prima adesso ti sei voi ti posso far vedere qualche demo dopo ma un concetto come literazione non penso che gli altri page builder hanno un concetto come literazione dal punto di vista parlo di sviluppo cioè di tu lo per sviluppare e poi per sviluppare non credo che si stanno un concetto di questo tipo e noi ci stiamo lavorando quindi diciamo io penso che è il futuro di wordpress e quindi provalo e poi ai miei contatti vuoi mandarmi le mail e mi farai sapere ok grazie ancora