L’installazione di WordPress, il CMS più popolare e diffuso al momento, può essere effettuata manualmente oppure attraverso appositi script nell’area di gestione dell’hosting, il più popolare dei quali è Scriptacolous.
Per quanto riguarda la prima modalità, è possibile ed opportuno effettuare alcune modifiche al file wp-config.php che si trova nella cartella principale del pacchetto e contiene i parametri di base dell’installazione, a partire dai dati relativi al database.
Modificando questo file prima di caricarlo online ed avviare l’installazione, è possibile impostare tale parametri, alcuni dei quali richiederebbero procedure complesse per essere modificati in un momento successivo.
Vediamo quali sono le ottimizzazioni consigliate:
1) Prefisso delle tabelle
In un’installazione standard, le tabelle create nel database hanno come prefisso wp_ (a meno che lo script di installazione messo a disposizione dal fornitore di hosting sia impostato in modo tale da creare un prefisso diverso ad ogni installazione).
L’utilizzo del prefisso standard è considerato rischioso poiché l’hacker che dovesse cercare di accedere al server partirebbe da una base nota.
Va detto che questo elemento non è di certo quello più rilevante, nel senso che di solito i pirati informatici sfruttano altri tipi di debolezze per conquistare l’accesso alla piattaforma; trattandosi però di un intervento che non costa alcuna fatica, tanto vale metterlo in pratica.
Il prefisso delle tabella può contenere solo lettere, numeri e l’underscore; una lunghezza di 8/10 caratteri è più che adeguata.
Nel file wp-config.php avremo dunque qualcosa di simile:
$table_prefix = 'wp_jnh_2019';
Rammentiamo che l’uso di prefissi di tabella differenziati è requisito indispensabile per utilizzare 1 database per 2 o più installazioni di WordPress, pratica non consigliata ma accettabile in caso di siti non molto esigenti in termini di risorse.
Notiamo inoltre che è possibile modificare il prefisso delle tabelle successivamente all’installazione del pacchetto, tramite alcuni plugin di firewall e sicurezza del sito.
Si tratta però di operazioni non prive di rischi, onde per cui qualora si proceda in tale modo è necessario disporre di un backup aggiornato del database.
A proposito di siti WordPress e hacker, leggi questi articoli: https://lnx.instantwebsites.it/iwblog/?p=1851 e https://lnx.instantwebsites.it/iwblog/?p=1876
2) Memoria
Se non viene specificato nulla, WordPress utilizza 64 megabyte della memoria disponibile sul server.
Questa quantità è sufficiente a fare funzionare un’installazione di base senza molti plugin, poiché questi ultimi possono determinare un aumento nel consumo delle risorse del server (basti pensare ai processi Cron, cioè programmati in automatico sia dal pacchetto WordPress di base, sia dai plugin stessi).
Un plugin molto esoso in termini di memoria è ad esempio WPML.
E’ dunque opportuno dichiarare quanta memoria è disponibile sul server e può essere utilizzata da WP, aggiungendo questa riga:
define('WP_MEMORY_LIMIT', '256M');
Il valore dipenderà dalle caratteristiche del server, normalmente negli hosting condivisi vengono messi a disposizione 128 o 256 megabyte (più raramente 512).
3) Debug
Dato che “se qualcosa può andare storto, lo farà” (Legge di Murhpy) può accadere che il sito presenti dei malfunzionamenti in una o più parti.
Tralasciando il caso estremo dell’Errore 500 (errore di server), per il quale saranno necessario delle procedure particolari (ne parleremo in un futuro articolo), al fine di individuare l’elemento o gli elementi che causano l’errore è necessario attivare il debug del sito, con o senza memorizzazione in un file di log, specificando che gli errori e gli avvisi devono essere visualizzati nella pagina.
Di base, il file wp-config.php comprende questa dichiarazione:
define('WP_DEBUG', false);
in cui false andrà modificato in true prima di ricaricare il file sul server.
In realtà, per assicurarsi un risultato ottimale su qualsiasi server, è opportuno completare la dichiarazione di cui sopra come segue:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Per attivare il debug, imposteremo i valori su true e su 1 per display_errors (se non desideriamo un log degli errori, possiamo lasciare WP_DEBUG_LOG su false).
Una volta visualizzati gli errori, dovremo individuare da quale elemento sono determinati (file di WordPress mancante o corrotto, problema derivante da un plugin…) per procedere alla correzione.
Le voci contrassegnate con Warning e Notice potranno essere ignorate mentre quelle indicate con Fatal Error e Parse Error, che causano l’interruzione dell’esecuzione degli script, richiederanno il nostro intervento.
Ovviamente, in un sito normalmente funzionante il debug può restare attivo per registrare nel log eventuali problemi che dovessero sorgere dopo un aggiornamento; la visualizzazione degli errori, invece, dovrà essere disattivata per evitare la comparsa di avvisi inutili e fastidiosi per il visitatore del sito.
4) Blocco dell’editor
Una delle voci create di default nel menu di amministrazione di WordPress è quella dell’Editor, posizionata sotto la voce Aspetto.
Essa consente di accedere ai file del tema (foglio di stile CSS, templates di pagina, function.php ecc.)
Risulta consigliabile bloccare l’accesso a tali files da back-end di WordPress per due motivi: il primo è quello di limitare le possibilità dell’utente finale di … causare danni (quando l’amministratore del sito non sia persona tecnicamente qualificata), il secondo è quello di impedire agli hacker che avessero guadagnato accesso al back-end di … causare danni, questa volta volontariamente.
E’ dunque sufficiente aggiungere quanto segue al file wp-config.php:
define('DISALLOW_FILE_EDIT', true);
e la voce Aspetto/Editor non comparirà più nel menu.
…in conclusione…
Esistono numerose altre modifiche possibili al file wp-config.php, che potrete trovare elencate nella pagina linkata più sotto.
Bisogna però limitarsi a ciò che è strettamente necessario ed opportuno, onde evitare errori che potrebbero causare problemi nel funzionamento del sito.
Rammentare infine che tutte le modifiche ed aggiunte devono essere scritte prima della riga:
/* Finito, interrompere le modifiche! Buon blogging. */
Tutto su wp-config.php: https://codex.wordpress.org/Editing_wp-config.php
Tipi di errore in PHP: https://www.quora.com/What-is-the-difference-between-warning-and-fatal-errors-in-PHP