Le criticità di WordPress: La prospettiva di uno sviluppatore

Le criticità di WordPress: La prospettiva di uno sviluppatore

Sempre più spesso gli sviluppatori finiscono per utilizzare un CMS come WordPress, pur non amando la piattaforma.

Gli sviluppatori capaci spesso preferiscono utilizzare soluzioni personalizzate, specialmente quando sei uno sviluppatore che è davvero bravo a programmare. Con una soluzione personalizzata è possibile creare applicazioni molto eleganti che funzionano molto bene. Tuttavia, gli sviluppatori finiscono per utilizzare un CMS come WordPress anche se non amano fortemente la piattaforma.

Questo articolo è rivolto a questi sviluppatori e affronta molte delle difficoltà incontrate quando si lavora con WordPress (WP). Vi illustreremo quali sono queste difficoltà e daremo anche un suggerimento: l’aiuto di Plesk, che fornisce un toolkit per WP che aiuta davvero a prendere in considerazione alcune delle maggiori ciriticità del più amato CMS del mondo: WordPress.

Perché gli sviluppatori utilizzano WordPress

Non illudetevi, WordPress è il CMS più popolare sul mercato per ottime ragioni. In questa sezione descriviamo perché il CMS è così popolare anche tra gli sviluppatori esperti che possono davvero scrivere il proprio codice.

In primo luogo, WordPress è super facile da installare. Tutto ciò di cui avete bisogno è l’ambiente standard LAMP/LEMP – Linux, Apache/Nginx, PHP e MySQL/MariaDB come DBMS. Se ce l’hai, puoi iniziare ad installare WordPress.

La personalizzazione è altrettanto facile perché il WP CMS è dotato di una vasta gamma di componenti aggiuntivi, compresi i temi per personalizzare il look&feel del front-end e i plugin che aggiungono funzionalità. È anche possibile costruire il proprio tema e gli sviluppatori esperti possono anche fare i propri plugin, ma questo processo è più complesso.

Forse la ragione principale della popolarità di WordPress è, naturalmente, il fatto che è accessibile a utenti non tecnici. Una volta installato WP non richiede alcuna esperienza di codifica o di comprensione del software per funzionare bene, gli utenti inesperti possono pubblicare un sito web e configurare un’istanza di WordPress subito dopo il lavoro.

Qual è esattamente il problema con WordPress?

Beh, il CMS più popolare al mondo ha un sacco di problemi da considerare. Non intendiamo fare un polverone sui problemi di WordPress, ma quanto segue è una discussione franca e speriamo che il team di sviluppo dietro questo CMS incredibilmente popolare consideri i seguenti punti come una critica positiva. Ecco perché pensiamo che WordPress sia frustrante per gli sviluppatori:

Ampiamente capace, ma mai eccellente

L’inizio di WordPress è stato semplice. WP nasce per essere una piattaforma coloro che volevano scrivere e pubblicare un blog. Il CMS è completamente cambiato nel corso degli anni e ora non assomiglia più ai suoi umili inizi. Alcune persone lo usano come sistema di base per gestire un intero sito, come una piattaforma per i negozi online e anche come un modo per generare siti statici (assurdo, ma abbiamo visto anche questo nel corso degli anni)

In un certo senso si evidenzia il fatto di quanto sia adattabile il CMS e noi concordiamo con questa affermazione, ma il problema di essere così flessibili è che diventa difficile eccellere in ogni singolo ruolo. Un modo per rendersi conto di questo è quello di scrutare attraverso la lente dei plugin: le migliaia di plugin WordPress disponibili mostrano come le persone stanno cercando di costringere WordPress ad essere qualcosa che semplicemente non è o peggio, a fargli fare qualcosa che non è capace di fare o se lo fa, lo fa male. Per questo noi, quando usiamo WordPress e lo usiamo spesso e volentieri, non lo carichiamo mai di plugin che non siano strettamente necessari. A quel punto, preferiamo farli noi.

