Riparare errore 500 Internal Server Error su Wordpress installato su Aruba

Quando ho scritto questo articolo, il 25 giugno 2012, WordPress 3.4 era stato rilasciato due settimane prima e aveva attivato in molti siti italiani hostati su Aruba lo stesso pattern: dopo l'aggiornamento automatico del core, il sito mostrava una pagina bianca con scritto "500 Internal Server Error" e il pannello admin diventava inaccessibile. Le installazioni interessate erano sempre quelle hostate sull'offerta Aruba "Hosting Linux" condivisa, e il pattern era così ripetibile che era diventato una FAQ ufficiosa nei forum italiani di chi gestiva siti per piccole aziende, blogger, professionisti.

La soluzione che documentavo nell'articolo originale era una procedura veloce nel pannello di controllo Aruba: navigare in admin.aruba.it, accedere al pannello "Hosting Linux", cliccare sulla scheda "Strumenti ed Impostazioni", attivare la funzione "Riparazione Permissions". Funzionava nella maggior parte dei casi perché la causa concreta era proprio il reset di permessi che WordPress applicava ai file durante l'auto-update e che andava in conflitto con la configurazione standard di Aruba. Quattordici anni dopo, il pannello di Aruba è cambiato di forma più volte, WordPress è arrivato alle versioni 6.x, lo stack PHP minimo richiesto è salito a PHP 7.4 (e WordPress 7.0 di aprile 2026 droppa PHP 7.2/7.3 entirely), ma la procedura "Riparazione Permessi" esiste ancora come tool dedicato. Quello che è cambiato è il quadro più ampio: oggi quella procedura è la prima cosa da provare ma è solo uno dei sei punti di un workflow di diagnosi che applico quando un cliente mi chiama in emergenza con WordPress su Aruba che mostra errore 500.

Cos'è davvero un errore 500 e perché su Aruba si manifesta più spesso?

L'HTTP 500 Internal Server Error è una risposta server-side che indica un fallimento generico nell'esecuzione della richiesta. Il server ha capito la richiesta ma qualcosa è andato storto durante l'elaborazione e non è in grado di darti una risposta più specifica. Sotto WordPress, le sei cause concrete che fanno scattare un 500 sono in ordine di frequenza: conflitto plugin/tema (la più frequente), file .htaccess corrotto, esaurimento del PHP memory limit, versione PHP incompatibile, permessi file scorretti, corruzione dei file core di WordPress.

Su Aruba in particolare, il problema dei permessi era storicamente più frequente che su altri provider per due ragioni operative. Prima ragione: il filesystem condiviso degli hosting Aruba Linux applicava per default permessi 644 ai file caricati, ma WordPress in alcuni casi (specialmente durante auto-update via il proprio updater interno) applicava 755 ai file PHP, generando un mismatch che il PHP-FPM di Aruba interpretava come "execute non permesso" e restituiva 500. Seconda ragione: l'updater di WordPress fino alla versione 4.x scriveva file temporanei in directory che richiedevano permessi specifici, e su filesystem condivisi la propagazione dei permessi non era sempre atomica, lasciando alcuni file in stato inconsistente che generava il 500 fino a riparazione manuale.

Il pattern operativo è cambiato con le versioni più recenti di WordPress (5.x e 6.x) che hanno migliorato la gestione dei permessi durante gli update, ma sui siti Aruba con installazioni storiche o con plugin che fanno scrittura intensiva su filesystem (caching plugin, optimizer, security plugin che gestisce file di log) il problema può ancora manifestarsi. Inoltre, Aruba stesso ha pubblicato una knowledge base ufficiale sul tema "Hosting Linux e WordPress: come evitare l'errore 500" che riconosce il pattern e propone la soluzione preventiva via wp-config.php.

Come funziona oggi la Riparazione Permessi su Aruba?

Il tool esiste ancora nel pannello Aruba 2026, anche se l'interfaccia ha attraversato più redesign. Il percorso di accesso aggiornato è: login su admin.aruba.it con le credenziali del cliente, navigazione al "Pannello Hosting Linux" → "Gestione Hosting Linux" → "Strumenti ed Impostazioni" → "Riparazione Permissions". Il bottone confermativo lancia un job server-side che propaga ricorsivamente i permessi corretti su tutti i file e directory dell'archivio. Il tempo di esecuzione è proporzionale al numero di file: per un blog WordPress standard con qualche centinaio di articoli e migliaia di file media, va dai 2 ai 10 minuti.

La pratica operativa è: lancia la riparazione, attendi il completamento, ricarica il sito. Se il 500 era causato da permessi inconsistenti, il sito torna online immediatamente. Se invece il sito continua a mostrare 500, la causa è altra e il workflow di diagnosi continua sui punti successivi.

