L'helper once() in Laravel 12: memoizzazione per-request con WeakMap al posto di proprietà statiche e cache forzata
L'helper once(), introdotto in Laravel 11 (PR #49744, Nuno Maduro), usa internamente una WeakMap di PHP 8.0 per cachare il risultato di una closure per la durata della request. In metodi d'istanza la cache è per-oggetto, in metodi statici è per-classe, in contesto globale è per call-site. In Octane, FlushOnce esegue Once::flush() tra le request. Continua a leggere
Ultima modifica:
L'event discovery scansiona automaticamente i listener nella directory app/Listeners e li registra in base al type-hint del metodo handle(). Introdotto in Laravel 5.8.9 come opt-in, è diventato il default da Laravel 11 con la rimozione dell'EventServiceProvider dallo skeleton. Il risultato: zero configurazione manuale, listener auto-registranti e testabili con Event::fake(). 
L'interfaccia ValidationRule, introdotta in Laravel 10, ha sostituito la vecchia Rule con passes()/message() e InvokableRule, entrambe deprecate. Un unico metodo validate() con closure $fail permette regole testabili in isolamento, parametrizzabili via costruttore, e riutilizzabili su più Form Request senza duplicazione. 
Concurrency::run() è stato introdotto in Laravel 11.23 e stabilizzato in Laravel 12. Il driver process (default) serializza le closure, le esegue in processi PHP figli separati via Artisan, e restituisce i risultati al processo padre. Non usa fibers né thread - ogni task ha il proprio bootstrap completo dell'applicazione. 
La proprietà $casts non è deprecata in Laravel 12, ma il metodo casts() introdotto in Laravel 11 abilita chiamate statiche come AsEnumCollection::of() e AsCollection::using() - impossibili in una definizione di proprietà PHP. Ecco quando e come migrare. 
Laravel 11 ha introdotto la struttura slim che elimina Http/Kernel, Console/Kernel e la maggior parte dei Service Provider, centralizzando tutto in bootstrap/app.php. La guida ufficiale dice che la migrazione non è obbligatoria - ma in un applicativo con logica custom sparsa tra Kernel e Provider, adottarla riduce il boilerplate e la superficie di manutenzione. 
Le feature flag gestite con config() e tabelle custom generano debito tecnico che cresce con ogni funzionalità aggiunta. Laravel Pennant offre definizioni class-based, scoping per utente o tenant, rollout percentuali e un'API di testing che semplifica la migrazione da approcci legacy. 
Molte PMI si affidano ad applicativi Symfony appesantiti da configurazioni legacy dei servizi. Scopri come autowiring e attributi PHP in Symfony 6/7 riducono il debito tecnico, migliorano la manutenibilità e preparano il codebase per gli aggiornamenti futuri. 
Molte PMI si affidano ad applicativi PHP basati su Symfony 3.4 o Laravel 5.8, framework privi di supporto attivo per la sicurezza. Questo articolo analizza le sfide e i vantaggi strategici dell'aggiornamento a Symfony 7.x e Laravel 11/12, confrontando l'approccio "rattoppo" con una migrazione pianificata e mostrando i guadagni concreti in sicurezza, performance e manutenibilità. 
Molti gestionali PHP delle PMI italiane soffrono di codice legacy datato e difficile da manutenere. Moduli critici come fatturazione e gestione clienti diventano colli di bottiglia. Questo articolo esplora strategie di refactoring con Laravel e Symfony, mostrando come i test automatici con PHPUnit e Pest trasformino questa sfida in un investimento sicuro per stabilità ed efficienza.