Af Greg Nowak. Senest opdateret 2026-06-26.
Drupal 10 har nu en dato, som bør stå i enhver webstedsejers kalender. Pr. 26. juni 2026 angiver Drupal.org den 9. december 2026 som Drupal 10's end-of-life-dato. Drupal 10.6.0 er samtidig udpeget som den sidste minor release til Drupal 10, og der kommer ingen nye Drupal 10-releases efter denne dato.
Det betyder ikke, at alle Drupal 10-websteder er i problemer i dag. Men det betyder, at samtalen bør handle om noget andet. Det relevante spørgsmål er ikke længere: »Skal vi opgradere på et tidspunkt?« Det er: »Hvad skal vi vide, før opgraderingen til Drupal 11 kan planlægges med sikker hånd?«
Deadline synliggør skjult projektarbejde
For virksomhedsejere, driftsansvarlige og bureauteams er det risikable sjældent den sidste Composer-kommando. Risikoen ligger i alt det skjulte arbejde med afhængigheder, som skal være afdækket, før det er sikkert at køre kommandoen.
Den officielle opgraderingsvej fra Drupal 10 til 11 forudsætter, at webstedet kører Drupal 10.3.x eller nyere, før det flyttes til Drupal 11. Den forudsætter også, at hostingmiljøet opfylder Drupal 11's platformskrav: PHP 8.3.0 eller nyere, kommandolinjeadgang med Composer og Drush samt mulighed for at justere filrettigheder under opgraderingen.
Der er også oprydning, som afhænger af det enkelte websted. Drupals vejledning gør opmærksom på, at alle core-filer ændres, herunder .htaccess. Derfor skal eventuelle scaffold-tilpasninger findes og dokumenteres. Flere extensions, som blev deprecated i Drupal 10, er fjernet i Drupal 11, herunder Actions UI, Activity Tracker, Book, Forum, Statistics og Tour. Hvis et live-websted stadig er afhængigt af en af disse, skal opgraderingskortlægningen afklare, om den skal fjernes, erstattes af en contrib-version, eller om den tilhørende forretningsproces skal ændres.
| Område | Det skal kontrolleres | Nødvendig beslutning |
|---|---|---|
| Platform | Drupal 10.3+, PHP 8.3+, Composer, Drush og filrettigheder | Kan den nuværende host og pipeline køre Drupal 11? |
| Contrib-projekter | Moduler, temaer, major-version constraints og issue queues | Skal de opdateres, erstattes, patches eller udfases? |
| Custom code | Deprecated API'er, custom modules, temaer, Twig og biblioteker | Skal det rettes manuelt, håndteres med Drupal Rector eller redesignes? |
| Composer og deployment | Lock-filens tilstand, direkte afhængigheder, forældede pakker og audit-resultater | Skal afhængighederne ryddes op, før core flyttes? |
| Scaffold og core-extensions | Ændringer i .htaccess, fjernede moduler og forældede extensions | Hvad skal dokumenteres og tilføjes igen? |
Kør parathedstjek før opgraderingen
Upgrade Status-projektet er nyttigt, fordi det behandler paratheden til en ny major-version som en vurdering og ikke et gæt. Det kontrollerer, om den aktuelle Drupal-version understøtter opgradering til den næste major-version, om systemet opfylder kravene til næste version, og om contrib-projekter kan opdateres, mens webstedet stadig kører den nuværende major-version. Det udfører også PHPStan-baserede kompatibilitetstjek, genkender flere Drupal-specifikke deprecations og kan bruges via Drush i kommandolinje- eller CI-workflows.
Timingen er vigtig. Upgrade Status bør køres på det nuværende Drupal 10-websted for at kontrollere paratheden til Drupal 11. Når webstedet først er opgraderet, er mange deprecated API'er og biblioteker væk, og der er derfor mindre tilbage at undersøge. Projektdokumentationen gør det samtidig klart, at hverken Upgrade Status eller Drupal cores opgraderingsvej understøtter, at man springer flere major-versioner over. I praksis betyder det, at opgradering direkte fra Drupal 10 til Drupal 12 ikke er en genvej.
Composer-efterslæb skal med i estimatet
Composer-parathed handler ikke kun om bekvemmelighed for udviklerne. Det er en del af leverancerisikoen. Drupal 10 kræver Composer 2.3.6 eller nyere, mens Drupal 11 kræver Composer 2.7.0 eller nyere. Hvis lokale maskiner, CI runners, release-scripts eller installationstrin i produktion stadig forudsætter ældre værktøjer, er opgraderingen ikke driftsmæssigt klar.
En brugbar kortlægning holder kommandoerne tæt på arbejdet. Begynd med at synliggøre det, der er forældet eller usikkert:
composer outdated "drupal/*"viser Drupal-projekter, som har tilgængelige opdateringer.composer auditkontrollerer advisories for PHP-afhængigheder og ikke kun Drupal-moduler.composer why-not drupal/core ^11hjælper med at identificere constraints, der blokerer Drupal 11.composer update --dry-runviser de forventede ændringer i afhængighederne, før nogen filer ændres.
Ved større modulopgraderinger er en simpel opdatering ofte ikke nok. Drupals Composer-vejledning angiver, at en ny major-version skal tilføjes som et eksplicit krav, eksempelvis composer require drupal/modulename:^2.0 --with-all-dependencies. I forbindelse med forberedelsen bruger Drupals core-vejledning også --no-update, når constraints ændres først. Dermed kan konflikter mellem afhængigheder løses kontrolleret i stedet for midt i et release-vindue.
En praktisk projektstruktur
- Bekræft udgangspunktet: core-version, PHP, Composer, Drush, hosting, rettigheder, backups og deployment-workflow.
- Udarbejd kortlægningen: contrib-moduler, temaer, custom code, direkte Composer-afhængigheder, fjernede core-extensions og scaffold-tilpasninger.
- Kør Upgrade Status: Registrer resultaterne for miljøet, contrib-projekterne og deprecations i custom code.
- Udbedr i den rigtige rækkefølge: Opdater det, der kan flyttes på Drupal 10, håndter constraints for major-versioner, fjern forældede afhængigheder, og ret custom code.
- Gennemfør og verificer: Tag backup af databasen, kør Composer med dry-run, udfør opdateringen, kør databaseopdateringer, genopbyg caches, eksportér konfigurationen, test workflows, overvåg logs, og kør cron.
For bureauteams giver denne struktur også en bedre overdragelse. Kortlægningen kan blive til en afgrænset backlog i stedet for en diffus advarsel. For ejere og driftsansvarlige giver den opgraderingen et budget, en risikoprofil og en rækkefølge.
Har opgraderingen brug for en fast ansvarlig?
Hvis dit Drupal 10-websted har uklar modulkompatibilitet, gamle Composer-constraints, custom code, som ikke er kontrolleret i forhold til Drupal 11, eller en deployment-proces, som kun én person forstår, er det et godt tidspunkt at omsætte de ubekendte faktorer til en plan. Greg kan hjælpe med at gennemgå webstedet, køre parathedstjek, skelne hurtige rettelser fra reelle blokeringer og forme arbejdet til et kontrolleret opgraderingsprojekt. Tal med Greg om kortlægningen af din Drupal-opgradering.
Relateret indhold på GrN.dk
- Parathed til samarbejdsfunktionerne i WordPress 7.0: Derfor kan ældre meta boxes og antagelser om hosting stadig forsinke opgraderingen
- CMS-opgraderinger i 2026: En PHP-roadmap for WordPress- og Drupal-websteder
- Drupal CMS 2.0 gør genopbygning af marketingwebsteder hurtigere, men det er ikke autopilot
Har du brug for hjælp til denne type arbejde?
Planlæg kortlægningen af din Drupal-opgradering. Kontakt Greg.
