Lo sapevate che per far comunicare una base dati e una applicazione, a meno di piccoli e veloci database integrabili sqlite, è necessario interfacciarsi ad un sistema API per lo scambio di dati e per eseguire operazioni remote?

Ebbene si, sistemi come Facebook, Instagram, Youtube,AirBnB per sfruttare al massimo i vostri browser web utilizzano framework Javascript per creare componenti di interfaccia (frontend), mentre richiedono il contenuto di questi ultimi tramite REST API (backend). Questo permette di rispettare un buonissimo standard sul riutilizzo del codice, a cui noi programmatori ed ingegneri senior teniamo molto, il pattern DRY. Oltre a questo standard, la separazione tra logica di business dell’applicazione e interfaccia visuale permette il costante aggiornamento dell’interfaccia senza doverne cambiare la logica: un pulsante che calcola la somma di 2+3 potrà essere stilizzato infinite volte, senza cambiare il fatto che il risultato rimanga 5.

Come funziona una chiamata REST

Quando digitate un indirizzo web nel vostro browser e premete il pulsante di invio, partirà una richiesta GET al server del sito che state richiedendo. Il server, dopo aver costruito la pagina tramite le logiche di business e le linee guida programmate restituirà codice HTML. Questo è il funzionamento base per mostrare il contenuto di una pagina web.

Approfondendo però i vari metodi disponibili del protocollo HTTP, è possibile notare la disponibilità di altri metodi quando si richiede qualcosa ad un server, informazioni che vengono passate tramite header. Nella lista qui sotto uno specchietto dei metodi disponibili più comuni:

• GET
• POST
• HEAD
• PUT
• DELETE
• PATCH
• TRACE
• OPTIONS
• CONNECT

Una chiamata REST sfrutta lo stesso protocollo HTTP per eseguire operazioni su un server remoto, anche distante rispetto a dove risiede il vostro sito/server. La differenza non sta nel come i sistemi parlano in questo caso, ma nella dialettica che usano per richiedere informazioni e rispondere con informazioni. Esistono alcuni standard rispettati internazionalmente per descrivere queste richieste e risposte, sono standard pensati dagli utilizzatori e dai programmatori, ed open source.

Nel caso di esempio di un link per operare su un utente con id 13 (e, si, questo link potrebbe già essere valido per una chiamata REST):

http://www.test.com/user/13/

preparando un ambiente server per rispondere ai diversi metodi HTTP di GET,POST,DELETE,PATCH potrò tramite questo stesso capire:

• In che contesto sto operando (sto modificando un utente)
• Che azione sto compiendo (chiamando con metodo GET, richiedo solo informazioni, chiamando con metodo POST creo un utente con id 13, chiamando con metodo DELETE elimino l’utente con id 13, chiamando con metodo PATCH modifico l’utente con id 13)

Perchè scegliere React per il frontend

React è una libreria Javascript, scritta da Facebook dopo aver capito quanto importante sia condividere parti di codice scritto su architetture e device differenti (perchè pagare dipendenti in più quando puoi pagar gli stessi dipendenti ma pubblicare, o meglio transcompilare lo stesso codice, su tutti i device?).

Infatti, tramite un piccolo “ponte” chiamato React Native, è possibile programmare 1 sola volta codice in Javascript che poi verrà automaticamente esportato per dispositivi mobile.

Questa liberia è stata scritta e pensata a componenti e ad albero, concetto differente dal concorrente AngularJS, che si mostra in forma più monolitica.
Lo stesso Facebook ha dichiarato di aver utilizzato più di 15.000 componenti per costruire la sua interfaccia di frontend e poterli riutilizzare su più piattaforme.

Ogni componente ha uno stato, che nel variare tramite azioni compiute riaggiorna l’interna interfaccia o parte di essa. Il tutto senza fatica, solamente capendone i concetti.

La nostra scelta per le applicazioni: API Platform

Se non ci fosse uno standard per sviluppare univocamente per tutte le piattaforme, dovreste moltiplicare il vostro budget di progetto almeno di 3 volte: il web si codifica con codice HTML e CSS, le applicazioni Android vengono sviluppate in codice Java, quelle per iOS in Objective C. Sono 3 linguaggi di programmazione diversi, e sfido chiunque a saperli tutti e 3 alla perferzione.

Dopo diversi mesi di ricerche e troppo tempo speso a migliorare vecchie tecnologie, qui in WebSolution abbiamo deciso di recepire le nuove richieste di progettazione e sviluppo con un nuovo spirito, più fresco, giovane, pieno di standard dei giorni d’oggi.

