Uno dei file più importanti di un’installazione di WordPress è il file di configurazione. Questo si trova nella directory principale e contiene definizioni di costanti e istruzioni PHP che fanno sì che WordPress funzioni nel modo in cui desiderate.
Il file wp-config.php memorizza dati come le credenziali per la connessione al database, il prefisso delle tabelle, i percorsi di directory specifiche e molte altre impostazioni relative a caratteristiche specifiche che analizzeremo dettagliatamente in questo articolo.

Il File wp-config.php di Base

Quando installate WordPress per la prima volta, vi viene chiesto di inserire alcune informazioni obbligatorie come le credenziali di accesso al database e il prefisso delle tabelle. A volte il vostro host installerà WordPress al posto vostro e non vi sarà richiesto di eseguire manualmente il set-up. Ma quando eseguite manualmente l’installazione “in 5 minuti”, vi sarà chiesto di inserire alcuni dei dati più rilevanti memorizzati in wp-config.

Dati memorizzati nel file wp-config.php durante l'installazione
Quando si esegue l’installazione, viene richiesto l’inserimento di dati che vengono memorizzati nel file wp-config.php

Ecco un file wp-config.php di base:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

define('AUTH_KEY',		'put your unique phrase here');
define('SECURE_AUTH_KEY',	'put your unique phrase here');
define('LOGGED_IN_KEY',		'put your unique phrase here');
define('NONCE_KEY',		'put your unique phrase here');
define('AUTH_SALT',		'put your unique phrase here');
define('SECURE_AUTH_SALT',	'put your unique phrase here');
define('LOGGED_IN_SALT',	'put your unique phrase here');
define('NONCE_SALT',		'put your unique phrase here');

$table_prefix  = 'wp_';

/* That's all, stop editing! Happy blogging. */

Di solito, questo file viene generato automaticamente quando si esegue il set-up, ma a volte WordPress non dispone dei privilegi per scrivere nella cartella di installazione. In questa situazione, dovreste creare un file wp-config.php vuoto, copiare e incollare il contenuto da wp-config-sample.php e assegnare i valori corretti a tutte le costanti definite. Quando avete finito, caricate il vostro file nella cartella principale ed esegui WordPress.

Nota: le definizioni delle costanti costanti e le istruzioni PHP sono disposte in un ordine specifico che non dovrebbero mai essere cambiate. E dovrebbero mai essere aggiunti contenuti sotto la seguente riga di commento:

/* That's all, stop editing! Happy blogging. */

Per prima cosa, vengono definite costanti del database, che dovreste aver ricevuto dal vostro host:

  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DB_HOST
  • DB_CHARSET
  • DB_COLLATE

Successivamente ai dati di connessione del database, otto chiavi di sicurezza renderanno il sito più sicuro contro gli hacker. Quando eseguite l’installazione, WordPress genererà automaticamente le chiavi di sicurezza e le salt keys, ma potete cambiarle in ogni momento aggiungendo una qualsiasi stringa arbitraria. Per una maggiore sicurezza, valutate la possibilità di utilizzare il generatore online.

La variabile $table_prefix memorizza il prefisso di tutte le tabelle di WordPress. Sfortunatamente, tutti conoscono il suo valore predefinito e questo potrebbe aprire il database di WordPress ad una vulnerabilità, che però può essere facilmente eliminata impostando un valore personalizzato per $table_prefix al momento dell’installazione.
Per modificare il prefisso della tabella in un sito web funzionante, è necessario eseguire diverse query sul database, quindi modificare manualmente il file wp-config.php. Se non si ha accesso al database o se non si dispone delle conoscenze necessarie per creare query personali, è possibile installare un plugin come Change Table Prefix, che rinominerà tabelle e nomi dei campi del database e aggiornerà il file di configurazione senza rischio.

Nota: è una buona pratica eseguire il backup di file e database di WordPress anche se si modificha il prefisso della tabella con un plugin.

Finora l’analisi è stata limitata alla configurazione di base. Ma abbiamo a disposizione molte costanti che possiamo definire per abilitare funzionalità, personalizzare e proteggere l’installazione

Oltre la Configurazione di Base: Modifica del file system

Il file system di WordPress è ben noto agli utenti e agli hacker. Per questo motivo, potreste prendere in considerazione la possibilità di modificare la struttura dei file predefinita spostando cartelle specifiche in posizioni arbitrarie e impostando gli URL e i percorsi corrispondenti nel file wp-config.
Per prima cosa, possiamo spostare la cartella del contenuto definendo due costanti. La prima imposta il percorso completo della directory:

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/site/wp-content' );

