notiziephp.it

Cosa sappiamo su Laravel 14

Traduzione da Laravel News
21 Settembre 2026 Tempo di lettura: 6 minuti
Cosa sappiamo su Laravel 14

Laravel 14 è la prossima major release del framework Laravel, prevista per Q1 2027. Questa release richiederà PHP 8.4 come versione minima e seguirà il ciclo di supporto standard di Laravel, con bug fix fino a Q3 2028 e aggiornamenti di sicurezza fino a Q1 2029.

Il team di Laravel non ha ancora annunciato una data di rilascio né un elenco di funzionalità. Tutto ciò che segue proviene dal branch master di laravel/framework, dove avviene lo sviluppo di Laravel 14, e qualsiasi dettaglio può cambiare prima del rilascio.

Nuove funzionalità

Le funzionalità di Laravel 14 verranno aggiunte a questo articolo man mano che vengono annunciate. La maggior parte delle novità continua ad arrivare nelle release minor settimanali di Laravel 13, mentre le funzionalità elencate di seguito attendono Laravel 14 perché aggiungono un metodo a un contract o modificano una firma.

Route::query()

#60655 di Vazha Aptsiauri aggiunge il supporto al routing per il metodo HTTP QUERY, un metodo sicuro che trasporta un body di richiesta:

Route::query('/search', function () {
return request()->input('filter');
});

Route::any() include QUERY, e il middleware CSRF lo tratta come una richiesta di lettura, allo stesso modo di GET, HEAD e OPTIONS.

Laravel 13.19 ha già aggiunto Http::query() al client HTTP, insieme agli helper di testing query() e queryJson().

Per Laravel 13, dai un'occhiata al nostro tutorial su il metodo HTTP QUERY con la ricerca di Scout.

$user->authorize()

Will Rowe ha aggiunto un metodo authorize() al contract e al trait Authorizable in #59708:

// Laravel 13
Gate::forUser($user)->authorize('viewAny', Post::class);
 
// Laravel 14
$user->authorize('viewAny', Post::class);

Funziona come $user->can(), ma lancia una AuthorizationException quando il controllo fallisce.

Contesto per report()

L'helper report() e il metodo report() dell'exception handler accettano un array di contesto opzionale, aggiunto da Caleb White in #60767:

try {
$order->charge();
} catch (Throwable $e) {
report($e, ['order_id' => $order->id]);
}

Il contract ExceptionHandler diventa report(Throwable $e, array $context = []), quindi un handler personalizzato che esegue l'override di report() ha bisogno del nuovo parametro.

Storage::fake() per i dischi on-demand