Chiaramente, WordPress è fatto per questo approccio “self-made” e ovviamente la flessibilità ha molti vantaggi, non c’è dubbio. Ma senza una forte concentrazione su un particolare compito, il CMS fatica moltissimo ad offrire una soluzione chiara. Questa focalizzazione sul cercare di essere tutto per tutti sta è la causa di problemi enormi. Tuttavia, dobbiamo sottolinearlo: WordPress funziona ancora bene come piattaforma per la creazione di blog e di siti web e siti di e-commerce non complessi.

Hack e crepe: WordPress può essere una porta aperta

In breve, WordPress viene hackerato 24 ore su 24 ed è la più grande lamentela di cui abbiamo sentito parlare nel mondo degli sviluppatori. Non si può negarlo, il CMS è pieno di buchi di sicurezza, non finisce mai. E’ come una coperta corta: lo aggiusti da una parte e si scopre dall’altra. In parte il numero di hack è dovuto alla popolarità di WordPress, ma anche al modo in cui WordPress è open-source.

Poiché tutti possono visualizzare il codice open-source del CMS, ciò consente agli hacker di trovare i punti deboli nel codice. Non intendiamo dire che il codice open-source è un approccio scorretto, ma pensiamo che la natura open-source del CMS WordPress stia contribuendo ai suoi infiniti problemi di sicurezza.

L’analisi mostra che i siti WordPress rappresentano più di un quarto di internet. Il team di WordPress lo sa e cerca di fare tutto il possibile per assicurarsi che il CMS sia sicuro, ma poiché i cicli di sviluppo sono così veloci oggi può essere difficile proteggere completamente un’applicazione complessa. E quando gli sforzi per la sicurezza falliscono, milioni di siti web possono essere in pericolo.

Non abbiamo una soluzione ovvia alle sfide di sicurezza di WordPress a parte, naturalmente, dall’ovvio “aggiorna la tua istanza di WordPress”. Anche allora il ciclo di rilascio di WordPress porta con sé problemi unici e a non finire.

Un sacco di persone dicono che prendersi cura della sicurezza di WordPress è semplice, ed è vero in larga misura, ma la domanda è: perché i proprietari dei siti dovrebbero essere tenuti a eseguire una lista di attività per assicurarsi che WordPress sia sicuro? Perché questa sicurezza non fa parte di WordPress “out of the box” ?

  • È facile per qualcuno caricare un file eseguibile su WordPress, e questa opzione dovrebbe essere limitata per impostazione predefinita. Richiede solo una persona leggermente in gamba per caricare un file con codice dannoso in uno script PHP e il tuo sito è compromesso.
  • Attualmente, le opzioni possono essere configurate nel file system. Invece, WordPress dovrebbe eliminare questo e fare l’ipotesi che il file system sia “di sola lettura”. Anche se il nucleo di WordPress fa questo, i plugin non seguono questo modello di comportamento. Se si incontra un plugin che cambia il file di configurazione mentre è attivamente in produzione, smettere di usarlo. In questo modo indica un file system che può essere scritto e, di conseguenza, un modo semplice per apportare modifiche dannose. Una soluzione è quella di togliere il file wp-config.php dalla root del sistema (WordPress funziona ugualmente) ma non è una garanzia totale di sicurezza e comunque impedisce poi il corretto funzionamento di molti plugin scritti a mani basse da sviluppatori incoscienti.
  • Per impostazione predefinita, WordPress consente agli utenti di effettuare tutti i tentativi di accesso che desiderano. Questo apre la porta a un attacco brute-force dove gli hacker continuano a provare password casuali fino a quando il login ha successo. Il CMS WordPress dovrebbe disabilitare i tentativi di accesso illimitati al momento dell’installazione.

Questo non è un elenco esaustivo, sono solamente un paio di punti. Ovviamente, una soluzione software di grandi dimensioni, specialmente una soluzione open-source, non può essere completamente invulnerabile all’attacco. Ma il nostro punto è che gli sviluppatori seri sono riluttanti ad usare WordPress proprio perché è così vulnerabile. Gli sviluppatori qualificati preferirebbero costruire un’applicazione nuova di zecca, in grado di soddisfare elegantemente le loro esigenze e che può essere rigorosamente protetta – senza preoccuparsi di future vulnerabilità sconosciute.