La seconda imposta il nuovo URL della directory:

define( 'WP_CONTENT_URL', 'http://example.com/site/wp-content' );

Possiamo anche spostare solo la cartella dei plugin, definendo le seguenti costanti:

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/mydir/plugins' );
define( 'WP_PLUGIN_URL', 'http://example.com/wp-content/mydir/plugins' );

Allo stesso modo, possiamo spostare la cartella degli upload, assegnando un nuovo percorso alla directory:

define( 'UPLOADS', 'wp-content/mydir/uploads' );

Nota: tutti i percorsi sono relativi a ABSPATH e non devono contenere una barra iniziale.

Quando avrete fatto, spostate le cartelle e ricaricate WordPress.

La struttura dei file predefinita messa a confronto con una struttura personalizzata
L’immagine mostra la struttura dei file predefinita messa a confronto con una struttura personalizzata

Non è possibile spostare la cartella/wp-content/themes dal file wp-config, ma possiamo registrare una nuova directory dei temi in un plugin o nel file functions.php di un tema.

Funzionalità per Sviluppatori: Modalità di Debug e Salvataggio delle Query

Se siete sviluppatori, potete forzare WordPress a mostrare errori e avvisi che vi aiuteranno nel debugging di temi e plugin. Per abilitare la modalità di debug dovete solo impostare il valore di WP_DEBUG su true, come mostrato di seguito:

define( 'WP_DEBUG', true );

WP_DEBUG è impostato su false per impostazione predefinita. Se è necessario disabilitare la modalità di debug, è sufficiente rimuovere la definizione o impostare il valore della costante a false.
Quando lavorate su un sito live, dovreste disabilitare la modalità di debug. Errori e avvisi non dovrebbero mai essere mostrati agli utenti del sito perché possono fornire informazioni preziose agli hacker. Ma cosa fare se doveste eseguire il debug comunque?
In tali situazioni, è possibile forzare WordPress a memorizzare di errori e avvisi nel file debug.log, inserito nella cartella /wp-content. Per abilitare questa funzionalità, copiate e incollate il seguente codice nel vostro file wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Per far sì che questa funzionalità operi correttamente, prima bisogna abilitare la modalità di debug. Quindi, impostando WP_DEBUG_LOG su true, forziamo WordPress a memorizzare i messaggi nel file debug.log, mentre impostando WP_DEBUG_DISPLAY su false, li nascondiamo dallo schermo. Infine, impostiamo a 0 il valore della variabile PHP display_errors in modo che i messaggi di errore non vengano stampati sullo schermo. Il file wp-config non viene mai caricato dalla cache. Per questo motivo, è un ottimo posto per sovrascrivere le impostazioni di php.ini.

Nota: questa è un’ottima funzionalità che potete sfruttare per registrare i messaggi che WordPress non stamperebbe sullo schermo. Ad esempio, quando viene attivata l’azione publish_post, WordPress carica uno script che salva i dati, quindi reindirizza l’utente alla pagina di modifica del post. In questa situazione è possibile registrare i messaggi, ma non stamparli sullo schermo.

Un’altra costante di debug determina le versioni di script e stili da caricare. Impostate SCRIPT_DEBUG a true se desiderate caricare le versioni non compresse:

define( 'SCRIPT_DEBUG', true );

Se il vostro tema o plugin mostra i dati recuperati dal database, potreste pensare di memorizzare i dettagli della query per una successiva revisione. La costante SAVEQUERIES obbliga WordPress a memorizzare le informazioni delle query nell’array $wpdb->queries. Questi dati saranno stampati aggiungendo il seguente codice al template del footer:

if ( current_user_can( 'administrator' ) ) {
        global $wpdb;
        echo '<pre>';
        print_r( $wpdb->queries );
        echo '</pre>';
}

Per un’analisi più approfondita di questa funzione, fate riferimento al nostro tutorial su Come Creare Query Efficienti in WordPress.

Impostazioni Relative al Contenuto

Quando il vostro sito web cresce, potreste pensare di ridurre il numero delle revisioni dei post. Di default, WordPress salva automaticamente le revisioni ogni 60 secondi. Possiamo modificare questo valore impostando un intervallo personalizzato in wp-config come segue:

define( 'AUTOSAVE_INTERVAL', 160 );