Storage::fake('ondemand') intercetta le chiamate a Storage::build(), così puoi testare i dischi on-demand con le stesse assertion dei dischi con nome (#61378). La PR è stata inviata a master perché un'applicazione potrebbe già avere un disco chiamato ondemand.

orWhereKey() e le subquery in whereKey()

Caleb White ha consolidato whereKey() e whereKeyNot() e ha aggiunto orWhereKey() e orWhereKeyNot() in #61395. Una seconda PR, #61496, consente a tutti e quattro i metodi di accettare una subquery.

Modifiche incompatibili

I metodi di pausa delle queue accettano prima la queue

Laravel 13.25 ha aggiunto la possibilità di mettere in pausa tutte le queue, e i metodi per singola queue sulla facade Queue richiedono la connessione come primo argomento. #61076 sposta la connessione in fondo e la imposta di default sulla connessione predefinita:

// Laravel 13
Queue::pause('redis', 'emails');
Queue::pauseFor('redis', 'emails', 60);
 
// Laravel 14
Queue::pause('emails');
Queue::pauseFor('emails', 60);
Queue::pause('emails', 'redis');

Anche resume() e isPaused() accettano prima la queue e, come secondo argomento opzionale, la connessione.

lazy() e chunk() non modificano più il builder

In Laravel 13, lazy() e chunk() modificano il query builder mentre eseguono la paginazione. Riutilizzare lo stesso builder in seguito restituisce un risultato errato:

$query = User::query();
 
foreach ($query->lazy(2) as $user) {
// ...
}
 
$query->count(); // 0 in Laravel 13

Jack Bayliss ha corretto entrambi i metodi in #61411 e #61428, così count() restituisce il numero completo di righe in Laravel 14.

findOr() con un array di ID

Builder::findOr() non chiamava mai la sua callback quando si passava un array di ID. #61577 di Matthieu lo allinea a findOrFail() e alle versioni di findOr() sulle relazioni:

User::findOr([1, 99], fn () => 'fallback');
 
// Laravel 13: a Collection containing only user 1
// Laravel 14: 'fallback'

Cache::has() e Cache::forget() con gli array

I docblock di has() e forget() accettano array da quattro anni, ma Cache::has(['a', 'b']) restituiva sempre true e Cache::forget(['a', 'b']) non rimuoveva le chiavi. #61466 di Jack Bayliss corregge entrambi i metodi. In Laravel 14, has() restituisce true solo quando ogni chiave esiste:

Cache::put('foo', 'bar');
 
Cache::has(['foo', 'missing']);
 
// Laravel 13: true
// Laravel 14: false

Passare un array a forget() rimuove ogni chiave e restituisce true solo quando tutte le chiavi sono state rimosse:

Cache::forget(['foo', 'baz']);
 
// Laravel 13: the keys remain, and the Redis store emits an
// "Array to string conversion" warning
// Laravel 14: both keys are removed

MassPrunable include i modelli soft-deleted

Il trait Prunable aggiunge withTrashed() alla query di prune quando un modello utilizza i soft delete. MassPrunable non lo faceva, e #61425 li rende coerenti. Prendiamo un modello che utilizza entrambi i trait:

use Illuminate\Database\Eloquent\MassPrunable;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\SoftDeletes;
 
class Post extends Model
{
use MassPrunable, SoftDeletes;
 
public function prunable()
{
return static::where('created_at', '<=', now()->subMonth());
}
}

In Laravel 13, model:prune esegue un force delete dei post corrispondenti che non sono soft-deleted, mentre i post soft-deleted restano nella tabella. In Laravel 14, esegue il force delete di ogni post corrispondente, inclusi quelli soft-deleted.

Se usi MassPrunable su un modello con soft delete, verifica che la tua query prunable() selezioni ancora le righe che ti aspetti. Per mantenere il comportamento di Laravel 13, aggiungi withoutTrashed() alla query.

Requisiti di versione di PHP

Laravel 14 richiederà PHP 8.4 come versione minima, in aumento rispetto al minimo di PHP 8.3 di Laravel 13. In #59104, Laravel 14 alza la versione minima a PHP 8.4, perché Symfony 8 richiede PHP 8.4 come minimo.

Laravel funzionerà anche con versioni più recenti di PHP. Consulta Le novità di PHP 8.6 per il resto di quella release.

Altre modifiche alle dipendenze su master che probabilmente arriveranno in Laravel 14:

  • ably/ably-php passa alla versione che utilizza il protocollo Ably 2.0 (#60860)
  • orchestra/testbench-core passa a ^12.0
  • PHPUnit 11.5, 12.5 e 13 sono tutti supportati

Timeline di supporto

La politica di supporto di Laravel prevede il rilascio di una major release ogni anno, intorno al primo trimestre. Seguendo tale politica, Laravel 14 riceverà bug fix fino a Q3 2028 e aggiornamenti di sicurezza fino a Q1 2029:

Versione PHP (*) Rilascio Bug fix fino a Fix di sicurezza fino a
11 8.2 - 8.4 12 marzo 2024 3 settembre 2025 12 marzo 2026
12 8.2 - 8.5 24 febbraio 2025 13 agosto 2026 24 febbraio 2027
13 8.3 - 8.5 17 marzo 2026 Q3 2027 17 marzo 2028
14 8.4+ Q1 2027 Q3 2028 Q1 2029

Nota: la documentazione ufficiale non elenca ancora Laravel 14, i dettagli ufficiali sono da definire.

Laravel 13, rilasciato il 17 marzo 2026, continuerà a ricevere:

  • Bug fix fino a Q3 2027
  • Fix di sicurezza fino al 17 marzo 2028

Laravel 12 non riceve più bug fix e i suoi fix di sicurezza terminano il 24 febbraio 2027.

Aggiornare a Laravel 14

Se vuoi automatizzare l'aggiornamento quando Laravel 14 sarà rilasciato, dai un'occhiata a Laravel Shift. Shift apre una pull request con commit atomici che potrai revisionare.

Condividi su: LinkedIn

Altri articoli recenti