Lo conosci bene il file wp-config.php di WordPress? Sai che in poche righe di codice php è racchiuso un sorprendente potenziale? Ho scritto questa guida non solo per fare un tour del file wp-config.php, ma anche per evidenziare alcune parti di cui forse non sapevi l’esistenza, ma che in realtà dovresti conoscere meglio.
Se conosci tutto quello che c’è da sapere sul file wp-config.php ed hai letto l’ intera pagina della documentazione di WordPress questa guida non è per te, ma se vuoi conoscere cose interessanti come sviluppatore, raggruppate bene per argomento allora resta e leggi l’articolo fino in fondo.
- Chi dovrebbe leggere la guida wp-config.php e perchè.
- Visualizzazione delle costanti wp-config
- Analizzare il processo di caricamento di wp-config.php
- Controllo/Formattazione del file wp-config.php
- Protezione di WordPress con wp-config.php
- Spostare cose
- Impostazioni relative al contenuto
- In conclusione
Chi dovrebbe leggere la guida wp-config.php e perchè.
Questo guida è rivolta a sviluppatori e utenti avanzati che sanno già come modificare il file wp-config.php e sono a conoscenza delle impostazioni di configurazione che è possibile inserirvi.
Se sei un principiante, wp-config.php ti basta cercare in rete le numerose guide che possono fornirti nozioni di base oppure puoi sempre dare un’occhiata alla documentazione ufficiale.
Ma se si trovano le guide di base, se il tuo provider già provvede ad impostare wp-config.php per te conosci più o meno bene il file e sei soddisfatto della situazione, allora perchè dovresti leggere questa guida?
Alziamo un po’ il livello e diciamo che, probabilmente, sei almeno in parte responsabile dell’hosting di siti di grandi dimensioni, magari direttamente per il cliente perciò è meglio che tu sappia come puoi utilizzare questo file in caso di emergenza, e porre maggiore attenzione a non fare modifiche errate che possano creare problemi.
Inoltre, anzi quasi sicuramente, vorrai bloccare alcune funzionalità di WordPress oltre alla configurazione di base del file.
Visualizzazione delle costanti wp-config
Senza la necessità di eseguire SSH sul server remoto ed aprire il file wp-config.php ci sono già alcuni modi per controllare rapidamente i valori delle costanti usate da WordPress .
La funzione Salute del sito (Site Health) del core di WordPress consente di visualizzare alcuni valori di base navigando su “Strumenti -> Salute del sito“, cliccando sul Tabs “Informazioni” e aprendo sia “Costanti di WordPress” sia “Database” della stessa pagina.
Utilizzare il plug-in Query Monitor che ha un pannello “Ambiente” (Environment) in cui si possono vedere alcune costanti del file wp-config.php comunemente usate.
wp-config.php. Questa operazione normalmente richiederebbe prima di fare accesso tramite SSH, ma se si impostano gli alias nella configurazione WP-CLI personalizzata, è possibile creare un collegamento rapido per visualizzare e modificare le costanti.Analizzare il processo di caricamento di wp-config.php
È utile sapere quando viene caricato il file wp-config.php, dal momento che il processo determina alcune delle cose che puoi e non puoi fare con esso.
- WordPress inizia a caricarsi con il file
index.phpil quale richiede il filewp-blog-header.php. - Praticamente la prima cosa che fa il file
wp-blog-header.phpè caricarewp-load.php. - Quindi,
wp-load.phpimposta la costante ABSPATH (la directory principale di WordPress) e inizializzaerror_reporting()prima di caricarewp-config.php.
Questo processo di caricamento, e il codice in wp-load.php in particolare, possono darci alcune informazioni interessanti. Infatti se date un’occhiata a questo file si può capire che:
wp-config.php può essere spostato in alto
guardando bene, il commento ci indica che possiamo inserire wp-config.php nella “root di WordPress“. Quello che non viene menzionato però è che la radice (root) può effettivamente essere una directory sopra ABSPATH posizione in cui wp-load.php effettivamente si trova.
Possiamo individuare questo controllo aggiuntivo nel punto elseif trovando la riga dirname( ABSPATH ) . '/wp-config.php'.
La condizione aggiuntiva nella elseif è spiegata nel commento sopra la riga stessa.
Se non è presente un file wp-config.php viene caricata la schermata di configurazione di WordPress
Dopo possiamo vedere che se non esiste un file di configurazione (wp-config.php), WordPress procederà a caricare la schermata di configurazione.
È possibile che tu non abbia mai visto questa schermata prima, infatti. consente di inserire le informazioni di configurazione iniziale, tipo le credenziali del database ecc., ma evidentemente se trovi WordPress già installato dal provider non vedrai questa schermata.
Questa è una caratteristica di WordPress che vale la pena sapere. Per esempio, se hai mai caricato WordPress per la prima volta su un server web pubblico, ma non hai creato un file wp-config.php, attenzione perchè qualcun altro (anche probabilmente, un bot) può arrivare sulla pagina e configurare WordPress a piacere ed anche hackerare il tuo hosting.
wp-config.php si carica molto presto
La terza cosa da notare è che wp-config.php viene caricato molto presto nella sequenza di avvio di WordPress e questo significa che:
- Ci sono azioni che non possiamo fare nel file
wp-config.php. Ad esempio, non possiamo aggiungere hook (azioni o filtri) perché le funzioni e le strutture dati per farlo non sono ancora state caricate. E non abbiamo accesso a nessuna delle funzioni, oggetti e API interni di WordPress. - Abbiamo il controllo su quello che accadrà dopo. Dato che il file viene caricato così presto, la cosa ha molta influenza su WordPress. Questo è sia bene che male. Possiamo facilmente stoppare completamente WordPress, ma possiamo anche accedere a tutto ciò che è definito nel file
wp-config.phpovvero praticamente da qualsiasi altra parte in WordPress.
Mai scherzare con wp-config.php!
Qualcuno ha detto: da un grande potere derivano grandi responsabilità. Detto fatto, infatti in fondo al file wp-config.php ci sono queste righe:
/* Add any custom values between this line and the "stop editing" line. */
/* That's all, stop editing! Happy publishing. */
/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', dirname( __FILE__ ) . '/' );
}
/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';Ci sono alcune istruzioni, ma la cosa importante è la riga dove si legge “stop editing”, infatti, dopo questa riga, c’è la continuazione della sequenza di inizializzazione di WordPress e l’inserimento di nuovo codice nel posto sbagliato comporterà non solo che il nuovo codice non avrà alcun effetto, ma anche malfunzionamenti. Per sicurezza, è consigliabile seguire queste istruzioni. Se sono lì, ci sarà una buona ragione.
Controllo/Formattazione del file wp-config.php
Se stai lavorando in produzione, l’ultima cosa che vorresti è l’inserimento di sviste od errori nel tuo file wp-config.php. Gli errori, oltre che danneggiano il tuo sito Web, si rischia anche di non individuarli perchè non viene emesso un messaggio di errore quando succedono.
E’ una buona cosa eseguire php sulla riga di comando con l’opzione (“lint”) per controllare il tuo file wp-config.php ed evitare errori di sintassi PHP come nell’esempio sotto:
$ php -l wp-config.php
Parse error: syntax error, unexpected token "require_once" in wp-config.php on line 9
Errors parsing wp-config.php
Si potrebb anche scrivere uno script di shell per:
- Copiare
wp-config.phpin un file temporaneo - Modifica il file temporaneo
- Aggiustare (linting) il file temporaneo
- Ricopiarlo di nuovo solo se non ha errori di sintassi
Se hai dimestichezza con la riga di comando, è più sicuro utilizzare i comandi WP-CLI tipo wp config set <name> <value> per impostare i valori in modo sicuro piuttosto che farlo a mano.
Puoi anche elencare i tuoi valori di configurazione con WP-CLI (questo è un esempio con alcune voci rimosse: potrebbe essere uno spunto!):
$ wp config list +---------------------+-----------------------------------------------+----------+ | name | value | type | +---------------------+-----------------------------------------------+----------+ | root_dir | /Users/smithers/sites/testsite | variable | | webroot_dir | /Users/smithers/sites/testisite/public | variable | | table_prefix | wp_ | variable | | WP_HOME | https://testsite.test | constant | | WP_SITEURL | https://testsite.test/ | constant | | DB_NAME | snpp | constant | | DB_USER | root | constant | | DB_PASSWORD | Patton | constant | | DB_HOST | 127.0.0.1 | constant | | DB_CHARSET | utf8mb4 | constant | | DB_COLLATE | | constant | | DB_PREFIX | wp_ | constant | | WP_DEBUG | 1 | constant | | WP_DEBUG_LOG | 1 | constant | | WP_DEBUG_DISPLAY | | constant | | WP_ENVIRONMENT_TYPE | development | constant | | DISABLE_WP_CRON | | constant | | DISALLOW_FILE_EDIT | 1 | constant | +---------------------+-----------------------------------------------+----------+
Queste due tecniche potrebbero davvero farti risparmiare qualche seccatura e impedirti di impazzire per aver accidentalmente messo un punto e virgola nel posto sbagliato in un file così critico.
Protezione di WordPress con wp-config.php
La sicurezza è un argomento perennemente attuale in WordPress. Alcune impostazioni che possiamo modificare nel file wp-config file danno a disposizione più strumenti per la sicurezza.
Queste parti del file wp-config file non sono sicuramente le uniche cose da usare per ottenere una buona sicurezza di WordPress. Naturalmente bisogna di comprendere a fondo la sicurezza del sito Web.
Protezione di wp-config.php dai visitatori del sito web
Il tuo file wp-config.php risiede nella directory principale del tuo sito Web per impostazione predefinita e contiene informazioni critiche come i dettagli di accesso del database e le password salt. Ovviamente, non vuoi che queste informazioni siano pubblicamente disponibili, quindi ti devi assicurare che il tuo file wp-config sia protetto dai visitatori del sito web.
La tua società di hosting potrebbe farlo per te, ma molto spesso anzi la maggior parte delle volte non lo fa. Puoi verificare la cosa provando ad accedere al file dal tuo browser aggiungendo /wp-config.php subito dopo il tuo dominio oppure ad un URL che potrebbe essere diverso se hai spostato il file.
Se hai inserito il file wp-config.php nella directory sopra la directory principale del tuo sito web, non dovresti essere in grado di vederlo. Nella maggior parte degli altri casi riceverai un messaggio di errore PHP quando provi comunque a visitare il file, quindi di solito non devi fare niente. Ma se vuoi proteggerlo correttamente, puoi farlo modificando la configurazione del tuo server web (Apache o nginx) per bloccarne l’accesso.
Infine, se stai usando Git in modo “pubblico”, sarebbe importante non archiviare il file wp-config.php nel tuo repository Git perchè potrebbe far trapelare informazioni critiche sul tuo sito, quindi sarebbe meglio aggiungerlo al tuo .git ignore e gestire manualmente i file in ogni ambiente.
Chiavi salt
Cosa sono le chiavi salt?
La sezione chiavi salt è una delle parti più misteriose di wp-config. Questo insieme di costanti dall’aspetto strano serve e viene usata per la crittografia di cose come cookie e nonce. Senza entrare troppo nel dettaglio, diciamo che aggiungono un ulteriore livello di casualità che rende le cose più difficili da decifrare se non le conosci.
Perché “ruotare” le chiavi salt?
Sempre per maggiore sicurezza, per esempio dovresti cambiare le chiavi salt se il sito è stato violato, poiché non puoi garantire che le chiavi salt siano ancora segrete. Ma potrebbe essere buona idea cambiarle regolarmente, come con le password, solo per essere sicuro che nessuno sappia cosa sono.
Problema con le chiavi salt
Cambiare le chiavi salt non è proprio indolore. Chiunque abbia un set di cookie lo perderà, di conseguenza chiunque abbia effettuato l’accesso verrà disconnesso e chiunque abbia un carrello WooCommerce se lo vedrà svuotato.
Come cambiare le chiavi salt
Vediamo come:
- Aggiungi manualmente le chiavi utilizzando un generatore: puoi utilizzare il generatore di wordpress.org per ottenere il codice di cui hai bisogno. Basta refreshare la pagina copiarlo e incollarlo nel file
wp-configfile al posto dei vecchi valori. - Puoi usare un plug-in, in realtà molti plug-in di sicurezza hanno questa funzione. Oppure un plugin dedicato tipo Salt Shaker che automatizza questo processo al posto tuo.
- Usa WP-CLI. Ha il comando
wp config shuffle-saltsper fare questa operazione in pochi secondi.
Spostare e nascondere cose
Qualcuno potrebbe obiettare, soprattutto se esistono degli addetti alla sicurezza i quali ti diranno che una “sicurezza per oscurità” non è affatto sicurezza, ma a molti piace ancora nascondere le proprie cose su WordPress per aumentare le difficoltà agli hackers.
Il file wp-config file offre una serie di opzioni per farlo e le tratteremo nelle sezioni successive sullo spostamento di oggetti e sulla disattivazione della modifica dei file.
Disabilitazione degli editor di file
WordPress ha una pratica funzionalità di editor che consente di modificare file in temi e plugin dall’interno della dashboard di amministrazione. La modifica di wp-config consente di disattivare questo editor di file! Per la massima tranquillità si può disabilitare.
Questo è in effetti un argomento di sicurezza cioè se qualcuno ha l’accesso come amministratore al tuo sito, che tra l’altro è necessario per utilizzare questo editor, può ad esempio caricare un plug-in e fare comunque quello che vuole. Disabilitare questo editor ovviamente da agli hacker meno potere.
Tuttavia il vero motivo per farlo è impedire alle persone che sono effettivamente autorizzate come amministratori di usarli. Se sei un’agenzia, potresti valutare utile non far modificare ai tuoi clienti tutti i file dei loro temi.
Utilizzando questa riga nel file wp-config:
define( 'DISALLOW_FILE_EDIT', true );Puoi attivare il blocco dell’editor.
Disabilitazione degli aggiornamenti automatici
Gli aggiornamenti vanno sempre fatti e questo è un assioma e l’inserimento degli aggiornamenti automatici di WordPress ha avuto un impatto netto positivo sull’ecosistema di WordPress, ma non tutti vogliono che il proprio software si prenda cura di se stesso ed anch’io penso che sia meglio avere il controllo su questa cosa.
E wp-config te lo consente, infatti ti dà il controllo sul processo di aggiornamento automatico con un semplice insieme di costanti autoesplicative che puoi impostare:
# Disable all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );
# Enable all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );
# Enable core updates for minor releases (default):
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Esiste anche un controllo più estremo:
define( 'DISALLOW_FILE_MODS', true );ma attenzione, questo impedisce a WordPress di scrivere qualsiasi cosa sul disco in relazione a core, temi, plug-in o traduzioni e disabilita le notifiche e-mail su aggiornamenti minori. In pratica sarebbe come un’imposizione tipo “non fare nulla a meno che tu non sappia esattamente cosa stai facendo”.
Forse è un po’ troppo estremo e allora leggermente meno estremo è usare AUTOMATIC_UPDATER_DISABLED. che ti consente di installare plugin e temi, ma non li aggiornerà e nemmeno aggiornerà il software principale, ma disabilita anche gli aggiornamenti di traduzione.
Esiste una guida dettagliata per tutto questo su wordpress.org, comprese alcune altre opzioni come l’utilizzo di filtri per un controllo più dettagliato.
Infine, c’è da notare che, se il tuo sito è ha un controllo di versione .git , è probabile che già WordPress abbia comunque disabilitato gli aggiornamenti per tuo conto. Ad esempio, la presenza di una directory .git nella radice del sito (o di vari altri file in luoghi diversi) disabiliterà gli aggiornamenti automatici senza che sia necessario aggiungere nulla a wp-config.
Configurazione HTTPS
La configurazione di HTTPS spesso era abbastanza impegnativa, ma con l’avvento di certificati di sicurezza gratuiti e affidabili come LetsEncrypt e Cloudflare, molti host lo configureranno per te con un paio di clic.
La costante FORCE_SSL_ADMIN dice a WordPress di utilizzare sempre SSL per le pagine di accesso e la dashboard di WordPress in modo da garantire che credenziali e cookie sicuri non possano essere inviati non crittografati.
Impedire le richieste HTTP esterne
Sempre a scopo di sicurezza è possibile bloccare le richieste HTTP esterne per impedire a WordPress di contattare altri siti per fare cose tipo effettuare chiamate API o scaricare aggiornamenti.
In generale va consentito perchè consente di ottenere aggiornamenti, installare plug-in e temi altrimenti molti plug-in si interrompono se disattivi le richieste HTTP.
Però, c’è sempre un però, il core di WordPress e molti plugin e temi inviano “telemetria” e/o “dati di utilizzo” ai loro server centrali. Da una parte è cosa positiva per il fatto che aiuta gli sviluppatori di plugin e temi a sapere chi sta usando il loro software e come, ma nel caso tu abbia un sito che contiene dati particolarmente sensibili, potresti voler disabilitare questa cosa e si può fare con:
define( 'WP_HTTP_BLOCK_EXTERNAL', true );Manualmente, si può gestire da soli un elenco di host autorizzati che possono essere contattati, ad esempio così:
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );L’elenco degli host accessibili è un elenco separato da virgole e sono consentiti sottodomini con caratteri jolly. Si potrebbe persino monitorare quali host vengono contattati utilizzando il plug-in Log HTTP Requests .
Spostare cose
Non tutte le installazioni di WordPress sono uguali. Ad alcuni host o framework piace spostare le directory per motivi di sicurezza o per mantenere il codice e le risorse specifici del sito separati dal core di WordPress.
Modifica del prefisso del database
Per impostazione predefinita WordPress utilizza il prefisso dei nomi delle tabelle del database wp_ . Questo prefisso viene aggiunto a tutti i nomi delle tabelle del database e viene utilizzato anche in altri posti, ad esempio l’opzione <prefix>user_roles nella tabella delle opzioni e le meta voci dell’utente <prefix>capabilities.
Gli hacker o gli aggressori potrebbero utilizzare il prefisso predefinito in un attacco, cercando di scoprire o modificare le tabelle del database. Quindi c’è una linea di pensiero che consiglia di cambiarlo dall’impostazione predefinita.
L’opzione di wp_config $table_prefix ti consente di farlo e una “best pratice” è di impostarlo con una stringa breve ma casuale ed un suffisso con trattino basso, tipo ad esempio:
$table_prefix = 'xyH7aq_';Spostamento delle tabelle User e Usermeta
Un’altra operazione di sicurezza che può essere fatta è quella di cambiare completamente i nomi delle tabelle user e usermeta.
Un ottimo scopo per farlo è quello di prevenire un attacco SQL-injection che potrebbe tentare un comando SQL tipo “SELECT * FROM wp_usermeta;” allo scopo di prelevare in modo fraudolento i dati dei vostri utenti.
Quello che serve per fare questa operazione sono le costanti CUSTOM_USER_TABLE e CUSTOM_USER_META_TABLE;
define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' );
define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );Prima di fare questa operazione però, ci sono avvisi che vale la pena conoscere ed è meglio controllare i documenti ufficiali. E’ sicuramente meglio farlo quando si installa un nuovo sito, piuttosto che modificarlo in seguito.
Spostare le directory Content, Uploads, e Plugins
È anche possibile spostare l’intera directory wp-content, la directory uploads e le directory themes e plugins. Questa per altro è una operazione che viene fatta anche da molti plugin di sicurezza, ma ci sono delle cose da tener presente:
- In alcuni di questi casi è necessario reimpostare l’URL e la directory
- È necessario fare attenzione a utilizzare percorsi completi o percorsi relativi a seconda dei casi.
- Nessuna di queste impostazioni dovrebbe avere una barra finale
Fare molta attenzione e consultare prima la documentazione ufficiale approfonditamente è la cosa migliore da fare in questo caso.
Avendo sempre ben presente che un plug-in o un tema mal codificato potrebbe non funzionare se fai questa modifica soprattutto quelli “custom”.
Se sei uno sviluppatore di plugin o temi, è importante ricordare che questi percorsi possono cambiare di conseguenza ti dovresti accertare di scrivere codice che usa i i percorsi di directory o URL non codificati in modo rigido. ma dinamico e relativo, e seguendo le direttive di WordPress per gli sviluppatori ci sono delle funzioni molto utili da poter usare:
wp_upload_dirplugins_urlplugin_dir_urlplugin_dir_pathget_stylesheet_directoryget_stylesheet_directory_uriget_template_directory– (NB: questa funzione per un child theme, restituisce il main theme cioè il tema principale)get_template_directory_uri
oltre a spostare i file all’interno dell’installazione di WordPress, è anche possibile voler spostare la posizione di wp-admin o addirittura cambiare la posizione del tuo sito. E wp-config.php può aiutare anche in questo caso.
Impostazioni relative al contenuto
WordPress è principalmente un sistema di gestione dei contenuti per cui ci si aspetterebbe che siano presenti delle costanti da poter utilizzare in wp-config.php per controllare le opzioni del contenuto. Vediamo cosa è possibile fare:
Modificare gli URL del sito e del dashboard
Questa operazione, forse, potrebbe generare un po’ di confusione, quindi meglio avere tutto chiaro.
Per impostare l’URL del tuo sito devi utilizzare la costante WP_HOME, non la costante WP_SITEURL la quale, a dispetto del nome, NON cambia l’URL del tuo sito.
Infatti, secondo la descrizione ufficiale di WP_SITEURL indica “l’indirizzo in cui risiedono i file core di WordPress”. Ma anche questo è fonte di confusione perché è un URL, non una directory.
Impostare WP_HOME e WP_SITEURL sovrascrive le voci home e siteurl nella tabella del database wp_options. Per esempio:
// NOTE: These must not have trailing slashes
define( 'WP_HOME', 'https://mywebsite.com' );
define( 'WP_SITEURL', 'https://mywebsite.com/wordpress` );È possibile utilizzare queste costanti dopo aver spostato un sito in un nuovo URL, per rendere operativo il sito mentre si corregge correttamente il database.
L’impostazione WP_SITEURL può essere utilizzata anche quando hai spostato i file principali di WordPress in una directory diversa.
L’uso di questi impedisce anche l’esecuzione di una o due query del database per ottenere i valori dalla tabella delle opzioni, quindi potrebbe avere un aumento marginale delle prestazioni. Tuttavia, se stai eseguendo la memorizzazione nella cache degli oggetti, il guadagno è probabilmente trascurabile.
C’è qualche dettaglio in più nei documenti ufficiali e persino un articolo di supporto completo sulla modifica dell’URL del sito. Inoltre, quell’articolo include l’oscura costante RELOCATE di wp-config.php di cui poco si sente parlare.
Impostazioni post
Trattando i post è possibile avere alcune impostazioni diverse da modificare, tipo la gestione delle revisioni dei post o della funzione di salvataggio automatico.
Revisioni post
Il comportamento predefinito di WordPress è quello di salvare tutte le revisioni apportate ai post e alle pagine, questo ci da Il vantaggio di una facilità di ripristino delle versioni precedenti. C’è però uno svantaggio, cioè che tutte queste revisioni occupano spazio nel database e possono influire sulle prestazioni del sito rallentando le query del database.
È possibile disabilitare completamente le revisioni dei post modificando il valore WP_POST_REVISIONS nel tuo file wp-config.php. Il valore predefinito è true. Per disattivare le revisioni puoi invece impostarlo su false:
define( 'WP_POST_REVISIONS', false );Alcuni host, per i loro scopi, non per i tuoi, disabilitano le revisioni dei post per impostazione predefinita a livello di server e non puoi abilitare le revisioni tramite wp-config perchè questo verrà sovrascritto. Quindi quando utilizzi un hosting WordPress gestito cerca di capire prima come agiscono e se permettono operazioni altrimenti sarai sempre limitato in questo. Personalmente consiglio wpmanage.it che lascia la piena libertà di gestione in questo, al contrario dei, pur blasonati, WP Engine e Kinsta, che limitano troppo le operazioni degli sviluppatori.
Se sei preoccupato per le revisioni dei post che rallentano le query del database, piuttosto che disabilitare forse è meglio limitare il numero di revisioni memorizzate da WordPress. Si può fare con la costante WP_POST_REVISIONS, che puoi impostare sul numero massimo di revisioni che vuoi mantenere, ad esempio:
define( 'WP_POST_REVISIONS', 5 );Modifica dell’intervallo di salvataggio automatico
E’ possibile anche ridurre la frequenza di attivazione del salvataggio automatico. L’impostazione predefinita è ogni 60 secondi, ma si può cambiare a piacere.
È importante tenere a mente quanto tempo impiega un salvataggio automatico. Meglio non farli accadere troppo frequentemente, quindi non impostare questo valore, ad esempio, su un secondo. Non è molto probabile che i salvataggi automatici richiedano più del valore predefinito di 60 secondi, però puoi gestire a piacimento la cosa:
define( 'AUTOSAVE_INTERVAL', 120 ); // SecondsIn conclusione
La gestione accurata di wp-config ha un grosso potenziale che aspetta solo di essere sbloccato penso a installazioni multisito e debug, la regolazione dei limiti di memoria, i problemi CRON e gli environment types.
Ci sono senza dubbio altre cose guardando bene nella documentazione ufficiale, in attesa di essere scoperte. Hai trovato cose, hai suggerimenti per l’utilizzo wp-config ? Fammi sapere la tua nei commenti.