Oppure, utilizzando al meglio le impostazioni di PLESK e non caricando WordPress di plugin “non consigliati” o peggio “free” o peggio ancora scritti male (ci vuole esperienza sul campo per poter dare giudizi in merito) si può rendere WordPress ancora una piattaforma eccellente anche in termini di sicurezza. Ma non è più una gestione “fai da te”, occorre una mano esperta.

I plugin come fonte di problemi

Un buon sviluppatore non ricorre a un plugin alla prima difficoltà. Invece, i buoni sviluppatori cercano di costruire una soluzione semplice ed elegante. Al contrario, affidarsi sempre ai plugin cercandoli su internet o affidandosi a quelli suggeriti dalla Community è un modo di pensare molto sbagliato.

Alla fine un plug-in rende facile aggiungere funzioni specifiche a WordPress, il che rende l’ampia gamma di plugin disponibili per WP un punto di forza del CMS – ma è anche un rischio. Per quanto i plugin possono rendere le cose più facili e veloci, i plugin comportano anche molti rischi in termini di sicurezza e allo stesso tempo vi costringono a scegliere la versione di WP che potete usare e allo stesso tempo gonfiano la vostra istanza di WordPress oltre ogni misura sostenibile vanificando o mettendo in crisi anche la vostra presenza online, la velocità di apertura del sito e così la raggiungibilità e di conseguenza la corretta indicizzazione nei motori di ricerca.

Plugins e sicurezza

In primo luogo, guardiamo ai problemi di sicurezza che i plugin creano. Una relazione suggerisce che oltre la metà dei problemi di sicurezza noti di WordPress derivano dai plugin. Gli sviluppatori sono soggetti a qualsiasi buona pratica che un produttore di plugin segue – il che potrebbe non essere così buono. Pertanto, come sviluppatore devi verificare accuratamente un plugin prima di utilizzarlo. In una certa misura questo processo di controllo può rimuovere il tempo che si risparmia con i plugin, quindi a quel punto tanto vale considerare lo sviluppo da zero della funzione necessaria da aggiungere al sito.

Limiti alle versioni WP

Conosciuto come “vincolo di versione”, i plugin possono limitare quale versione del WP CMS è possibile eseguire. Ora, WordPress è molto aggressivo con il suo ciclo di rilascio, per questo rilascia regolarmente un nuovo aggiornamento e infatti spesso accade che la piattaforma rilasci diverse piccole versioni o patch in un dato mese. Questo è comprensibile in quanto il team di WP fissa costantemente i vettori di attacco. Eppure tutti questi aggiornamenti hanno un problema: un aggiornamento di un WP può rompere un plug-in, causando l’interruzione del funzionamento o il malfunzionamento del sito.

Naturalmente è necessario mantenere aggiornato il vostro CMS, ma i vincoli di versione imposti dai plugin possono rendere questo lavoro difficile. Alcuni sviluppatori di plugin stanno sempre testando e aggiornando i loro plugin, ma questo piccolo “mondo” di plugin premium non rappresenta la maggioranza. Al di fuori di questi plugin premium si corre il rischio reale che un aggiornamento della versione di WP possa letteralmente corrompere il sito.

Plugin bloat

Supponiamo che la maggior parte degli sviluppatori sappia che è importante costruire progetti snelli che non utilizzano codice in eccesso. Ora, alcuni plugin sono conformi a questo principio, ma molti plugin sono molto gonfi perché questi plugin cercano di risolvere ogni problema che un utente potrebbe avere. È comune per uno sviluppatore scoprire che un plugin risolve un problema e allo stesso tempo offre una soluzione ad altri cinquanta problemi non rilevanti per il suo sito. (Per non parlare poi dei temi e dei “builder”).

I plugin interrompono il flusso di lavoro di WordPress

Infine, un altro problema comune che molti plugin creano è il fatto che un plugin può ostacolare l’esperienza utente in WordPress, questo dipende ahimè dall’effetto plugin bloat di WordPress. Ad esempio, un plugin può cambiare completamente come un post viene creato e diffuso attraverso il sito.

