Skip to main content

Inleiding

Deze gids beschrijft hoe je migreert van de oude applicatiestructuur van Laravel 10 en eerder (een structuur met Kernel-klassen en meerdere service providers) naar het Slim Application Skeleton van Laravel 11 en later.
De officiële documentatie raadt deze migratie niet aan.
  • De oude structuur van Laravel 10 blijft gewoon werken in Laravel 11 en later. Tot en met de huidige versies, inclusief Laravel 13, zijn er geen plannen om de ondersteuning te beëindigen.
  • De migratie is volledig optioneel. Niet verplicht en niet aanbevolen.
  • Begrijp je de verschillen tussen de oude en nieuwe structuur niet grondig, dan raden we je sterk aan de migratie achterwege te laten. Dit is werk voor ontwikkelaars die de interne werking van het framework goed kennen.
  • Maak vóór de migratie altijd een back-up en controleer dat alle tests slagen.

Wanneer migreren nodig kan zijn

In de volgende situaties kun je een migratie overwegen:
  • Je wilt het project laten aansluiten op de nieuwste standaardstructuur, zodat nieuwe teamleden het makkelijk kunnen vergelijken met de officiële documentatie
  • Je wilt consistentie bewaren met packages en starter kits die met Laravel 11 of later zijn gemaakt
  • Je wilt configbestanden en klassen uit de oude structuur opruimen en de codebase eenvoudiger maken

Vereisten

Deze gids gaat uit van de volgende situatie:

Migratievoorbeeld

We laten zien hoe je een project dat is gemaakt met Laravel 10 + Breeze (Blade-stack) migreert naar de nieuwe structuur, terwijl Breeze intact blijft.
1

bootstrap/app.php vervangen

Het oude bootstrap/app.php maakte een $app-instantie aan en registreerde de kernels. Dit vervang je door de Application::configure()-keten.Oud (Laravel 10):
Nieuw (Laravel 11 en later):
De callbacks van withMiddleware() en withExceptions() zijn de plek waar je de configuratie van de kernelbestanden die je in de volgende stappen verwijdert naartoe verhuist. Laat ze eerst leeg; je vult ze aan in de volgende stappen.
2

De HTTP-kernel (app/Http/Kernel.php) verwijderen

In app/Http/Kernel.php stonden de globale middleware, middlewaregroepen en middleware-aliassen gedefinieerd.Oud (app/Http/Kernel.php):
In Laravel 11 zit bovenstaande middleware als standaardwaarden ingebouwd in het framework. Heb je geen aanpassingen, dan kun je app/Http/Kernel.php direct verwijderen.Heb je wel aanpassingen (eigen middleware toegevoegd of uitgesloten), verhuis die dan eerst naar withMiddleware() in bootstrap/app.php en verwijder het bestand daarna.
Zodra de verhuizing klaar is, verwijder je app/Http/Kernel.php.
In Laravel 11 kun je ook de standaard-middlewareklassen zoals TrustProxies, EncryptCookies en VerifyCsrfToken verwijderen uit app/Http/Middleware/. Ze zitten ingebouwd in het framework, dus zonder aanpassingen heb je de bestanden zelf niet meer nodig.
3

De consolekernel (app/Console/Kernel.php) verwijderen

app/Console/Kernel.php verzorgde de scheduledefinities en het automatisch laden van commands.Oud (app/Console/Kernel.php):
Het automatisch laden van commands is in Laravel 11 en later overbodig geworden: de map app/Console/Commands/ wordt automatisch gescand, dus de regel met $this->load() is niet meer nodig.De scheduledefinities verhuis je naar routes/console.php of naar withSchedule() in bootstrap/app.php.
Verwijder daarna app/Console/Kernel.php.
Verwijder de bestanden van je eigen Artisan-commands in de map app/Console/ niet. Laat de commandbestanden staan en verwijder alleen het bestand van de kernelklasse.
4

De exception handler (app/Exceptions/Handler.php) verwijderen