Naturalmente, potete anche ridurre l’intervallo del salvataggio automatico.
Ogni volta che salviamo le nostre modifiche, WordPress aggiunge una riga alla tabella posts, in modo da poter ripristinare precedenti revisioni di post e pagine. Questa è una funzionalità utile che potrebbe trasformarsi in un problema quando il nostro sito cresce in dimensioni. Fortunatamente, possiamo ridurre il numero massimo delle revisioni dei post da memorizzare o disabilitare del tutto la funzionalità.
Per disabilitare le revisioni dei post, basta definire la seguente costante:

define( 'WP_POST_REVISIONS', false );

Per limitare il numero massimo di revisioni, aggiungete, invece, la seguente riga:

define( 'WP_POST_REVISIONS', 10 );

Di default, WordPress archivia post, pagine, allegati e commenti cestinati per 30 giorni, quindi li elimina in modo permanente. Possiamo cambiare questo valore con la seguente costante:

define( 'EMPTY_TRASH_DAYS', 10 );

Possiamo anche disabilitare il cestino, impostando il suo valore di questa costante a 0, ma fate attenzione perché WordPress non vi permetterà più di ripristinare i contenuti cestinati.

Allowed Memory Size

Di tanto in tanto potreste ricevere un messaggio come quello che segue:

Fatal error: Allowed memory size of xxx bytes exhausted …

La dimensione massima della memoria dipende dalla configurazione del server. Nel caso in cui non si abbia accesso al file php.ini, è possibile aumentare il limite di memoria solo per WordPress definendo la costante WP_MEMORY_LIMIT nel file wp-config. Di default, WordPress tenta di allocare 40Mb a PHP per singoli siti e 64 MB per installazioni multisite. Ovviamente, se la memoria allocata a PHP è maggiore di 40Mb (o 64Mb), WordPress adotterà il valore massimo.
Detto questo, potete impostare un valore personalizzato con la seguente riga:

define( 'WP_MEMORY_LIMIT', '128M' );

Se necessario, è possibile impostare un limite massimo di memoria, con la seguente dichiarazione:

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

Aggiornamenti Automatici

A partire dalla versione 3.7, WordPress supporta gli aggiornamenti automatici per le release di sicurezza. Questa è una funzionalità importante che consente agli amministratori del sito di mantenere il loro sito web costantemente al sicuro.

Potete disabilitare tutti gli aggiornamenti automatici definendo la seguente costante:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Forse non è una buona idea disabilitare gli aggiornamenti di sicurezza, ma è una vostra scelta.
Per impostazione predefinita, gli aggiornamenti automatici non funzionano con le major release, ma è possibile abilitare tutti gli aggiornamenti del core definendo la costante WP_AUTO_UPDATE_CORE come segue:

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );

Il valore predefinito è minor:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Una costante aggiuntiva disattiva gli aggiornamenti automatici (e qualsiasi aggiornamento o modifica a qualsiasi file). Se impostate DISALLOW_FILE_MODS a true, tutte le modifiche ai file saranno disabilitate, ma con queste saranno disabilitate anche le installazioni e gli aggiornamenti di temi e plugin. Per questo motivo, il suo utilizzo non è consigliato.

Impostazioni di Sicurezza

Possiamo utilizzare il file wp-config per aumentare la sicurezza del sito. Oltre alle modifiche alla struttura dei file che abbiamo esaminato sopra, possiamo bloccare alcune funzionalità che potrebbero aprire vulnerabilità non necessarie. Prima di tutto, possiamo disabilitare l’editor dei file presente nel pannello di amministrazione. La seguente costante nasconderà la schermata Aspetto -> Editor:

define( 'DISALLOW_FILE_EDIT', true );

Nota: alcuni plugin potrebbero non funzionare correttamente se il valore di questa costante è true.

Disabilitare la modifica dei file
Disabilitare la modifica dei file

Una funzionalità di sicurezza è l’Amministrazione su SSL. Se avete acquistato un certificato SSL, e l’avete configurato correttamente, potete forzare WordPress a trasferire i dati su SSL in tutte le sessioni di accesso e di amministrazione. Per far questo, utilizzate la seguente costante:

define( 'FORCE_SSL_ADMIN', true );

Date un’occhiata al Codex se avete bisogno di maggiori informazioni sull’Amministrazione su SSL.

Altre due costanti consentono di bloccare le richieste esterne e di elencare gli host ammessi.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'example.com,*.anotherexample.com' );

In questo esempio, abbiamo prima disabilitato tutti gli accessi da host esterni, quindi elencato gli host ammessi, separati da virgole (i caratteri jolly sono consentiti).

Altre Impostazioni Avanzate