Stiamo parlando di API Platform, piattaforma PHP per lo sviluppo e la gestione delle REST API di progetto. Questa piattaforma altro non è che un insieme di strumenti sviluppati dalle più importanti compagnie open source, stesse sviluppatrici di uno dei framework PHP più utilizzati e meglio documentati del settore, Symfony.

Le caratteristiche di API Platform

Le ragioni principali del perchè questo set di strumenti può essere d’aiuto al lancio e alla gestione di progetti più complessi sono:

• Utilizzo di Swagger e OpenAPI, quindi interoperabilità tra linguaggi di codice differenti con uno standard riconosciuto (consultate la vostra libreria consumer swagger/openapi per capire che ne esistono per tutti i linguaggi esistenti)
• API auto-generate per il vostro Model con l’utilizzo del pattern MVC (tramite PHP-Doc per descrivere i valori degli attributi)
• Modello gestito da Doctrine (ORM), quindi il codice per le operazioni basiche CRUD viene generato automaticamente
• Codice autogenerato per consumatori frontend (di operazioni CRUD), in linguaggio React/VueJS/React Native. In un secondo momento potrete usare la stessa piattaforma per crearvi app mobile native tramite, vi creerà lei alcuni pezzi di codice
• Una interfaccia di amministrazione per gestire le API e la loro creazione
• (Se codificate con standard PHPDoc) un modo automatico per tenere sempre documentate le API;
• Una piattaforma ben documentata, quindi è possibile modificare a più mani lo stesso progetto negli anni
• Una piattaforma che rispetta le specifiche php-fig (standard programmazione php internazionale)
• Un parco di Bundles Symfony e librerie integrabili in progetto utilizzando composer e Symfony Recipes;
• Solo la business logic delle API da gestire, quindi ORE E ORE DI TEMPO SALVATE (e, chiaramente, soldi)

Gutenberg, come già spiegato qui, fornisce ampia modalità per creare le proprie collezioni di blocchi di contenuti, sia statici che dinamici. Non è comunque da tutti saper scrivere correttamente codice Javascript con standard ES6 e codice PHP.

D’altra parte, ciò che aiutava l’utente finale a compilare dinamicamente una pagina senza necessariamente conoscere alcun linguaggio di programmazione e che abbiamo integrato in tutti i progetti che richiedevano maggiore attenzione per complessita logica è ACF, aka Advanced Custom Fields. Più precisamente, abbiamo optato per la versione Pro che offre migliorie su funzionalità degli elementi di backend, come la capacità di creare dei veri e propri gruppi ripetibili di dati inseribili.

Fino ad ora, ACF Pro ci ha dato possibilità di creare temi ad-hoc, studiati appositamente per facilitare l’utente utilizzatore dei nostri applicativi a inserire dati senza alcuna perdita di tempo.
Veniva quindi creato per ogni template o parziale di template un gruppo di campi specifico per descrivere ciò che il frontend poi avrebbe dovuto mostrare. Inoltre, venivano create pagine opzioni per gli elementi comuni del tema, quali header e footer, pagine di archivio del blog e dei custom post types.
ACF costruisce da solo elementi per la compilazione backend, chiamati meta boxes, e si occupa di andare a salvare metadati nella tabella postmeta e renderli disponibili in secondo momento in frontend.

I meta box (r)esistono ancora?

Per ora, i meta box per i campi custom di ACF verranno mantenuti in backend, subito sotto l’editor Gutenberg.

Non sembra però essere idea ottimale quella di continuare a comporre contenuti tramite la compilazione di meta box. Se ci riflettete bene, andrebbe esattamente contro gli standard di libertà introdotti con lo stesso Gutenberg! Un contenuto qui dovrebbe essere formato DA SOLI blocchi, non da un misto tra blocchi e pezzi di parziale intestati o accodati al contenuto principale. Lasciamo in parte i casi particolari per un momento.

Elliot Condon e le scelte commerciali intelligenti: ACF e blocchi dinamici

Tra Advanced Custom Fields e la migliore versione PRO, esistono più di un milione di installazioni su siti in tutto il mondo. Per non deludere tutta questa tribù di users, il team di sviluppo di ACF, capitanato da Elliot Condon, continuerà a seguire l’implementazione a meta box di campi custom, ma ha ben pensato di stare al passo con i tempi pensando ad una nuova modalità per registrare e costruire blocchi fruibili in Gutenberg, formati dagli stessi campi che una volta potevano essere mostrati solo nei riquadri paralleli al contenuto principale.

Da poco tempo a questa parte quindi è stato rilasciato un aggiornamento molto importante in ACF che integra ACF Blocks e permette di:

