--- title: "PHP" description: "PHP moderno e professionale: 8.4 e 8.5, tipizzazione, OPcache, modernizzazione del legacy e sicurezza del linguaggio. Vent'anni di backend PHP in produzione. - PHP - Pagina 1 di 4" canonical: "https://www.mauriziofonte.it/blog/cat/php.html" author: "Maurizio Fonte" --- Categoria # PHP Pagina 1 di 4 ## **PHP**: il linguaggio che regge una fetta enorme del web, usato come si deve Con la 8.4 PHP è un linguaggio tipizzato, veloce e con un ecosistema ingegneristicamente maturo, ben lontano dall'idea di "linguaggio di WordPress", e la 8.5 continua a spingerlo in avanti. Lo uso da oltre vent'anni, ho attraversato ogni major dalla 4.x alla 8.x, e in questa categoria porto il criterio con cui si scrive PHP destinato a restare in produzione per anni. Molti articoli parlano della **modernità che conta davvero**. Enums, property hooks, lazy objects, fibers, tipizzazione stretta e OPcache cambiano il modo di modellare un dominio e di reggere il carico. Scrivo di come si usano per rendere il codice più leggibile e più veloce, e di quando una feature nuova è solo zucchero sintattico che non vale il rischio di adottarla. Altri affrontano la **realtà del codice legacy**. Gran parte del PHP che gira nelle aziende è una base 5.x o 7.x che qualcuno deve tenere viva, mettere in sicurezza e portare avanti senza fermare il servizio. Qui l'esperienza pesa più della teoria, dal porting delle vecchie funzioni deprecate alla gestione dei cambi di comportamento silenziosi fra una versione e l'altra. Poi la **sicurezza come parte del linguaggio**, pensata dal primo giorno: crittografia fatta con libsodium, sessioni difese da fixation e hijacking, upload validati in profondità, JWT implementati senza le trappole classiche. E sullo sfondo il capitolo che sta cambiando il mestiere: PHP nell'era dell'AI, dal debugging assistito alla validazione dell'output dei modelli. Se hai un progetto PHP da modernizzare o un backend da irrobustire, guarda come lavoro sui [progetti PHP senior](https://www.mauriziofonte.it/programmatore-php.html) oppure [scrivimi per una consulenza mirata](https://www.mauriziofonte.it/pages/contattami). > Quasi mai il problema è il linguaggio. Conta come lo usi, in che contesto, e se chi lo scrive sa cosa sta facendo. 1[2](https://www.mauriziofonte.it/blog/cat/php.md?page=2)[3](https://www.mauriziofonte.it/blog/cat/php.md?page=3)[4](https://www.mauriziofonte.it/blog/cat/php.md?page=4) [PHP](https://www.mauriziofonte.it/blog/cat/php.html) [Sicurezza Applicazioni](https://www.mauriziofonte.it/blog/cat/sicurezza-applicazioni.html) ## [Come funziona la use-after-free di PHP2Shell nelle CVE-2026-109618 e CVE-2026-109619](https://www.mauriziofonte.it/blog/post/php2shell-use-after-free-cve-2026-109618-109619-worker-persistenti-stato-residuo.html) 22/10/2026 ![Come funziona la use-after-free di PHP2Shell nelle CVE-2026-109618 e CVE-2026-109619](https://www.mauriziofonte.it/image/006160200-php2shell-use-after-free-cve-2026-109618-109619-worker-persistenti-stato-residuo.jpg) Le due vulnerabilità di PHP2Shell non nascono da una funzione scritta male, ma da un'assunzione sbagliata che attraversava l'intero motore: che si potesse interrompere una richiesta in qualunque momento e ritrovare, dopo, uno stato coerente. Capire perché quell'assunzione non reggeva spiega anche la cosa che più disorienta chi legge gli avvisi, cioè perché nessuna delle contromisure di configurazione proposte è dichiarata sufficiente. [Continua a leggere](https://www.mauriziofonte.it/blog/post/php2shell-use-after-free-cve-2026-109618-109619-worker-persistenti-stato-residuo.html) Ultima modifica: Giovedì 22 Ottobre 2026, alle 08:31 [PHP](https://www.mauriziofonte.it/blog/cat/php.html) [Linux & Server](https://www.mauriziofonte.it/blog/cat/linux.html) ## [La scoperta di PHP2Shell e cosa fare sulle CVE-2026-109618 e CVE-2026-109619](https://www.mauriziofonte.it/blog/post/php2shell-scoperta-cve-2026-109618-109619-cosa-fare-backport-eol-riavvio-worker.html) 21/10/2026 ![La scoperta di PHP2Shell e cosa fare sulle CVE-2026-109618 e CVE-2026-109619](https://www.mauriziofonte.it/image/006150200-php2shell-scoperta-cve-2026-109618-109619-cosa-fare-backport-eol-riavvio-worker.jpg) Le due vulnerabilità che il mondo della sicurezza ha chiamato PHP2Shell sono state segnalate al progetto PHP in agosto, corrette in ottobre e pubblicate un giorno prima del previsto perché i dettagli erano trapelati. Portano a esecuzione di codice remoto senza autenticazione e riguardano ogni server che serve pagine PHP. La storia di come sono arrivate fin qui spiega anche perché il controllo che quasi tutti fanno, cioè guardare il numero di versione, qui non risponde. [Continua a leggere](https://www.mauriziofonte.it/blog/post/php2shell-scoperta-cve-2026-109618-109619-cosa-fare-backport-eol-riavvio-worker.html) Ultima modifica: Mercoledì 21 Ottobre 2026, alle 08:19 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [PHP](https://www.mauriziofonte.it/blog/cat/php.html) ## [Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso](https://www.mauriziofonte.it/blog/post/scadenze-eol-php-2026-piano-migrazione-parte-adesso.html) 30/09/2026 ![Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso](https://www.mauriziofonte.it/image/005410200-scadenze-eol-php-2026-piano-migrazione-parte-adesso.jpg) Le scadenze EOL di PHP non sono un dettaglio da sysadmin: sono una leva di rischio per chi resta indietro. Lo stato reale nel 2026, con le date dal dossier: 8.3 già in security-only, 8.4 in supporto attivo fino a fine anno, 8.2 fuori dalla sicurezza a fine 2026. Il piano di migrazione da avviare adesso per chi è su 8.2 o 8.3: checklist, deprecazioni da gestire, test, e perché aspettare l'ultimo trimestre è la scelta più costosa. [Continua a leggere](https://www.mauriziofonte.it/blog/post/scadenze-eol-php-2026-piano-migrazione-parte-adesso.html) Ultima modifica: Mercoledì 30 Settembre 2026, alle 07:49 [PHP](https://www.mauriziofonte.it/blog/cat/php.html) [Code Quality](https://www.mauriziofonte.it/blog/cat/code-quality.html) ## [Il pipe operator di PHP 8.5: leggibilità reale o zucchero sintattico?](https://www.mauriziofonte.it/blog/post/php-8-5-pipe-operator-leggibilita-reale-zucchero-sintattico.html) 28/09/2026 ![Il pipe operator di PHP 8.5: leggibilità reale o zucchero sintattico?](https://www.mauriziofonte.it/image/005390200-php-8-5-pipe-operator-leggibilita-reale-zucchero-sintattico.jpg) PHP 8.5 introduce il pipe operator, e la domanda onesta è se migliori davvero la leggibilità o sia solo zucchero sintattico. Analisi pratica: cosa risolve davvero, ovvero le chain leggibili da sinistra a destra; i limiti reali con i callable a più parametri e i built-in da wrappare; e gli esempi da codice gestionale dove il pipe rende il flusso chiaro contro quelli dove aggiunge solo una sintassi nuova. Onesto sui tradeoff, non entusiasta per default. [Continua a leggere](https://www.mauriziofonte.it/blog/post/php-8-5-pipe-operator-leggibilita-reale-zucchero-sintattico.html) Ultima modifica: Lunedì 28 Settembre 2026, alle 09:46 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [PHP](https://www.mauriziofonte.it/blog/cat/php.html) ## [Migrare da PHP 7.4 a 8.3: checklist per applicazioni legacy in produzione](https://www.mauriziofonte.it/blog/post/migrare-php-74-php-83-checklist-applicazioni-legacy-produzione.html) 31/08/2026 ![Migrare da PHP 7.4 a 8.3: checklist per applicazioni legacy in produzione](https://www.mauriziofonte.it/image/005190200-migrare-php-74-php-83-checklist-applicazioni-legacy-produzione.jpg) Migrare un'applicazione legacy da PHP 7.4 a 8.3 è un progetto di rischio gestito, non un aggiornamento al volo. Checklist concreta: i breaking changes che mordono davvero, le deprecazioni da intercettare prima del deploy, la strategia incrementale per non fermare la produzione e la suite di test che fa da rete. Con le date EOL aggiornate, perché restare su 7.4 nel 2026 non è più un'opzione di sicurezza. [Continua a leggere](https://www.mauriziofonte.it/blog/post/migrare-php-74-php-83-checklist-applicazioni-legacy-produzione.html) Ultima modifica: Lunedì 31 Agosto 2026, alle 07:56 [Laravel](https://www.mauriziofonte.it/blog/cat/laravel.html) [PHP](https://www.mauriziofonte.it/blog/cat/php.html) ## [Laravel: la scelta migliore per le applicazioni Web-based](https://www.mauriziofonte.it/blog/post/laravel-la-scelta-migliore-per-le-applicazioni-web-based.html) 05/05/2026 ![Laravel: la scelta migliore per le applicazioni Web-based](https://www.mauriziofonte.it/image/000650200-laravel-la-scelta-migliore-per-le-applicazioni-web-based.jpg) "Laravel è la scelta migliore" è il tipo di affermazione di cui diffido, perché nessuno strumento è il migliore per tutto. Eppure, quando un cliente mi chiede su cosa costruire una nuova applicazione web aziendale, nella maggioranza dei casi la mia risposta è Laravel, e non per moda: è una scelta di ingegneria, fondata su velocità di sviluppo, manutenibilità ed ecosistema. Vediamo perché lo scelgo, cosa lo distingue nel 2026, e quando invece consiglio altro. [Continua a leggere](https://www.mauriziofonte.it/blog/post/laravel-la-scelta-migliore-per-le-applicazioni-web-based.html) Ultima modifica: Lunedì 15 Giugno 2026, alle 18:01 [PHP](https://www.mauriziofonte.it/blog/cat/php.html) [Performance](https://www.mauriziofonte.it/blog/cat/performance.html) ## [PHP OPcache: configurazione ottimale per Laravel e Symfony in produzione](https://www.mauriziofonte.it/blog/post/php-opcache-configurazione-ottimale-laravel-symfony-produzione.html) 24/03/2026 ![PHP OPcache: configurazione ottimale per Laravel e Symfony in produzione](https://www.mauriziofonte.it/image/002720200-php-opcache-configurazione-ottimale-laravel-symfony-produzione.jpg) OPcache è la singola ottimizzazione PHP con il maggiore impatto sulle prestazioni: su una applicazione Laravel media, la configurazione corretta riduce il tempo di risposta del 40-60%. Ma la configurazione di default non è ottimale per la produzione. Vi mostro i parametri che cambio sempre e perché. [Continua a leggere](https://www.mauriziofonte.it/blog/post/php-opcache-configurazione-ottimale-laravel-symfony-produzione.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [PHP](https://www.mauriziofonte.it/blog/cat/php.html) ## [Migrare un gestionale PHP 5.6 a PHP 8.4 senza riscriverlo: il caso reale di un e-commerce B2B con 12 anni di codice procedurale](https://www.mauriziofonte.it/blog/post/migrare-php-56-php-8-guida-completa-applicazioni-legacy-produzione.html) 11/03/2026 ![Migrare un gestionale PHP 5.6 a PHP 8.4 senza riscriverlo: il caso reale di un e-commerce B2B con 12 anni di codice procedurale](https://www.mauriziofonte.it/image/002320200-migrare-php-56-php-8-guida-completa-applicazioni-legacy-produzione.jpg) Un e-commerce B2B con 47.000 righe di PHP 5.6 procedurale, 340 chiamate mysql_connect(), un hosting che aveva annunciato la rimozione di PHP 5.6 entro 60 giorni, e un titolare che non poteva permettersi downtime. In quattro settimane l'ho migrato a PHP 8.4 senza riscrivere l'applicazione: ecco il metodo, gli strumenti, le breaking changes reali e le decisioni che hanno fatto la differenza. [Continua a leggere](https://www.mauriziofonte.it/blog/post/migrare-php-56-php-8-guida-completa-applicazioni-legacy-produzione.html) Ultima modifica: Giovedì 25 Giugno 2026, alle 13:40 [PHP](https://www.mauriziofonte.it/blog/cat/php.html) [Code Quality](https://www.mauriziofonte.it/blog/cat/code-quality.html) ## [PHP e memory management: come evitare i memory leak nelle applicazioni di lunga esecuzione](https://www.mauriziofonte.it/blog/post/php-memory-management-memory-leak-applicazioni-lunga-esecuzione.html) 10/03/2026 ![PHP e memory management: come evitare i memory leak nelle applicazioni di lunga esecuzione](https://www.mauriziofonte.it/image/002710200-php-memory-management-memory-leak-applicazioni-lunga-esecuzione.jpg) I worker Laravel Horizon di un cliente consumavano 500MB di RAM dopo 6 ore di esecuzione e venivano killati automaticamente. Il memory leak non era ovvio: un event listener registrato globalmente teneva riferimenti a ogni job processato. Vi mostro il processo di diagnosi con Blackfire e le strategie di correzione. [Continua a leggere](https://www.mauriziofonte.it/blog/post/php-memory-management-memory-leak-applicazioni-lunga-esecuzione.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [Sicurezza Applicazioni](https://www.mauriziofonte.it/blog/cat/sicurezza-applicazioni.html) [PHP](https://www.mauriziofonte.it/blog/cat/php.html) ## [Gestione delle sessioni sicure in PHP: session fixation, hijacking e best practice](https://www.mauriziofonte.it/blog/post/gestione-sessioni-sicure-php-fixation-hijacking-best-practice.html) 02/03/2026 ![Gestione delle sessioni sicure in PHP: session fixation, hijacking e best practice](https://www.mauriziofonte.it/image/003410200-gestione-sessioni-sicure-php-fixation-hijacking-best-practice.jpg) La sessione PHP è uno dei vettori di attacco più sottovalutati. In un assessment su un portale bancario PHP, ho dimostrato session fixation in meno di 10 minuti sfruttando un PHPSESSID passato in query string. Vi mostro la configurazione php.ini che elimina la classe di vulnerabilità e i pattern di sessione sicura per Laravel. [Continua a leggere](https://www.mauriziofonte.it/blog/post/gestione-sessioni-sicure-php-fixation-hijacking-best-practice.html) Ultima modifica: Lunedì 2 Marzo 2026, alle 10:08 1[2](https://www.mauriziofonte.it/blog/cat/php.md?page=2)[3](https://www.mauriziofonte.it/blog/cat/php.md?page=3)[4](https://www.mauriziofonte.it/blog/cat/php.md?page=4) ## Strumenti PHP utili Tool gratuiti che uso e che possono servirti mentre lavori su PHP: [Audit del composer.lock](https://www.mauriziofonte.it/strumenti/audit-composer), [Regex tester](https://www.mauriziofonte.it/strumenti/regex-tester), [JSON formatter](https://www.mauriziofonte.it/strumenti/json-formatter), [Generatore UUID](https://www.mauriziofonte.it/strumenti/generatore-uuid). --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about