Stai iniziando a creare un sito WordPress e vuoi saperne di più su questo mondo? In questa lista vedremo 10 errori gravi da non fare con un sito WordPress. Si tratta di modifiche, configurazioni ma anche dimenticanze che, nella migliore delle ipotesi, possono mandare offline il sito, o, nella peggiore, possono mettere a serio rischio la sicurezza di WordPress.
Indice
Lasciare il log degli errori attivo
Quando si attiva la modalità di debug su un sito WordPress, si può decidere anche di attivare il log degli errori. Così facendo si permette la creazione di un file, debug.log, in cui vengono memorizzati tutti gli errori rilevati in automatico.
Fin qui è tutto normale, il problema però si presenta quando si lascia la registrazione degli errori attiva per mesi, o per anni.
Perché non bisogna lasciare il log degli errori attivo
Lasciare il debug attivo ad oltranza fa sì che il file continui a crescere senza controllo e il primo problema in cui si può incorrere è una saturazione dello spazio a disposizione sul proprio account hosting.
Inoltre, non bisogna dimenticare che ogni volta che viene registrato un errore ci sono operazioni di scrittura sul disco che possono far raggiungere il limite di risorse e causare rallentamenti in tutto il sito.
Come evitare il problema
È bene usare la modalità di debug solo quando è necessario e poi disattivarla. Se l’obiettivo è quello di trovare un errore isolato basta disattivare poi il file di log degli errori.
Per farlo apriamo il file wp-config.php e modifichiamo il codice in modo da impostare queste due direttive su false:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );In questo modo si disattiva la modalità di debug e la creazione del file di log.
Se abbiamo la necessità di tenerlo attivo per più tempo, la cosa migliore da fare è eliminarlo periodicamente in modo da evitare il problema di spazio.
Quando invece la scrittura del log degli errori causa rallentamenti nel sito, è il caso anche di intervenire per risolvere gli errori, non solo per bloccare la creazione del file di log.
Non monitorare l’uso delle risorse
Negli ambienti di hosting condivisi, ma anche se il sito è ospitato su una soluzione dedicata, c’è sempre un limite massimo di risorse a disposizione. Per la precisione, le risorse hardware dell’hosting, anche quando limitate in modo virtuale, riguardano principalmente:
- CPU
- RAM
- numero di processi.
Ci sono poi eventuali altri limiti come gli inode ossia il numero di file massimi che un account può ospitare. Questi limiti sono a discrezione dei provider, ad esempio su SupportHost non è previsto un limite massimo di inode.
Controllare l’utilizzo delle risorse ci aiuta a capire se il piano hosting che abbiamo scelto è sottodimensionato rispetto alle esigenze del sito. Inoltre in alcuni casi picchi nell’uso delle risorse possono rappresentare un errore risolvibile.
Perché è importante conoscere i limiti di risorse
Consultare i grafici dell’uso delle risorse del proprio piano hosting è utile per identificare possibili problemi. Ad esempio un conflitto tra plugin dopo un aggiornamento del core di WordPress può andare a saturare tutta la CPU oppure il problema può essere dovuto a operazioni ricorsive sul database.
Come identificare i problemi
Per prima cosa è utile andare a verificare l’utilizzo delle risorse. In base al tuo provider di hosting, potresti avere accesso diretto all’uso in tempo reale.
Ad esempio su SupportHost puoi vedere i consumi in tempo reale da cPanel. Ti basta aprire lo strumento Resource Usage da cPanel e potrai vedere i grafici e l’eventuale superamento delle risorse.
A questo punto se pensi che la causa del problema possa essere un plugin, puoi usare Query Monitor per capire se c’è un plugin che sta utilizzando più risorse del dovuto.
Impostare un limite di memoria troppo basso
Su WordPress possiamo impostare un limite di memoria massimo per gli script PHP, modificare questo limite può compromettere il funzionamento del sito perché ad esempio i plugin possono smettere di funzionare.
Come modificare il limite di memoria
Per verificare rapidamente il limite di memoria attuale, possiamo accedere dalla dashboard di WordPress a Strumenti > Salute del sito, qui nella tab “Informazioni” alla voce “Server” potremo vedere qual è il limite di memoria PHP attuale.
Per modificare il limite attuale possiamo agire tramite lo strumento MultiPHP INI Editor di cPanel oppure aggiungendo nel file wp-config.php, la seguente riga:
define('WP_MEMORY_LIMIT', '256M');Non limitare il traffico dei bot
Un altro problema che può portare al superamento delle risorse del piano è il traffico massimo da parte di bot e crawler. Il traffico eccessivo da parte dei bot soprattutto quando provoca picchi di traffico simultanei, può rallentare il sito o arrivare a mandare in down il sito stesso.
Come risolvere
Una volta identificato il traffico non desiderato dai bot, si può limitare questo traffico in modo selettivo in modo da distinguere il traffico umano da quello di crawler o bot per il web scraping. Ad esempio Cloudflare ha diversi strumenti che classificano i bot e riescono a bloccare il loro traffico in modo efficace.
Mostrare troppi post nelle pagine o nei feed
Dalle impostazioni di WordPress è possibile scegliere quanti post mostrare nei feed delle notizie e nelle pagine del blog. Usare un’impostazione scorretta può causare problemi sia nel caricamento delle pagine che portare a saturazione delle risorse quando ad esempio i bot scansionano le pagine.
Come risolvere
È bene impostare un numero limitato di post per pagina, ad esempio 10 o 12 per evitare errori. Per modificare questa impostazione basta accedere alla bacheca di WordPress e andare in Impostazioni > Lettura, qui vedremo due opzioni:
- Le pagine del blog visualizzano al massimo
- I feed visualizzano i più recenti.
Ci basta impostare il numero massimo di articoli ed elementi e cliccare su “Salva le modifiche”.
Non aggiornare i plugin
Aggiornare i plugin di WordPress non ci permette solo di accedere a nuove funzioni introdotte dagli sviluppatori, ma è fondamentale soprattutto per la sicurezza. Quando viene scoperta una falla in un plugin e viene risulta con una patch di sicurezza, è importante aggiornare il plugin in modo da non essere più esposti.
La maggior parte delle vulnerabilità su WordPress dipende proprio dai plugin.
Come risolvere
Aggiornare regolarmente il core, i temi e i plugin di WordPress è uno dei passi fondamentali per avere un sito più sicuro.
Non monitorare il ruolo predefinito per i nuovi utenti
La gestione dei ruoli su un sito WordPress è molto importante per la sicurezza. Di default WordPress ha già diversi ruoli utente, ognuno con permessi specifici in modo da poter assegnare agli utenti un ruolo e mantenere quello che viene definito Least Privilege Principle che consiste cioè nell’assegnare l’accesso minimo richiesto.
Per impostazione predefinita, il ruolo di base dei nuovi utenti è impostato su “Sottoscrittore“, cioè il ruolo con permessi minimi. Ci sono casi però in cui o per una impostazione sbagliata o in seguito a un attacco, il ruolo di default può essere modificato in “Amministratore”.
Come risolvere
Se il ruolo predefinito è stato impostato erroneamente su “Amministratore”, ci basta andare a modificare le impostazioni. Dalla bacheca di WordPress andiamo su “Impostazioni > Generali” e modifichiamo la voce “Ruolo predefinito nuovi utenti” impostandola su “Sottoscrittore”. Inoltre vale anche la pena verificare che non siano consentite le nuove registrazioni se non vogliamo che chiunque possa registrarsi al nostro sito.
Nei casi in cui ci sia stato un attacco grazie al quale sono stati creati degli account Admin, bisogna identificare la vulnerabilità e risolverla, non basta eliminare semplicemente i nuovi utenti che sono stati creati.
Novità: con il passaggio a WordPress 7, una delle novità che è stata introdotta è la rimozione dei ruoli “Amministratore” ed “Editor” come ruoli predefiniti.
Lasciare esposto il file wp-config.php
Il file wp-config.php è uno dei file più importanti di WordPress e può mettere a rischio la sicurezza di tutto il sito. Infatti in questo file sono contenuti i dati che permettono a WordPress di comunicare con il database e quindi queste credenziali possono essere usate per accedere al database e creare utenti admin oppure inserire link di spam e così via.
Uno dei principali errori quando si esegue un backup è quello di creare una copia di backup del file wp-config.php modificandone l’estensione, ad esempio:
- wp-config.txt
- wp-config.bak
- wp-config.html.
Il problema è che così facendo stiamo esponendo il contenuto del file e quindi permettendo a utenti malintenzionati di accedere al file. In particolare se il file ha l’estensione .txt potrà essere letto direttamente nel browser, se ha estensione .bak potrà essere scaricato e se ha estensione .html potrà essere visualizzato con una richiesta curl.
Come risolvere
In questo caso per evitare il problema bisogna fare attenzione quando si creano i backup e non lasciarli sul server. La soluzione può essere scaricare immediatamente il file di backup ed eliminarlo o conservare temporaneamente un backup del file facendo attenzione a non modificare l’estensione.
Sbagliare a impostare la struttura dei permalink
WordPress ci permette di impostare una struttura di base per gli URL del sito web. Ad esempio ci permette automaticamente di aggiungere il nome della categoria prima dell’URL dell’articolo nel caso di un blog o anche per le pagine di prodotto.
Le modifiche ai permalink devono essere fatte sempre con cautela e in particolare bisogna anche fare attenzione ai caratteri speciali.
In questo esempio l’utilizzo di un’icona nella struttura dei permalink genera link rotti ed errori 404 per pagine non trovate.
Come risolvere
Controllare sempre che non ci siano errori dopo aver impostato la struttura dei permalink.
Se si vogliono fare cambiamenti a sito già pubblicato oltre ad analizzare bene la situazione, è bene impostare dei redirect 301 in modo che il vecchio link venga rimandato al link modificato.
In questo modo permetteremo sia agli utenti che hanno eventualmente salvato l’indirizzo, che ai motori di ricerca che possono averlo indicizzato, di raggiungere ugualmente la risorsa.
Non controllare il codice generato dall’IA
Oggi è allettante rivolgersi all’IA per aggiungere rapidamente nuove funzioni al nostro sito WordPress. Come ogni cosa, però, l’IA è solo uno strumento che può essere valido se affidato a mani esperti, ma che può nascondere diverse insidie se usato alla leggera.
In questo screen vediamo un esempio di uso senza ragionare, in cui è stato fatto un copia e incolla con tanto di richiesta da parte dell’IA.
Come risolvere
Questo esempio è un errore innocuo, ma anche se il codice generato dall’IA funziona, non è detto che non abbia delle vulnerabilità. Per evitare problemi è consigliabile farsi aiutare dall’IA solo quando si ha già esperienza di programmazione e di sicurezza, in modo da evitare anche errori “grossolani”.
Conclusioni
Abbiamo visto 10 errori che possono costare caro quando si vanno a fare modifiche su un sito WordPress. La maggior parte dei problemi esaminati riguarda la compromissione del funzionamento del sito per via di un consumo eccessivo di risorse, ma l’altra categoria di errori riguarda soprattutto la sicurezza.
Si ringrazia Michele Genito per aver ispirato questo post e fornito gli screenshot delle varie problematiche.
E tu, conoscevi già questi rischi? Ti è capitato di dover risolvere qualcuno di questi problemi? Lascia un commento per farcelo sapere.
Pronto a costruire il tuo sito WordPress?
Prova il nostro servizio gratuitamente per 14 giorni. Nessun impegno, nessuna carta di credito richiesta.