app/Exceptions/Handler.php verzorgde de configuratie van exceptierapportage en -rendering.Oud (app/Exceptions/Handler.php):
Heb je aanpassingen, verhuis die dan eerst naar withExceptions() in bootstrap/app.php en verwijder het bestand daarna.
Had je eigen items toegevoegd aan $dontFlash, dan verhuis je die op dezelfde manier.
Zodra de verhuizing klaar is, verwijder je app/Exceptions/Handler.php.
5

De RouteServiceProvider verwijderen en routeregistratie verhuizen

app/Providers/RouteServiceProvider.php verzorgde het laden van routebestanden en de configuratie van rate limiting.Oud (app/Providers/RouteServiceProvider.php):
De registratie van routebestanden verhuis je naar withRouting() in bootstrap/app.php.
Rate limiting verhuis je naar AppServiceProvider::boot().
Gebruik je ergens de constante HOME, vervang die dan door de URL-string zelf of verplaats de constante naar de AppServiceProvider.Verwijder daarna app/Providers/RouteServiceProvider.php.
6

Service providers opruimen

In Laravel 10 waren er standaard vijf service providers. Deze voeg je samen tot één bestand: AppServiceProvider.php.Te verwijderen providers (eerst de inhoud verhuizen naar de AppServiceProvider, dan verwijderen):Voorbeeld: de inhoud van het oude app/Providers/AuthServiceProvider.php verhuizen:
Zodra je de overbodige providerbestanden hebt verwijderd, verwijder je de providers-array uit config/app.php.
Maak vervolgens bootstrap/providers.php aan om aan te sluiten op de nieuwe structuur.
Als bootstrap/providers.php bestaat, geeft Laravel dit bestand voorrang als lijst van providers.
7

De basiscontrollerklasse bijwerken

De Controller-basisklasse van Laravel 10 gebruikte de traits AuthorizesRequests en ValidatesRequests. De nieuwe basisklasse van Laravel 11 is een simpele abstracte klasse zonder deze traits.Oud (Laravel 10):
Nieuw (Laravel 11 en later):
De functionaliteit die de traits boden, vervang je als volgt:Gebruiken bestaande controllers de trait-methodes, dan kun je kiezen: elke controller aanpassen, of de traits in de Controller-basisklasse laten staan. Het blijft ook werken als je niet alles in één keer verandert.
Roepen de door Breeze of Jetstream gegenereerde authenticatiecontrollers $this->validate() of $this->authorize() aan, controleer dan zeker de werking voordat je de basisklasse wijzigt.
8

Overbodige configbestanden verwijderen

Bestanden die je niet hebt gewijzigd ten opzichte van de standaard, zoals config/cors.php, config/hashing.php en config/view.php, kun je verwijderen. Laat gewijzigde bestanden staan.
9

public/index.php bijwerken

Dit bestand is aangepast aan de nieuwe structuur, dus je herschrijft het volledig.
10

artisan bijwerken

Het artisan-bestand herschrijf je op dezelfde manier volledig.
11

tests/TestCase.php bijwerken

De trait CreatesApplication is niet meer nodig, dus je past dit aan. tests/CreatesApplication.php mag je verwijderen.
12

.env, .env.example en phpunit.xml bijwerken

Er is het een en ander veranderd, zoals CACHE_DRIVER dat CACHE_STORE is geworden, en er zijn items bijgekomen; pas dit aan waar nodig. Deze wijzigingen raken ook configbestanden en de productieomgeving, dus wees hier voorzichtig mee. Je hoeft dit niet koste wat kost te volgen.
13

Werking controleren

Is de migratie afgerond, controleer dan de werking in deze volgorde:
Treden er problemen op, herstel dan de verwijderde bestanden vanuit je back-up en bekijk de foutmeldingen.

Bestandsstructuur na de migratie

Na de migratie ziet het project er als volgt uit (met de wijzigingen ten opzichte van de oude structuur):

Samenvatting

Naslag

Laatst gewijzigd op 6 september 2026