Wordpress Headless e Jamstack

Quando si parla dell’approccio jamstack unito al conosciuto e flessibile wordpress, bisogna fare un po’ di precisazioni e distinguo, specie se jamstack è qualcosa di cui si è sentito parlare in maniera non troppo approfondita, infatti le due cose possono generare un po’ di confusione

Wordpress in due parole

Wordpress è un cms molto amato e conosciuto, che grazie alla facilità della scrittura del codice in frontend, e alla solidità del pannello di amministrazione, è stato spesso un’ottima scelta per molti privati ed aziende per creare i siti dagli scopi più disparati, dal semplice sito di “rappresentanza” fino a sistemi più complessi come gli e-commerce, dove la stabilità e la velocità sono tutto.

Proprio sulla velocità, wordpress che gira su linguaggio di programmazione PHP ha qualche problemino nativo, dovuto anche all'approccio di gestione del database. Non sarà una notizia sconvolgente per gli addetti ai lavori, sapere che a parità di funzionalità, un sito fatto su codice proprietario e uno fatto basandosi su wordpress, avranno database dalle dimensioni notevolmente differenti.

Quando facciamo una richiesta dal nostro browser a un sito wordpress standard, la nostra richiesta viene presa in carico dal server, che smista le varie parti della nostra richiesta alle varie componenti che lavorano in orchestrazione, e quindi parte una elaborazione della stessa dal PHP, che la elabora e restituisce una risposta. 

Passi fondamentali per velocizzare negli anni questi passaggi, sono stati la compressione dei dati e il meccanismo della cache.

Cos’ è la cache di Wordpress

Senza specificare troppo, esistono ovviamente tantissimi meccanismi di cache che possono agire sul nostro sito, un elenco non esaustivo comprende:

• Cache su web server nginx 
• Cache di cloudflare o similari
• Cache dei file statici prodotti dall’elaborazione del PHP e salvati in una cartella del disco fisso del server
• Cache delle chiamate al database

Operativamente parlando, su wordpress complessi, nei tempi passati, talvolta tra plugin della cache, cache fatta sulle query del database, cache statica e cache cloudflare o similari, non era chiarissimo di quale cache si dovesse forzare la pulizia, per vedere immediatamente il fix di un bug di un sito .

Tutti questi tipi di cache hanno sempre avuto il pregio di intervenire un po’ come fa un cappotto termico su una casa già costruita, e cioè apporta dei miglioramenti con una struttura solida e coerente che avvolge la casa, e non snatura la struttura di base del wordpress / casa.

Questo è particolarmente chiaro e visibile nella cache dei file statici. Il PHP alla fine elabora una risposta da servire che sarà in html. La maggior parte del codice html che uscirà da questa elaborazione sarà sempre uguale, quindi non ha senso far fare al PHP l’elaborazione della richiesta tutta da capo per tutte le volte che viene richiesta. Si salva la prima elaborazione e si serve quella per un certo periodo di tempo.

Questo non cambia nulla nel frontend del sito, e se si vuole stravolgere graficamente una pagina del sito, e questo è permesso da come è stato fatto il sito, si fanno le modifiche volute, si cancella la cache, e quindi si mantiene la libertà assoluta di farlo.

Sembra bellissimo vero? Lo è, ma solo in parte. Quando un sito ha molte richieste concorrenti, questo tipo di meccanismo non basta più, e il server va comunque in stress, perché tutte le parti di cui è composta l’infrastruttura del sito sono comunque attive e pesano, meno magari, ma pesano. 

Cosa è veramente imbattibile di Wordpress?

Parlando molto onestamente, l’aspetto veramente imbattibile di un wordpress è la sua parte di amministrazione ben congegnata e universalmente conosciuta; è facile che gli addetti ai lavori o i semplici amatori ci abbiano messo mano almeno una volta nella vita. 

La scelta dei temi e dei plugin è certo una grande risorsa, ma facendo una analisi rischio beneficio, non sono qualcosa a cui non poter rinunciare, specialmente i temi. La riprova ciò è che qualsiasi professionista, quando deve fare un sito in wordpress, usa solitamente una di queste strade:

1. Rielabora un tema semplice già fatto, che funziona in partenza e magari crea un template personalizzato child dello stesso
2. Crea un template da zero
3. Usa in maniera massiccia un visual composer

Jamstack in due parole