Questo si traduce in un problema che gli sviluppatori di WP si trovano ad affrontare molto comunemente, sentono che hanno la sensazione di dover lavorare “intorno” a un plugin troppo, piuttosto che usare solo il plugin. Inevitabilmente gli sviluppatori si accollano questo processo di aggirare i plugin perché quel plugin magari sembra risolvere un problema di processo (che inevitabilmente non c’è).

L’architettura web si è evoluta

Abbiamo già detto che WordPress è in giro da un po’ di tempo. Quando è stato costruito, gli sviluppatori pensavano che un sito web avrebbe sempre utilizzato un unico server, accanto a un unico file system. Tuttavia, gli sviluppatori utilizzano sempre più spesso quella che viene chiamata architettura micro-server che fa uso di più nodi. Lo fanno perché questo modo di lavorare è più scalabile e flessibile. Ma l’utilizzo di WordPress su un’architettura complicata può creare problemi, ad esempio, il ricorso quasi esclusivo all’FTP per gli aggiornamenti del WP CMS.

Gli sviluppatori moderni penserebbero ovviamente che l’aggiornamento del codice via FTP è semplicemente arcaico. Gli sviluppatori di solito usano un flusso specifico di lavoro in modo che i potenziali problemi possano essere fermati prima che il codice diventi operativo. Questo significa che lo sviluppo è fatto localmente, il codice è controllato dalla versione e che il codice è anche testato automaticamente – il tutto attraverso un continuo processo di integrazione. Quindi, il semplice caricamento di nuovo codice in un ambiente che esegue dei brevi circuiti, il che significa che c’è un’alta probabilità che le cose possano andare male.

Più grande del problema delle patch è semplicemente il presupposto che stiamo lavorando con un singolo file system su un singolo nodo. Un cluster multi-nodo di server web migliora sia i guasti hardware che le prestazioni, ed è per questo che questo approccio è sempre più adottato. WP presenta un ostacolo, tuttavia, in quanto l’installazione di un aggiornamento del tema o del plugin via FTP significa che solo un file system può essere aggiornato in una sola volta. Quindi, con un cluster multi-nodo ci si trova di fronte all’esecuzione di questo aggiornamento per ogni nodo.

Gli sviluppatori possono aggirare il problema, ma rimane una difficoltà che non si risolve facilmente. Inoltre, il processo richiede che il file system sia scrivibile, il che a sua volta porta una grande preoccupazione per la sicurezza del Database che è il cuore pulsante di WordPress.

I dati orfani e la struttura dei dati in generale

All’inizio, la struttura dei dati WordPress è semplice. Tuttavia, ben presto emerge che nel database di WP ci sono tabelle ridondanti. Per esempio, perché i metadati devono essere separati in due tabelle: una chiamata “wp_posts” e una chiamata “wp_postmeta”? Non è meglio includere tutti i dati in una tabella? Lo stesso vale per la tabella dei commenti, che ha una seconda tabella associata per i suoi metadati.

Il risultato è che ci sono dati extra rimasti in tutto il database. Sì, WP include alcune funzionalità che aiutano a ridurre l’effetto dei dati orfani, ma le funzioni non funzionano quando è necessario manipolare un conteggio di righe di migliaia di righe. In pratica le funzioni di WordPress causano timeout del server e portano a problemi di memoria e semplicemente non sono efficaci.

Naturalmente è possibile scegliere di ridurre semplicemente i dati orfani scrivendo direttamente le query SQL in questo senso. Ma è necessario capire a fondo come sono collegate le tabelle in modo da poter scrivere le query SQL corrette. Il grado di separazione dei dati nel database di WordPress si rivela semplicemente superfluo.

Cosa fa il Toolkit di Plesk per WordPress per migliorare le cose

WordPress Toolkit di Plesk è un modo semplice per impostare e personalizzare un’istanza di WordPress, tutto da un unico pannello di controllo. Puoi usarlo finché è installato sul tuo sito web. Qui ci sono alcune aree in cui WordPress Toolkit aiuta a prendersi cura di WP:

Gestione della sicurezza

Con il toolkit è possibile chiudere automaticamente le falle di sicurezza più evidenti. Ad esempio, è possibile passare da XML a RPC ping back, assicurarsi che la cartella “wp-content” sia sicura e molto altro ancora. Il toolkit mostra lo stato di sicurezza del tuo sito e segnala i problemi con “pericolo” o “avviso” che è una raccomandazione per migliorare la sicurezza.