• bypassare completamente la registrazione tramite Javascript di un nuovo blocco, evitandoci di imparare decine di linguaggi e concentrandoci sui veri problemi sistemici da risolvere
• registrare un blocco tramite un helper PHP creato ad hoc (che funge da “ponte” e crea in automatico per noi tutta la parte Javascript che permette a Gutenberg di digerire meglio il nuovo blocco)
• popolare di campi custom il blocco visualizzato in backend
• passare ad un livello migliore di modularità del frontend

Un esempio concreto di tutto ciò è un pezzo di codice integrabile nel file functions.php del tema e che vi riporto qui sotto. Questo va a registrare un nuovo blocco ACF che prenderà il nome di “Testimonal” e definisce come il frontend dovrà interpretare codice e dati e trasformare tutto in HTML.

<?php 

// Registra un nuovo blocco ACF testimonial
if( function_exists('acf_register_block') ) {
	
	$result = acf_register_block(array(
		'name'				=> 'testimonial',
		'title'				=> __('Testimonial'),
		'description'		=> __('Blocco custom testimonial.'),
		'render_callback'	=> 'visualizza_testimonial'
		//'category'		=> '',
		//'icon'			=> '',
		//'keywords'		=> array(),
	));
}

// Funzione callback per visualizzare il blocco come html
function visualizza_testimonial() {
	
	// vars
	$testimonial = get_field('testimonial');
	$author = get_field('author');
	$avatar = get_field('avatar');
	
	?>
	<blockquote class="testimonial">
	    <p><?php echo $testimonial; ?></p>
	    <cite>
	    	<img src="<?php echo $avatar['url']; ?>" alt="<?php echo $avatar['alt']; ?>" />
	    	<span><?php echo $author; ?></span>
	    </cite>
	</blockquote>
	<?php
}

Dopo aver registrato il blocco, possiamo definirne i campi custom, specificando come regola di visualizzazione che i campi dovranno essere presenti all’interno del campo Testimonial.

Ora sarà possibile editare il blocco in Gutenberg e vederne la preview in backend.

Un nuovo livello di modularità

Le novità introdotte con il nuovo editor permetteranno una modularità superiore in qualità e quantità rispetto a ciò disponibile fin ora. Sarà ora possibile sviluppare (con lo stesso concetto di Facebook’s React) componenti con una vita propria, riutilizzabili in molteplici progetti.

Mio consiglio: armatevi di pazienza, capite quali componenti secondo voi potranno essere replicati in contesti diversi, createvi una libreria di blocchi da installare in ogni vostro progetto, vedrete che alla fine dell’anno quando conterete le statistiche delle ore di lavoro impiegate a costruire frontend mi ringrazierete.

Abbiamo già visto in questo articolo cos’è stato introdotto con l’ultima versione di WordPress. Gutenberg è stato concepito per facilitare la vita alle nuove generazioni di Copywriters che stanno crescendo. Ma… come la mettiamo con i siti già fatti, con compositori visuali installati?

Genericamente, un visual composer salva per ogni modifica fatta ad un post una serie di metadati nella relativa tabella postmeta di WordPress, poi un parser si occuperà di ricostruire il contenuto di pagina con gli stessi metadati.
Con l’entrata in gioco di un editor a blocchi come Gutenberg, non è strano riflettere su quale sarà la vera fine di questi compositori, anche se sembra che ogni compagnia di sviluppo si stia adattando all’evoluzione del nostro CMS preferito.

Elementor e WordPress 5

Dopo ardua scelta, e dopo aver eseguito reverse engineering di 4 page builders e controllato la qualità del codice con cui sono stati scritti, in Websolution abbiamo deciso di accontentare anche i clienti con budget più limitato, utilizzando Elementor Pro per aiutarci a risparmiare tempo e fatica ed arrivare più velocemente al risultato.

Elementor Pro è già stato descritto in centinaia di blog, mi limiterò
quindi a descrivere ciò che riguarda la sua integrazione in WP5.

Cosa cambia?

A questa domanda, risponderò schiettamente: assolutamente nulla, in negativo. Gutenberg, essendo creato per essere retrocompatibile, non nega l’utilizzo di Elementor, plugin che non fa altro che “prendere il controllo” del contenuto di un post e lasciar possibilità di creare pagine tramite interfaccia visuale interattiva e di facile navigabilità.

Quindi, per passare da un’interfaccia di inserimento ad un’altra, è disponibile un apposito semplice tasto di editing.

Template di Elementor come blocchi di Gutenberg

Altra cosa davvero positiva è l’ingresso in gioco di un piccolo plugin, sviluppato sempre da PojoMe, che permette di inserire template sviluppati in Elementor direttamente come blocchi in Gutenberg. 