L’approccio Jamstack è pensato per oltrepassare un approccio LAMP classico, o comunque un approccio in cui l’area di amministrazione del sito (o backend) e l’area del sito visibile all’utente finale (o frontend) sono identiche a livello di architettura sottostante.

In parole povere, usando l’approccio Jamstack, la parte di amministrazione del sito a cui si accede, ad esempio, per inserire un articolo, è strutturalmente completamente diversa da quella su cui atterra il visitatore del sito per leggere tale articolo. 

In questo modo wordpress diventa un CMS HEADLESS e cioè è usato solo dalla parte amministrativa e contiene solo la parte che permette, per esempio, di scrivere o modificare articoli. 

Il template grafico del sito, in questa maniera, diventa completamente alieno dal Wordpress, non è quindi scritto in PHP. La parte visiva del sito (composto nei suoi file html) viene completamente elaborata e messa a parte, e la richiesta dell’utente non viene elaborata in nessuna maniera dal PHP (per ottenere il frontend del sito) e non vengono fatte richieste al database.

Solo e soltanto html e javascript. Quando si necessita di avere elaborazioni particolari dipendenti da scelte variabili dell’utente, vengono fatte richieste a un sistema di API, che interrogato rende una risposta che viene rielaborata e quindi restituita.

Cosa potentissima di tutto il discorso, è che a livello sistemistico il sito in frontend può tranquillamente stare su una CDN, aggiungendo il vantaggio di essere semplice html ( elaborato tra l’altro senza nessun vincolo imposto da infrastruttura del wordpress)

Riportando le parole di cloudflare, che di cdn se ne intendono 

"Un cdn è Una Content Delivery Network (CDN) fa riferimento a un gruppo di server distribuiti geograficamente che collaborano per fornire la trasmissione rapida di contenuti Internet.

Una CDN consente di trasferire velocemente le risorse necessarie per caricare i contenuti Internet, incluse pagine HTML, file javascript, fogli di stile, immagini e video. La popolarità dei servizi CDN continua ad aumentare e, ad oggi, la maggior parte del traffico Web viene servito attraverso CDN, compreso il traffico da siti importanti come Facebook, Netflix e Amazon."

Vantaggi e svantaggi di un Wordpress Jamstack

I vantaggi sono quindi molteplici:

• Velocità
• Razionalizzazione della struttura, 
• Resilienza ( richieste multiple e concorrenti pesano notevolmente meno sul server) 
• Migliore scrittura del codice html e resa dello stesso 

Esiste un solo “svantaggio” per chi conosce Wordpress ed è affezionato alla sua estrema malleabilità, che può essere capito come logica conseguenza, ma è bene ribadirlo: 

L'elaborazione del frontend e del backend diventano due entità a sé e, in questo modo, cambiare un template sul backend di Wordpress o installare un plugin non avrà effetto immediato sul frontend.

Primi passi per rendere Wordpress headless

A questo punto, partendo dal fatto di avere la propria area amministrativa separata dal proprio frontend, il primo passo è rendere wordpress solo e soltanto l'area amministrativa da interrogare per recuperare i dati da "convertire" nel frontend.

Come riportato da jamstack.org “L'API REST di WordPress è una funzionalità stabile della piattaforma da diversi anni” e quindi il primo passo è iniziare a sfruttare le api di Wordpress.

Per farlo, un modo molto semplice è quello di installare WPGraphQL. 

Consiglio di prenderlo direttamente da github, basterà scaricare la cartella e copiarla nella cartella /wp-content/plugins.

Effettuando questa operazione su un pannello plesk pulito, ho ricevuto questo avviso una volta attivato il plugin 

Sul mio server di plesk di prova, sono quindi entrato in ssh e ho lanciato questi comandi

curl -sS https://getcomposer.org/installer | php -d detect_unicode=Off

alias php=/opt/plesk/php/7.4/bin/php

php composer.phar install

php composer.phar update

In questa maniera ho installato il composer, scelto la versione di PHP che dovesse essere usata dal composer, e quindi fatto un install e update del tutto.

Questa situazione prevede quindi o che abbiate gli accessi in ssh del vostro server, o che il gestore del server debba procedere all’installazione dello stesso.

Una volta installato WPGraphQL, potremo usare anche un idle per facilitare l’uso dello stesso. 

Qui la documentazione necessaria

Ecco che abbiamo uno strumento che ci permetterà di creare api, a cui potremo successivamente collegarci per riprendere i dati da Wordpress e quindi rielaborarli.