C'è una soluzione preventiva che Aruba stessa raccomanda nella sua KB e che applico sempre nei progetti che gestisco: aggiungere al file wp-config.php due righe che forzano i permessi corretti durante ogni update di WordPress.

define('FS_CHMOD_FILE', 0755);
define('FS_CHMOD_DIR', 0755);

Queste costanti istruiscono il WordPress filesystem API a scrivere file e directory con permessi 755 invece dei default che possono generare conflitti su Aruba. La modifica si applica una volta sola e protegge da future occorrenze del problema dopo update successivi. Su installazioni create via "Linux Applications Installer" di Aruba la modifica non è necessaria perché Aruba la pre-configura.

Quali sono gli altri cinque punti di diagnosi quando il 500 persiste?

Se la riparazione permessi non risolve, il workflow corretto continua su cinque punti, in ordine di costo crescente per l'amministratore.

Primo: rinominare il file .htaccess per testare se è la sua corruzione la causa. Via FTP (FileZilla, Cyberduck) o tramite il File Manager del pannello Aruba, accedi alla root dell'installazione e rinomina .htaccess in .htaccess_old. Ricarica il sito. Se torna online, il file era corrotto. Per ricreare un .htaccess pulito, basta entrare nel pannello WordPress in Impostazioni → Permalink e cliccare "Salva modifiche" senza cambiare nulla: WordPress rigenera automaticamente un .htaccess corretto. La causa più frequente di corruzione è un plugin che scrive direttive nel file e che ha un bug, o l'editor di codice integrato di un plugin di security che ha applicato regole malformate.

Secondo: aumentare il PHP memory limit. Se l'errore è dovuto a esaurimento memoria (sintomo: l'errore appare solo su certe pagine pesanti, su admin con molti plugin, o durante operazioni come backup o ottimizzazione database), aggiungere a wp-config.php la riga define('WP_MEMORY_LIMIT', '256M'); prima del commento "Happy publishing". Su Aruba, l'hosting condiviso ha un limite memoria dichiarato per piano: nei piani base il limite è tipicamente 128MB e non aumentabile dal cliente. Per siti che richiedono memoria maggiore, va valutato l'upgrade al piano superiore o il passaggio a hosting con risorse dedicate (vedi punto 6).

Terzo: disabilitare tutti i plugin per test di conflitto. Via FTP, rinominare la directory wp-content/plugins in wp-content/plugins_disabled. WordPress non troverà nessun plugin attivo e ripartirà. Se il sito torna online, la causa era un plugin. Per identificare quale, ripristina il nome originale della directory, poi entra nel pannello WordPress (che ora mostra "Plugin disattivato perché il file plugin manca") e riattiva i plugin uno alla volta finché il 500 si ripresenta. L'ultimo plugin attivato è il colpevole.

Quarto: switch a tema di default WordPress. Se i plugin non sono il problema, il tema attivo potrebbe esserlo. Via FTP, rinomina la directory del tema corrente in wp-content/themes/[nome-tema]_old. WordPress fa fallback automatico al tema di default più recente disponibile (Twenty Twenty-Four nel 2026, Twenty Twenty-Five se installato). Se il sito torna online, il problema è nel tema custom o premium che usavi.

Quinto: aggiornare la versione PHP del piano Aruba. Aruba permette di scegliere la versione PHP da una lista di versioni supportate, accessibile via "Hosting Linux → Servizi hosting → Informazioni sul Software → Scelta della versione PHP". Nel 2026 la lista include tipicamente da PHP 7.4 a PHP 8.3 (con PHP 8.4 in arrivo). Selezionare una versione più recente spesso risolve incompatibilità tra plugin/tema moderni e PHP datato. Attenzione che WordPress 7.0 (rilascio aprile 2026) ha alzato il minimo a PHP 7.4 strict, droppando 7.2/7.3, quindi se il piano Aruba era ancora su PHP 7.2 questo è da aggiornare prima del prossimo update WordPress automatico. Per la migrazione strutturata, la mia guida sul percorso di migrazione PHP da 7.4 a 8.3 con workflow LLM-assisted documenta il pattern operativo che applico nei progetti.

Sesto: leggere i log degli errori. Dopo i primi cinque punti, se il problema persiste, è il momento di guardare i log. Su Aruba: pannello → Strumenti e Impostazioni → Mostra log degli errori. Il messaggio caratteristico per il 500 è "End of script output before headers" oppure "PHP Fatal error: ..." con stack trace. Da quel messaggio si risale alla causa specifica e si interviene mirato.