Potete trovare maggiori informazioni sul plugin direttamente in plugin repository di WordPress: https://wordpress.org/plugins/block-builder/

E’ finalmente arrivata quella parte dell’anno che ogni sviluppatore ama ed odia, dato che il rilascio di una nuova major release porta novità nel fronte dello sviluppo e dell’organizzazione applicativa (e quindi… felicità!), ma comporta ulteriore studio del sistema in questione, e sicuramente saprete che con le chiusure aziendali natalizie viene difficile pensare di potersi permettere un reale approfondimento del tema.
Con questo piccolo contributo alla causa, cercheremo di smarcare con semplicità le novità che vengono offerte da WordPress 5, più in particolare dal nuovo editor Gutenberg che va a sostituire il vecchio editor WYSIWYG.

Benvenuto Gutenberg

Dicevamo… Gutenberg è il nuovo editor che è già integrato in tutte le nuove versioni di WordPress, successive alla versione 5.0.0.
Dopo aver rilasciato da un paio d’anni un plugin dal nome analogo, per permettersi di testare un’idea e tutte le funzionalità ad essa legate, il plugin è stato integrato in core di WordPress. Ma… come funziona in parole spicce?

Benvenuti blocchi

E’ molto probabile che con l’avvento dei compositori visuali, gli stessi sviluppatori in Automattic abbiano sentito il bisogno di esporre alla comunità un metodo di inserimento dei contenuti che fosse più facile, divertente, snello che il solito e vecchio editor.

Ogni pezzo di contenuto ora può essere visto come un semplice blocchetto che fa esattamente una cosa specifica. Esistono blocchi per inserire un nuovo titolo, un nuovo paragrafo, una nuova immagine o galleria, una nuova lista, un nuovo video embedded (non li citerò tutti, sarebbero troppi). Persino uno spazio vuoto di altezza 30px è diventato un blocco, addio caro css, addio padding!

Ora, sarà molto più semplice per l’utilizzatore finale capire come inserire un titolo, un elenco, senza mandar fuori di testa noi poveri sviluppatori, che ci dovremo occupare solo ed esclusivamente (finalmente) di stilizzare qualcosa di già generato dal sistema. Quindi, addio classi css, addio bug frontend, addio clienti che ti chiamano per sistemare un colore. Ora è già tutto pronto all’uso. Ora un documento non sarà più semplice html, sarà astratto ad un livello superiore e strutturato.

TL;DR: Blocchi come Custom Post Types, commenti HTML come descrittori di blocco

Se non siete nel settore dello sviluppo, ma siete semplici persone curiose del mondo WordPress, potrete saltare questa sezione.

Come funziona tecnicamente questa cosa dei blocchi?
Un blocco è registrato a sistema come una nuova entità, come lo sono un Custom Post Type e una Taxonomy. La differenza in registrazione tra un blocco e un CPT/Taxonomy è che i nuovi blocchi interagiscono con il backend tramite javascript, che ne può dinamicizzare il contenuto al volo. E’ necessario quindi operare in entrambi i linguaggi PHP e Javascript (le guide ufficiali parlano di standard Javascript ES6, armatevi quindi di pazienza e, nel caso vi servissero informazioni su come registrare nuovi blocchi, date un’occhiata al tutorial ufficiale reperibile qui).
Quando un utente inserisce un nuovo blocco in interfaccia backend, il motore javascript di Gutenberg crea un nuovo elemento JSON che viene concatenato all’albero di elementi della pagina in costruzione, che descrive esattamente il medesimo blocco. Ne descrive quindi il contenuto e la formattazione.

[
    {
        type: "core/cover-image",
        attributes: {
            url: "my-hero.jpg",
            align: "full",
            hasParallax: false,
            hasBackgroundDim: true
        },
        children: ["Gutenberg posts aren't HTML"]
    },
    {
        type: "core/paragraph",
        children: ["Lately I've been hearing plen…"]
    }
];

Al salvataggio della pagina, il sistema salva in database, al posto del vecchio e puro HTML in colonna post_content, un insieme di blocchi rappresentati ognuno da un commento html. In base alla tipologia del blocco (se popolato staticamente o dinamicamente), viene appeso un array serializzato contenente le descrizioni del blocco in questione. Questa sotto è la risultante contenutistica della pagina che state leggendo.

Naturalmente, in frontend i commenti sarebbero inutilizzabili, come per l’array descrittivo serializzato… il browser interpreta solo HTML. Esiste quindi un parser che intepreta ogni commento HTML e converte i dati esistenti nell’array di configurazione del blocco in dati che abbiano un senso valido alla visualizzazione in frontend dello stesso.