Aggiornamento dell’istanza del WP

Disponibile come funzione aggiuntiva in Toolkit 3.x e successivi, la funzione Smart Updates consente di mantenere in funzione un sito di produzione e di aggiornarlo contemporaneamente, senza il rischio di rompere il sito. Lo strumento controlla i problemi che potrebbero verificarsi a causa dell’aggiornamento e vi dirà se c’è un rischio di qualche tipo.

Clonazione

Ci sono un sacco di ragioni per cui si potrebbe desiderare di fare una copia del vostro sito WordPress. Ad esempio, si potrebbe avere un sito di staging in cui testare le modifiche prima di renderlo live. Una volta pronto, si vorrebbe copiare il contenuto del sito.

Oppure, si potrebbe avere un sito pubblico e si potrebbe desiderare di farne una copia di cui non si vuole che il pubblico abbia accesso. Un altro esempio sono gli sviluppatori professionisti che hanno una copia modello di un’installazione di WordPress e che vogliono semplicemente clonarla, inclusi temi e plugin, automaticamente.

Abbiamo anche clienti che vogliono semplicemente fare un paio di copie di un sito per vari motivi, ad esempio per dimostrare come un sito può avere un aspetto diverso con alcune modifiche.

Qualunque sia la vostra ragione, lo strumento di clonazione nel WordPress Toolkit rende facile copiare tutto, inclusi i file del sito, il database del sito e tutte le impostazioni del WP CMS.

Sincronizzazione

Per vari motivi si potrebbe desiderare di assicurarsi che due siti web WordPress coincidano. WP Toolkit consente di sincronizzare automaticamente sia il database WP che tutti i file WP.

Se hai una copia di staging del tuo sito, mentre la tua copia pubblica viene eseguita altrove, potresti voler sincronizzare i siti perché vuoi copiare le modifiche che hai fatto sul sito di staging sul sito live del WP.

Allo stesso modo, potresti voler copiare alcuni dati del sito di produzione nella tua istanza di staging in modo da poter controllare se le modifiche apportate alla versione di staging giocano bene con i dati live. Oppure, le modifiche apportate al vostro sito di stadiazione hanno causato un cambiamento nelle tabelle del database, nel qual caso il toolkit consente di sincronizzare solo queste modifiche al database, se lo si desidera.

Un altro caso d’uso per la funzione di sincronizzazione di WP Toolkit è quello in cui uno sviluppatore ha aggiornato un sito di staging ad una versione finale di WordPress e vuole rispecchiare le modifiche su un sito live.

Hai la possibilità di sincronizzare l’intero WP CMS, o solo alcune parti di esso. Quindi, è possibile eseguire il mirroring dei file del WP, del suo database o di entrambi. C’è un’ulteriore granularità in offerta in quanto è possibile scegliere tra la sincronizzazione dell’intero database o solo tabelle, o anche tabelle che sono nel sorgente ma non presenti nella destinazione. È anche possibile eseguire il mirroring di singole tabelle.

Caccia ai bug in WP

Plesk WordPress Toolkit permette inoltre agli sviluppatori di individuare e correggere automaticamente gli errori nella fonte del sito web, abilitando la sua modalità di debug.

Conclusione.

Dopo tutto quanto sopra esposto è chiaro che diventa estremamente importante scegliere non solo lo sviluppatore con cui lavorare o l’agenzia che vi può seguire ma soprattutto l’hosting su cui ospitare il vostro sito in WordPress. Anche da queste cose si comprende cosa significhi avere un sito scuro su un hosting professionale o meno.

WordPress non è un “oggetto” semplice da maneggiare. Certo, ci si sente liberi, si pensa di non dover avere bisogno di uno sviluppatore o di non essere vincolati ad una agenzia, si pensa che sia magnifico poter fare da soli ma nella realtà delle cose, la verità dice altro e oggi la sicurezza è un tema non più secondario ma primario anche in virtù degli obblighi e delle responsabilità verso terzi.