Il file wp-config.php fa parte del cuore di WordPress ed oltre ad essere il punto di partenza per qualsiasi nuova installazione, rappresenta il fulcro centrale delle impostazioni e configurazioni di base di questo CMS (Content Management System). Quando si scarica una copia vergine di WordPress il file si trova con il come wp-config-sample.php ed occorre rinominarlo in wp-config.php per fare in modo che venga utilizzato dal sistema.
All’interno di questo file sono indicate le informazioni basilari per l’accesso al database (host, nome utente, password, prefisso delle tabelle), le chiavi di salatura (usate dal sistema di login e dai form del backend), la modalità di debug e la lingua di WordPress (modificabile nelle ultime versioni anche da backend).
Ci sono però alcune configurazioni avanzate di WordPress che è possibile attivare proprio agendo all’interno del wp-config.php. Oggi ne vediamo 10 che, forse, non conoscete.
1) Revisioni dei post
Quante volte vi è capitato di lavorare per più giorni ad un post? Oppure di modificare ed aggiornare una pagina molte volte? A me capita spesso.
Ogni volta che salvate un post o una pagina cliccando il pulsante “Aggiorna” WordPress crea una nuova revisione, ovvero una copia dello stato del post. Questo vi permette, in caso di errori o ripensamenti, di “tornare indietro” e riprisitinare una versione precedente.
Il “problema” delle revisioni è che “occupano spazio” nel vostro database MySql e possono potenzialmente rallentare il vostro sito (anche perchè sono memorizzate nella stessa tabella wp_posts dove risiedono i post “reali”). Quindi, nell’ottica di ottimizzare il database MySql, possiamo limitarne il numero con una semplice costante di configurazione chiamata WP_POST_REVISIONS da inserire nel vostro wp-config.php in queste varianti:
define(‘WP_POST_REVISIONS’, false);
se volete completamente disabilitare il salvataggio delle revisioni. Oppure, in modo più prudente, e consigliato:
define(‘WP_POST_REVISIONS’, 3);
che limita a 3 il numero massimo di revisioni salvate.
2) Svuotare il cestino
Ogni volta che un utente cancella un post o una pagina questa viene spostata nel Cestino di WordPress e verrà cancellata dopo 30 giorni. Anche in questo caso parliamo di record che “occupano spazio” inutilmente nel database, perciò possiamo definire la costante ‘EMPTY_TRASH_DAYS’ in modo da limitare questo periodo. Nel mio caso ho impostato a 10 giorni la cancellazione automatica degli elementi nel cestino, ecco come:
define( ‘EMPTY_TRASH_DAYS’, 10);
se siete sempre sicuri di quello che fate 🙂 potete disabilitare completamente il cestino impostando la costante con il valore 0.
define( ‘EMPTY_TRASH_DAYS’, 0);
3) Modificare l’intervallo di autosalvataggio
Per questa configurazione non spendo tante parole, sappiate che WordPress salva una “bozza” dei vostri post e pagine mentre li scrivete ad intervalli regolari di 60 secondi. Qualora voleste modificare questo periodo di tempo, perchè volete accorciarlo o allungarlo, la costante da inserire nel file wp-config è:
define( ‘AUTOSAVE_INTERVAL’, 120); // Il valore è in secondi, nell’esempio 2 minuti
4) Disabilitare gli aggiornamenti automatici
Dalla versione 3.7 WordPress è in grado di auto-aggiornarsi senza l’intervento degli amministratori. Gli aggiornamenti automatici sono, per impostazione di default, abilitati solo per le minor release: significa che se possedete la versione 4.1.1 WordPress si aggiornerà automaticamente alle versioni 4.1.2, 4.1.3, ecc ma non alla versione 4.2.
Questo può essere un vantaggio, perchè non dovrete preoccuparvi di aggiornare WP per bug fix urgenti o release di sicurezza ed avrete sempre un’installazione aggiornata (cosa estremamente consigliata), ma può essere anche uno svantaggio.
Capita a volte di personalizzare in modo spinto la piattaforma, di utilizzare plugin di dubbia provenienza o temi di sviluppatori poco professionali che rendono “rischioso” l’aggiornamento automatico in quanto “potrebbe rompersi qualcosa” ed è preferibile agire in modo manuale, verificando subito dopo che tutto funzioni correttamente.
Se siete in quest’ultimo caso consiglio di disabilitare gli aggiornamenti automatici con questa configurazione:
define( ‘WP_AUTO_UPDATE_CORE’, false );
Se invece siete sicuri di avere un’installazione “pulita” e non volete preoccuparvi di niente, potete lasciare le impostazioni di default oppure passare al “pilota automatico” facendo gestire a WordPress tutti gli aggiornamenti (temi, plugin e traduzioni compresi). Per farlo occorre agire in un altro file chiamato functions.php (che risiede sempre all’interno del tema che state usando) aggiungendo alcuni filtri per cui vi rimando alla documentazione ufficiale.
5) Disabilitare la modifica dei files da backend
WordPress permette di modificare i files di temi e plugin direttamente dal backend. Questo significa che se un malintenzionato riesce ad entrare nel backend (indovina per esempio la vostra password di admin) può modificare i file della vostra installazione direttamente da li e fare potenzialmente danni o semplicemente farvi diventare degli spammer (immaginate se inserisse un link ad un sito che vende viagra).
Per evitare tutto questo è sufficiente abilitare una delle nostre configurazioni avanzate di WordPress, eccola:
define(‘DISALLOW_FILE_EDIT’, true);
Se vi interessa qualche nozione in più sulla sicurezza di WordPress, in questo articolo ho descritto alcuni attacchi che ho subito e alcune contromisure che ho poi adottato per proteggere i miei siti WP.
6) Spostare/Rinominare la cartella wp-content
Sempre nell’ottica di aumentare la sicurezza di WordPress possiamo spostare o rinominare la cartella wp-content, ovvero la cartella dove vengono salvati tutti i file caricati dagli utenti e dove risiedono plugin e temi.
Molti bot automatici alla ricerca di installazioni WordPress cercano proprio la cartella wp-content per identificare un sito che usa questo CMS e provare quindi a bucarlo in base alle falle conosciute nelle varie versioni.
Consiglio la seguente configurazione solo a quelli che partono con una nuova installazione (in una esistente si dovrebbero infatti fare delle migrazioni dei dati):
define( ‘WP_CONTENT_DIR’, dirname(__FILE__) . ‘/miopath/miacartella’);
define( ‘WP_CONTENT_URL’, ‘http://www.tuodominio.it/miopath/miacartella’);
Potete inserire qualsiasi path a cartella già esistente nel vostro spazio web, anche se si trova fuori (anzi meglio) dalla cartella di installazione di WordPress. Fate attenzione a non inserire l’ultimo “/” nel path di configurazione, non è richiesto.
7) Indirizzi di installazione WordPress e home del sito web
Secondo alcuni guru di WordPress che seguo impostare direttamente nel file wp-config.php le configurazioni relative alle url di installazione di WordPress e alla url della homepage del sito web aiuta a migliorare le performance.
Queste 2 configurazioni avanzate:
define( ‘WP_SITEURL’, ‘http://miodominio.it/wp );
define( ‘WP_HOME’, ‘http://miodominio.it’ );
vanno infatti in ovverride delle impostazioni salvate tramite la pagina Impostazioni del backend nella tabella del database delle opzioni di WordPress. Perciò scrivendole nel wp-config.php si evita una query al database. Se siete dei perfezionisti… 🙂
8) Cambiare il prefisso delle tabelle di WordPress
So che questa configurazione la conoscete tutti… ma voglio spenderci ugualmente due parole per due consigli pratici:
- il primo è di usare sempre un prefisso randomico seguito dal suffisso di default di WP. Ovvero impostare (a titolo di esempio) il prefisso delle tabelle su “xy783z_wp_” anzichè semplicemente “xy783z_”. Trovo infatti che lasciare la parte con il “wp_” (che è la configurazione di base) aiuti a comprendere meglio e più velocemente eventuali tutorial che troverete in rete (soprattutto quelli con le query SQL)
- il secondo è di usare sempre lettere minuscole per il prefisso. Non so spiegarne il motivo tecnico, ma mi è capitato che in un particolare Hosting WordPress non riuscivo a far funzionare il sito perchè avevo installato WP usando un prefisso tipo “HostingVirtuale0045_wp_” mentre il server MySql utilizzava le tabelle come “hostingvirtuale0045_wp_”. Mistero. Magari non vi capiterà mai, ma tanto… cosa vi costa usare le minuscole? 🙂
Nel caso non sapessi di cosa sto parlando, mi riferisco a questa configurazione del nostro file wp-config.php:
$table_prefix = ‘wp_’; // Solo numeri, lettere e underscore
che definisce il prefisso delle tabelle del database di WordPress e che è altamente consigliato di cambiare rispetto alla versione standard per ragioni legate alla sicurezza.
9) Debug su WordPress
Mai capitata la famosa “pagina bianca di WordPress”? Quando si verifica un errore su WordPress spesso non vengono date molte informazioni (giustamente) e quindi è necessario attivare la modalità di debug. Nella sua versione più semplice e veloce consiste nell’impostare a TRUE la costante WP_DEBUG già presente nel vostro file wp-config.php in questo modo:
define(‘WP_DEBUG’, true);
noi però stiamo parlando di configurazioni avanzate, perciò facciamo un passo in più ed invece di far visualizzare a tutti i nostri errori (che a questo punto vengono stampati direttamente a video al posto della pagina bianca) li facciamo scrivere all’interno di un file di testo, chiamato file di log. Ecco come:
define(‘WP_DEBUG_LOG’, true); // questo dice a WP di scrivere il log di debug dentro al file su /wp-content/debug.log
define(‘WP_DEBUG_DISPLAY’, false); // dice a WP di non mostrare gli errori “a video”
@ini_set(‘display_errors’, 0); // stessa cosa della precedente riga, ma si tratta di un impostazione del php.ini
10) Accessi FTP
In alcuni hosting linux che ho utilizzato non era possibile installare (in modo immediato) i plugin dal backend (o gli aggiornamenti di WordPress) perchè venivano richieste ogni volta le credenziali FTP per l’accesso allo spazio web. Perciò, se vi trovate in questa situazione, potete inserire i vostri dati di accesso FTP direttamente nel file wp-config in questo modo:
define(‘FTP_HOST’, ‘ftp.dominio.it’);
define(‘FTP_USER’, ‘ftp@dominio.it’);
define(‘FTP_PASS’, ‘password’);
ovviamente compilando i valori delle costanti con le vostre credenziali.
Conclusioni
Per concludere, ricordate sempre di inserire le regole cha abbiamo visto prima dell’inclusione del file php chiamato settings.php (ovvero prima della riga require_once(ABSPATH . ‘wp-settings.php’);) perchè se lo fate dopo le vostre configurazioni non verranno caricate.
Queste sono le configurazioni avanzate che ho realmente utilizzato in alcuni siti WordPress che ho sviluppato. Ne esistono moltissime altre (ad esempio il backend con SSL), ma per ora non le ho mai usate.
Spero l’articolo vi sia piaciuto. Conoscevate già queste configurazioni avanzate? Se sì, quali usate nella vostra installazione WordPress? Parliamone nei commenti.
Niki Rocco è Senior Web Developer e Seo Specialist presso Quag, il social network che ti mette subito in contatto con persone nuove con i tuoi stessi interessi. Su Quag puoi condividere le tue passioni, raccontando le tue emozioni.
Lascia un commento