WP_CACHE impostato su true include lo script wp-content/advanced-cache.php. Questa costante ha effetto solo se installate un plugin di cache persistente.

CUSTOM_USER_TABLE e CUSTOM_USER_META_TABLE vengono utilizzati per impostare tabelle utente personalizzate diverse dalle tabelle predefinite wp_user e wp_usermeta. Queste costanti abilitano una funzionalità utile che permette agli utenti del sito di accedere a diversi siti web con un solo account. Affinché la condivisione funzioni correttamente, tutte le installazioni devono condividere lo stesso database.

A partire dalla versione 2.9, WordPress supporta l’ottimizzazione automatica del database. Grazie a questa funzionalità, impostando WP_ALLOW_REPAIR su true, WordPress riparerà automaticamente un database danneggiato.

WordPress crea un nuovo set di immagini ogni volta che modificate un’immagine. Se ripristinate l’immagine originale, tutti i set generati rimarranno sul server. Potete sovrascrivere questo comportamento impostando IMAGE_EDIT_OVERWRITE su true, in modo che, quando ripristinate l’immagine originale, tutte le modifiche vengano eliminate dal server.

Mettere in Sicurezza il File wp-config.php

Ora sappiamo perché wp-config.php è uno dei file di WordPress più importanti. Quindi, perché non lo nascondiamo agli hacker? Prima di tutto, possiamo spostare il file wp-config di un livello sopra la cartella principale di WordPress (solo un livello). Tuttavia, questa tecnica è un po ‘controversa, quindi personalmente suggerirei di adottare altre soluzioni per proteggere il file. Se il vostro sito web è in esecuzione su Apache Web Server, potete aggiungere le seguenti direttive al file .htaccess:

<files wp-config.php>
order allow,deny
deny from all
</files>

Se il sito web è in esecuzione su Nginx, è possibile aggiungere la seguente direttiva al file di configurazione:

location ~* wp-config.php { deny all; }

Nota: queste istruzioni dovrebbero essere aggiunte solo dopo aver completato il set-up.

Se il vostro sito web ha subito più migrazioni o l’hai acquistato da qualcun altro, vi consigliamo di creare un nuovo set di chiavi di sicurezza di WordPress. Queste chiavi sono un insieme di variabili casuali che migliorano la crittografia delle informazioni memorizzate nei cookie dell’utente. A partire da WordPress 2.7 ci sono 4 chiavi diverse: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY e NONCE_KEY.

Di default, vengono generate casualmente. WordPress fornisce in realtà uno strumento gratuito che potete utilizzare per generare nuove chiavi casuali. È quindi possibile semplicemente aggiornare le chiavi correnti che sono memorizzate nel file wp-config.php.

Chiavi di sicurezza di WordPress
Chiavi di sicurezza di WordPress

Maggiori informazioni sulle chiavi di sicurezza di WordPress.

Infine, dovreste fare un doppio controllo per assicurarvi che le vostre autorizzazioni sul vostro file wp-config.php siano rigide. In genere i permessi sui file nella directory principale di un sito WordPress saranno impostati su 644, il che significa che i file sono leggibili e scrivibili dal proprietario del file e leggibili dagli utenti del gruppo proprietario di quel file e da tutti gli altri. Secondo la documentazione di WordPress, le autorizzazioni sul file wp-config.php dovrebbero essere impostate su 440 o 400 per impedire la lettura ad altri utenti sul server. Potete facilmente modificare questo valore con il vostro client FTP.

Permessi sul file wp-config
wp-config.php permissions

Riepilogo

In questo post ho elencato un bel po’ di costanti di WordPress che possiamo definire nel file wp-config. Alcune di queste costanti sono di uso comune e le loro funzioni sono facili da capire. Altre costanti consentono di abilitare funzionalità avanzate che richiedono una profonda conoscenza di WordPress e dell’amministrazione del sito.

Ho elencato le funzionalità più comuni, lasciando da parte alcune funzionalità avanzate che potremmo discutere in post futuri. Se volete esplorare caratteristiche e costanti che non sono elencate nel post, avviate una conversazione nei commenti qui sotto e le approfondiremo insieme.

Carlo Daniele Kinsta

Carlo è cultore appassionato di webdesign e front-end development. Gioca con WordPress da oltre 20 anni, anche in collaborazione con università ed enti educativi italiani ed europei. Su WordPress ha scritto centinaia di articoli e guide, pubblicati sia in siti web italiani e internazionali, che su riviste a stampa. Lo trovate su LinkedIn.