In aggiunta al log lato Aruba, conviene attivare il logging WordPress nativo aggiungendo a wp-config.php queste tre costanti: define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true);, define('WP_DEBUG_DISPLAY', false);. La prima abilita il debug, la seconda lo scrive su file (wp-content/debug.log), la terza impedisce che il debug appaia in pagina (essenziale in produzione perché altrimenti espone informazioni sensibili al pubblico). Il log così configurato cattura warning e error PHP che il pannello Aruba potrebbe non sempre mostrare, e include il filename e la line number di ogni problema. Una volta risolto il 500, ricordarsi di mettere WP_DEBUG a false di nuovo per non lasciare il log attivo permanentemente. Se il debug log mostra un errore ricorrente del tipo "Allowed memory size of N bytes exhausted", sei nel caso del punto 2 (memory limit) e la soluzione è esattamente quella. Se mostra "Fatal error: Uncaught Error: Class 'X' not found in /path/to/plugin-Y", sei nel caso del punto 3 (plugin conflict) e devi disattivare il plugin Y. Se mostra errori di syntax o di funzioni deprecate, sei nel caso del punto 5 (PHP version). Il log fa il lavoro di triage al posto tuo.

Una nota operativa importante: durante la diagnosi non lavorare mai direttamente in produzione se il sito è critico per il business. La pratica corretta è clonare l'installazione WordPress in un ambiente di staging (cartella separata sul piano Aruba o un piano staging dedicato), riprodurre il problema lì, applicare le correzioni in staging, validare, e infine portare in produzione. Su Aruba la creazione di un ambiente staging via subdominio è gratuita ma richiede manualmente la duplicazione del database e dei file. Plugin come WP Staging o Duplicator automatizzano la procedura, ma sono il primo che disabilito quando il sito principale è in errore 500 perché il plugin di staging stesso può essere parte del problema.

Quando ha senso restare su Aruba e quando valutare alternative?

Aruba resta uno degli hosting italiani più diffusi nel 2026, e per progetti specifici (blog personali, siti vetrina di piccole attività, professionisti che vogliono dominio .it ufficiale) ha senso continuare a usarlo. Il pricing è competitivo, l'assistenza è in italiano, la conformità GDPR è gestita lato provider. Per workload più impegnativi o per progetti che richiedono controllo sull'infrastruttura, però, le limitazioni dell'hosting condiviso Aruba si fanno sentire: PHP memory limit non aumentabile sopra una certa soglia, accesso SSH limitato o non disponibile sui piani base, restrizioni su Cron, no possibilità di tuning a livello sistema operativo.

Per progetti che superano queste soglie, le alternative che valuto con i clienti sono tipicamente VPS unmanaged su Hetzner, Contabo o OVH, gestiti con disciplina sysadmin appropriata. Per esempio, il confronto benchmark fra Hetzner Cloud, Contabo e OVH per PMI che pubblicato l'anno scorso documenta esattamente i trade-off prezzo/prestazioni dei tre provider europei più diffusi nei progetti italiani. Per chi vuole strutturare un setup VPS con WordPress in modo professionale, il setup tipico prevede reverse proxy Traefik con HTTPS automatico, backup automatizzati su S3 e monitoring centralizzato. È un livello operativo diverso dall'hosting condiviso ma garantisce controllo, prestazioni e affidabilità che l'hosting condiviso non può raggiungere strutturalmente.

Le risorse autorevoli che continuo a consultare per WordPress troubleshooting sono il knowledge base ufficiale di Aruba sull'errore 500 con WordPress, la documentazione ufficiale WordPress sul debugging (con istruzioni per attivare WP_DEBUG in wp-config.php per log dettagliati) e le requisiti minimi ufficiali su wordpress.org/about/requirements/ per verificare la compatibilità tra versione WordPress e versione PHP del piano hosting.

Per chi gestisce un sito WordPress per la propria attività professionale o per una piccola azienda e si trova periodicamente con problemi di stabilità (errori 500 ricorrenti, performance degradate dopo update, plugin che vanno in conflitto, sicurezza dopo tentativi di intrusione), il mio profilo professionale include esperienze concrete di rescue, hardening e ottimizzazione di installazioni WordPress critiche su hosting condiviso, VPS unmanaged e server dedicati. La differenza tra un sito che genera grattacapi mensili e un sito stabile sta quasi sempre in cinque scelte iniziali: hosting dimensionato sul carico reale, plugin set scelto con disciplina (no plugin abbandonati, no overlap funzionale), backup automatizzati testati periodicamente, monitoring di uptime e performance, hardening di base contro la classe più diffusa di attacchi automatizzati. Sono scelte che fanno la differenza tra "sito che funziona quando ricordo di guardarlo" e "sito che gira da solo per anni con manutenzione minima". Se vuoi inquadrare il tuo setup WordPress in modo professionale prima che si manifesti la prossima emergenza 500, contattami direttamente per una valutazione iniziale.