Drupal 12: Mi Változik És Mikor Érdemes Váltani

A Drupal 12 a 2026. december 7-i hétre van ütemezve, a Drupal 10 támogatása pedig 2026. december 9-én ér véget. Mindkét dátum a Drupal mag kiadási menetrendjének ugyanazon az oldalán szerepel, két sor távolságra egymástól, és a Drupal 10-et üzemeltetők többsége egyiket sem vette észre. Az új főverzió első alfáját 2026. szeptember 2-án címkézték, így a kiadás alakja mostantól tény, nem találgatás.

Ez az ütközés az egész történet. Egy új főverzió érkezése általában nem sürgős a webhely tulajdonosának, hiszen egy-két évig el lehet üldögélni az előző főverzión, amíg az ökoszisztéma felzárkózik. Ezúttal az előző főverzió pontosan azon a héten szűnik meg biztonsági közleményeket kapni, amelyen az új megjelenik, és ettől egy technikai eseményből megfelelőségi éllel bíró határidő lesz.

Az alábbiakban következik a menetrend úgy, ahogy a drupal.org közzéteszi, hogy mi változik ténylegesen a kódban, mit kényszerítenek ki az új platformküszöbök a tárhelyen, a három reális frissítési útvonal a költségsávjaival, és egy decemberből visszafelé tervezett terv. A megnyugtató rész korán érkezik: egy Drupal főverzióváltás nagyrészt törlés, nem újrafeltalálás.

Mikor jelenik meg a Drupal 12, és muszáj váltanom? A Drupal 12.0.0 a 2026. december 7-i hétre van ütemezve, a Drupal 11.5.0 kíséretében. A Drupal 10 két nappal később, 2026. december 9-én éri el a támogatás végét, ezután nem adnak ki hozzá több biztonsági közleményt. Egy Drupal 11-es webhelyre kis frissítés vár. Egy Drupal 10-es webhelynek előbb a Drupal 11.4-en vagy újabbon kell átmennie, tehát a munka két ugrás, nem egy.

A két dátum, amely eldönti a következő hat hónapját

A kiadási menedzserek előre közzéteszik a teljes ciklust, és a mostani szokatlanul rendezett. A Drupal 11.4.0 a 2026. június 29-i héten jelent meg, és ez a kiadás zárta le a biztonsági támogatást a Drupal 11.2.x és a Drupal 10.5.x számára is. A 12.0.0-alpha1 címke 2026. szeptember 2-án ment ki. A béta követelményeit 2026. szeptember 11-ig kellett teljesíteni, a 12.0.0-beta1 és a 11.5.0-beta1 a szeptember 14-i héten, a kiadásjelöltek pedig a november 9-i héten érkeznek.

A december 7-i hét ezután három dolgot tesz egyszerre. Megjelenik a Drupal 12.0.0, mellette megjelenik a Drupal 11.5.0, és véget ér a biztonsági támogatás a Drupal 11.3.x és a Drupal 10.6.x számára. Két nappal később, 2026. december 9-én a Drupal 10 egésze eléri a támogatás végét, és többé egyetlen kiadás sem készül belőle.

Miért esik egy hétre a Drupal 10 vége és a Drupal 12 érkezése

Ez szabályzat, nem véletlen. A kiadási folyamat áttekintése kimondja, hogy a főverziók kétévente, páros években érkeznek, és hogy minden főverzió legalább négy évig támogatott, egészen addig, amíg két további főverzió meg nem jelenik. A Drupal 10.0.0 2022. december 15-én jött ki. A Drupal 11 2024 augusztusában érkezett, a Drupal 12 pedig 2026 decemberében érkezik, ez a második további főverzió, és négy év eltelt. Az óra pontosan a terv szerint járt le.

Ugyanez a szabályzat rendezi az alverziókat. Minden alverzió egy évig támogatott, az első hat hónapban hibajavításokkal és biztonsági javításokkal, az utolsó hat hónapban már csak biztonsági javításokkal. Ezért kap ma egyedül a 10.6.x közleményeket, és ezért veszíti el a 11.3.x a lefedettségét abban a pillanatban, amikor a 11.5.0 megjelenik.

A Drupal 11 nem áll meg, amikor a Drupal 12 elindul. A 11.5.0 ugyanazon a héten való kiadása indítja el azt, amit a szabályzat hosszú távú támogatási szakasznak nevez: az előző főverzió megtart egy azonos programozási felületű alverziót, átáll a Symfony egy LTS kiadására, és félévente kap egy szűkülő hatókörű karbantartási alverziót. A drupal.org nem tesz közzé kemény dátumot a Drupal 11 támogatásának végére, de a saját elavult bővítményekről szóló dokumentációja szerint a Drupal 11 2028 közepéig vagy végéig lesz támogatott.

Hány webhely ül még mindig a Drupal 10-en

A számok nyilvánosak, és nem kényelmesek. A drupal.org maghasználati statisztikái a 2026. augusztus 23-i héten 468 877 olyan webhelyet rögzítenek, amely magverziót jelent. Ebből 205 568 fut a Drupal 10 valamelyik ágán, 168 857 pedig a Drupal 11-en. A jelentést küldő telepítési bázis nagyjából 44 százaléka azon a verzión van, amely decemberben megszűnik közleményeket kapni.

Az élesebb szám ezen belül rejlik. Egyedül a 10.6.x rendelkezik még biztonsági lefedettséggel, és a 10.6.x ezekből a webhelyekből 139 911-et tesz ki. A maradék 65 657 a 10.0 és 10.5 közötti verziókon fut, vagyis már ma, szeptemberben nem támogatott alverziót üzemeltetnek, anélkül hogy megvárnák a decembert.

Ezek a számok olyan webhelyektől származnak, amelyek önkéntesen jelentenek az Update Status modulon keresztül, tehát a valós populáció nagyobb, és ugyanabba az irányba dől. A gyakorlati olvasat az, hogy nagyon sok szervezet ugyanabban a negyedévben próbálja majd lefoglalni ugyanazt a frissítési munkát, és októberben meg novemberben az ügynökségi kapacitás lesz a szűk keresztmetszet, nem a kód.

Mit jelent valójában a támogatás vége egy Drupal webhelynek

A támogatás vége nem kapcsoló, amely eltöri a webhelyet. A Drupal 10-es telepítése december 10-én pontosan úgy szolgálja ki az oldalakat, ahogy december 8-án tette. Az változik, hogy a Drupal biztonsági csapata többé nem ad ki közleményeket és javításokat ehhez a kódhoz, így attól a naptól kezdve a Drupal 10 magjában újonnan felfedezett minden sebezhetőség véglegesen nyitva marad.

A második hatás lassabb, és többet árt. Egy contrib modul biztonsági lefedettsége attól függ, hogy a modulnak van-e stabil kiadása egy támogatott magágon, így ahogy a karbantartók elejtik a Drupal 10 kompatibilitást, a webhelyén lévő modulok is csendben kilépnek a közleményezési folyamatból. Erről nem kap értesítést. A modul egyszerűen nem jelenik meg többé a biztonsági kiadásokban, a saját webhelyén futó, elérhető frissítésekről szóló jelentés pedig továbbra is zöldnek látszik.

A harmadik hatás az, hogy a kilépés annál drágább, minél tovább vár. Egy novemberben frissített Drupal 10-es webhely karbantartott magág ellen frissül, működő frissítési útvonallal. Ugyanaz a webhely a következő júniusban már mentőprojekt, mert a contrib modulok, amelyektől függ, további hat hónapot kaptak arra, hogy nélküle lépjenek tovább.

Cyber Essentials, biztosítás és szerződéses kikötések

Itt szűnik meg a nem támogatott CMS mérnöki kérdés lenni. Az NCSC 2026 áprilisi keltezésű Cyber Essentials informatikai infrastruktúra követelményei v3.3 kimondják, hogy a hatókörbe tartozó eszközökön minden szoftvernek licencelt és támogatott állapotban kell lennie, és el kell távolítani az eszközökről, amint támogatás nélkül marad, vagy ki kell venni a hatókörből egy olyan meghatározott részhalmazzal, amely minden internetes forgalmat blokkol. A kontroll kiterjed a szerverekre, az IaaS, a PaaS és a SaaS szolgáltatásokra, így egy hatókörbe eső szerveren futó Drupal telepítés egyértelműen érintett.

Egy nyilvánosan elérhető Drupal 10-es webhelyet nem lehet elzárni az internettől, ezért 2026. december 9-e után két válasz marad: frissíteni, vagy elfogadni, hogy a webhely megbukik ezen a kontrollon. Ha a szervezete Cyber Essentials vagy Cyber Essentials Plus tanúsítvánnyal rendelkezik, és azt évente megújítja, ezt a kérdést a következő értékelésen írásban fel fogják tenni.

Legyen óvatos azzal, amit ezen túl állít. Hogy egy konkrét kiberbiztosítási kötvényt vagy ügyfélszerződést érint-e a dolog, teljes egészében a szövegezésén múlik, és a lényeges kikötések általában támogatott szoftvert vagy gyártó által karbantartott verziót követelnek meg, ahelyett hogy a Drupalt neveznék meg. Olvassa el a saját kötvényét és a saját keretszerződéseit december előtt, ne egy incidens után, mert az az olcsó időpont erre.

Mi változik valójában a Drupal 12-ben

Nagyon kevés, és ez az őszinte és hasznos válasz. A 12.0.0-alpha1 kiadási jegyzete nyíltan kimondja: a 12.0.x szinte azonos lesz a 11.5.x ággal, azzal a különbséggel, hogy az elavult kódot eltávolítják, beleértve egész elavult modulokat, a függőségek új főverziókra lépnek, és a rendszerkövetelmények emelkednek. Minden más változás ügyében a jegyzet a 11.5.x ághoz irányítja.

Van néhány valódi viselkedésbeli változás, amelyet érdemes ismerni. Az alapértelmezett jelszóhasító algoritmus argon2id lesz, a bcrypt pedig kernelparamétereken keresztül marad elérhető ott, ahol az argon2 hiányzik. A mag robots.txt fájlja mostantól blokkolja a lekérdezési paramétereket hordozó keresési találati oldalakat, ami megakadályozza, hogy a keresők végtelen fazettált kombinációkat járjanak be, az egyedi robots.txt fájlt használó webhelyeknek pedig kézzel kell felvenniük ezeket a tiltó szabályokat. A HTMX, amelyet a mag már most szállít, a béta1-re a 2-es verzióról a 4-esre vált.

Van még egy, amelyet könnyű elnézni. A Drupal közvetlen üzemeltetése Windowson éles környezetben elavultnak minősül a Drupal 12-ben, azon az alapon, hogy nincs automatizált Windows tesztkörnyezet, és kevés fejlesztő tesztel rajta. A helyi fejlesztéshez a Windows továbbra is támogatott. Ha éles rendszert futtat Windowson, ez a következő hónapok tárhelydöntése, nem kódmódosítás.

A magból kikerülő bővítmények

A Drupal évek óta viszi ki a szűk hatókörű modulokat a magból contrib projektekbe, és a Drupal 12 ezt folytatja. Az alpha1 jegyzete eltávolítottként sorolja fel a Ban, Contact, Field Layout, History, Settings Tray, Shortcut és Telephone modulokat, valamint a Stable 9 sablont. A Text with Summary mezőbővítmény szintén saját contrib modulba került. A Ban már a 11.3-ban elavult lett, a Contact, a Field Layout, a History és a Telephone a 11.4-ben, a Settings Tray, a Shortcut és a Text with Summary pedig a 11.5-ben.

Kettő ezek közül meglepetés lesz. A Shortcut és a Settings Tray olyan adminisztrációs funkciók, amelyeket rengeteg szerkesztőségi csapat használ naponta anélkül, hogy valaha opcionálisnak gondolná őket, és különösen a Settings Tray adja a helyben történő blokk-konfigurálást, amelyre a szerkesztők támaszkodnak.

A kezelés mechanikája fontosabb, mint a lista. A helyes lépés az, hogy a frissítés előtt felveszi a contrib változatot a Composer követelményei közé, nem pedig az, hogy eltávolítja a modult. Az eltávolítás megsemmisíti a bővítmény konfigurációját, a Drupal modulfelderítése pedig utoljára néz a magba, így amint a contrib projekt jelen van, a Drupal egyszerűen azt használja. Vegye figyelembe azt is, hogy a Drush megkerülheti az update.php hiányzó bővítményekre vonatkozó figyelmeztetéseit, így a hiba csak utólag, az állapotjelentés hibáiként bukkan fel.

A Migrate Drupal elvesztése fáj a legjobban

A Migrate Drupal és a Migrate Drupal UI modult eltávolítják a Drupal 12-ből, és a többivel ellentétben nem kerülnek át contrib projektbe. A Drupal 12 megtartja a Migrate programozási felületet és a modern Drupalra vonatkozó célbővítményeket, de nem tartja meg a Drupal 6-hoz és Drupal 7-hez tartozó forrásbővítményeket.

Olvassa el újra, ha Drupal 7-es webhely tulajdonosa. Az az eszköz, amely beolvas egy régi Drupal adatbázist és egy modernbe írja, létezik a Drupal 11-ben, és nem létezik a Drupal 12-ben. A drupal.org útmutatása egyértelmű: azoknak a Drupal 6-os vagy Drupal 7-es webhelyeknek, amelyek használni kívánják a migrációs felületet, továbbra is a Drupal 11-be kell migrálniuk, majd a szokásos frissítési folyamattal kell átlépniük a Drupal 11-ről a Drupal 12-re.

Ez egy homályos szándékot kemény sorrendi kényszerré alakít. Egy olyan Drupal 7-es újraépítésnek, amely a Drupal 11 támogatásának megszűnése után ér célba, vagy saját forrásbővítményeket kell írnia, vagy vissza kell állítania egy régebbi magot, hogy a migrációt eldobható környezetben futtassa, vagy más úton kell exportálnia és visszaimportálnia a tartalmat. Mindhárom drágább annál, mint a migrációt a Drupal 11-be elvégezni, amíg a Drupal 11 aktuális, karbantartott cél. A Drupal migráció költségeiről, lehetőségeiről és határidőiről szóló útmutatónk részletesen bemutatja ennek a munkának az alakját.

Az új függőségi küszöbök

A főverzió az a pont, ahol a Drupal megemelheti a platformkövetelményeit, és a Drupal 12 él is ezzel a lehetőséggel, mindenütt. Ezek a küszöbök a frissítés azon része, amellyel nem lehet alkudni, mert a telepítéskor kényszerülnek ki.

PHP 8.5, és semmi régebbi

A Drupal 12 PHP 8.5 verziót követel meg. A PHP követelmények táblázata szerint a Drupal 12.0 a PHP 8.5 verziót támogatja, és mindent visszautasít alatta, míg a Drupal 11.3 és 11.4 elfogadja a 8.3, 8.4 és 8.5 verziót. Ez az átfedés az útvonala: vigye át a webhelyet PHP 8.5-re, amíg még Drupal 11.4-en fut, győződjön meg róla, hogy jól viselkedik, és csak azután váltson Drupal verziót.

A küszöb inkább nagyvonalú, mint büntető. A PHP 8.5 2025. november 20-án jelent meg, és a php.net támogatott verziókat felsoroló oldala szerint az aktív támogatása 2027. december 31-ig, a biztonsági támogatása pedig 2029. december 31-ig tart. Ha ide érkezik meg, három évet vásárol, mielőtt ez a beszélgetés újra előjönne.

Adatbázisok és Symfony

A Drupal 12 adatbázis-kiszolgálóra vonatkozó követelményei a MySQL 8.0 vagy újabb, a MariaDB 10.11 vagy újabb, a PostgreSQL 18 vagy újabb, valamint az SQLite 3.45 a json1 kiterjesztéssel. A PostgreSQL-t használó webhelyeknek ezt a küszöböt különös gonddal érdemes ellenőrizniük, mert az alpha1 kiadási jegyzete PostgreSQL 19-et említ, míg a követelményoldal és a telepítő kódja egyaránt 18-at. Ellenőrizze újra a béta1-nél, mielőtt adatbázis-munkát foglal le.

A mélyben a Symfony 7.4-ről 8.1-re, a Guzzle pedig 7-ről 8-ra lép. Több régebbi könyvtár-főverzió támogatása megszűnik, köztük a doctrine/lexer 2, az egulias/email-validator 3 és a guzzlehttp/psr7 2 verzióé. Az egyedi kód, amely közvetlenül Symfony osztályokat típusol, az a hely, ahol ez megmutatkozik.

Mit kényszerít ki a küszöb a tárhelyen

A MariaDB ugrása az, amely a megosztott és menedzselt tárhelyeket kapja el. A Drupal 11 elfogadja a MariaDB 10.6 verziót, amelynek közösségi karbantartása a MariaDB karbantartási szabályzata szerint 2026. július 6-án ért véget, tehát egy Drupal 11-es webhely jelenleg teljesen jogszerűen ülhet nem támogatott adatbázismotoron. A Drupal 12 a küszöböt 10.11-re emeli, amelyet 2028. február 16-ig karbantartanak. Ha a tárhelyszolgáltatója ma nem tud PHP 8.5-öt és MariaDB 10.11-et adni, a tárhelyváltásnak meg kell előznie a Drupal váltást, és éppen ez az átrendezés az, ami egy kéthetes munkából kéthónaposat csinál. A Drupalt valóban jól futtató környezetről szóló jegyzetünk a platformoldalt tárgyalja.

Miért kezelhető a Drupal 12 az elavulási modell miatt

Íme az a mechanizmus, amelyet a legtöbb webhelytulajdonosnak soha senki nem magyarázott el, és amely miatt a Drupal főverziói már nem ijesztők. A folyamatos frissítésekről szóló szabályzat egyszerű ígéretre kötelezi a magot: a következő főkiadás nyilvános programozási felülete azonos az előző főverzió utolsó alverziójáéval. Az új felületek az alverziókban kerülnek be, a régieket az alverziókban jelölik elavultnak, és a törlés kizárólag a főverzióhatáron történik.

A gyakorlati következményt érdemes egyszerűen kimondani. Ha az egyedi kódja és a contrib moduljai elavulási figyelmeztetés nélkül futnak a Drupal 11.5-ön, akkor futnak a Drupal 12-n is. A frissítés megszűnik újraírás lenni, és függőségemeléssé plusz adatbázis-frissítéssé válik, mert minden, ami eltört volna, már hónapokkal korábban figyelmeztetésként megjelent, amelyet ráérősen ki lehetett javítani.

Ezért mondja a kiadási jegyzet is, hogy előbb a 11.4-re vagy újabbra frissítsen, és ezért ajánlja nyomatékosan a 11.5-öt. A 11.4.0 előtti kiadásokból induló adatbázis-frissítési útvonalat teljesen eltávolították a Drupal 12-ből, tehát egy 11.3-as vagy régebbi webhelynek nincs útja a 12-be, amíg fel nem lép a 11-es ágon. Ez nem tanács, ez egy hiányzó kódútvonal.

Az elavulásokat jelentő eszközök

Két projekt végzi a munkát, és mindkettőt karbantartják jelenleg. Az Upgrade Status a webhely egészét vizsgáló szkenner. Arra a webhelyre telepíti, amelyről frissít, nem arra, amelyre frissít, mert az elavult felületeknek létezniük kell ahhoz, hogy megtalálja a rájuk irányuló hívásokat. Ellenőrzi, hogy a környezete megfelel-e a következő főverzió rendszerkövetelményeinek, összeveti a contrib projekteket az elérhető frissítésekkel, PHPStan futtatásával keresi az elavult PHP felületek használatát, és beolvassa a Twig sablonokat, az info.yml fájlokat, a composer.json fájlt és az elavult konfigurációs kulcsokat. Az 5.0.0-alpha3 kiadás, 2026. július 2-i keltezéssel, a Drupal 10.4, 11 és 12 verziókkal való kompatibilitást hirdeti.

Emellett kategorizálja is, amit talál, és ez az a rész, amely pénzt takarít meg. A problémákat aszerint rendezi, hogy gép javíthatja-e őket vagy ember kell hozzájuk, így a kézi felét be tudja árazni, mielőtt dátumot vállalna. Drush alatt az upgrade_status:analyze paranccsal fut, és a Code Climate formátumú JSON kimenete beköthető a GitLab CI-ba.

A Drupal Rector a másik fele. Átírja a gépiesen javítható elavulásokat az egyedi moduljaiban és sablonjaiban, --dry-run kapcsolóval, amellyel előre megnézhető a különbség. Az 1.1.2 verzió 2026. augusztus 7-én jelent meg. A kettővel együtt egy hozzáértő fejlesztő két-három nap alatt védhető felkészültségi jelentést készít egy közepes méretű webhelyről.

Első útvonal: Drupal 11-ről Drupal 12-re

Ha Drupal 11.4-en vagy 11.5-ön van naprakész contrib modulokkal, ez kis munka. A hivatalos frissítési útmutató többnyire Composer parancsokból áll: a 12-es verzió metacsomagjainak megkövetelése --no-update kapcsolóval, a drupal/core explicit követelményének eltávolítása, a composer update --dry-run futtatása, majd élesben is, végül az adatbázis-frissítések alkalmazása a drush updatedb paranccsal.

Az igazi munka ennek két oldalán van. Előtte: futtassa az Upgrade Statust, vegye fel a contrib pótlást minden eltávolított magbővítményhez, amelyet ténylegesen használ, és győződjön meg róla, hogy a tárhelye kínál PHP 8.5-öt. Utána: számítson rá, hogy minden magállvány-fájl megváltozott, az .htaccess is, tehát az ezekhez fűzött minden testreszabást tudatosan újra kell alkalmazni, nem vakon összefésülni.

Ha egy függőség nem hajlandó feloldódni, a composer why-not drupal/core ^12 megnevezi a blokkolót. Egy modul két főverziójának engedélyezése a composer.json fájlban, például "^6.1 || ^7.0" formában, a szokásos módja annak, hogy áthidalja az átmenet közepén lévő projektet. Ha olyan modulra van szüksége, amelyhez van működő javítás, de nincs címkézett kiadás, a Drupal Lenient Composer végpont pontosan erre való, és ma is karbantartott.

Második útvonal: Drupal 10-ről Drupal 12-re két ugrás

Nincs közvetlen frissítés Drupal 10-ről Drupal 12-re. Az Upgrade Status dokumentációja ezt kifejezetten kimondja, és a 11.4 előtti adatbázis-frissítési útvonal eltávolítása kényszeríti is ki. A Drupal 10.6-ról a Drupal 11.4-re vagy 11.5-re megy, ellenőrzi a webhelyet, és onnan megy tovább a Drupal 12-re.

Rendesen megtervezve ez nem kétszeres munka. A Drupal 10-ről Drupal 11-re tartó ugrás viszi szinte az összes kockázatot, mert ott laknak a contrib modulok kompatibilitási problémái, és ott találkozik az egyedi kód az eltávolított felületekkel. A második ugrás a fentebb leírt kicsi. Azok a csapatok, amelyek mindkettőt egyetlen változtatási ablakba próbálják préselni, utólag rendszerint nem tudják megmondani, melyik kettő közül rontott el valamit.

A működő sorrend az, hogy a Drupal 11-es ugrást most csinálja meg, a webhelyet több hétig futtatja 11.4-en vagy 11.5-ön, hogy a valódi szerkesztőségi és látogatói viselkedés felszínre hozza a furcsaságokat, a Drupal 12-t pedig az új évben veszi, miután a contrib modulok stabil kiadásokat címkéztek rá. Az számít, hogy az első ugrás december előtt megtörténjen, mert az az ugrás emeli le a nem támogatott kódról.

Harmadik útvonal: a Drupal 7 vagy 8 újraépítés, nem frissítés

Minden, ami a Drupal 9-nél régebbi, más gyakorlat. A Drupal 7 támogatása 2025. január 5-én, a Drupal 6-é 2016 februárjában ért véget. Egyik sem frissíthető helyben, mert teljes egészében megelőzik a modern architektúrát. Ezeket migrálják, vagyis új webhely épül aktuális Drupalon, a tartalmat pedig a Migrate felülettel viszik át. Egy Drupal 8-as webhelynek technikailag van helyben frissítési útja, de az négy egymást követő főverzión vezet át, és minden contrib modulnak túl kell élnie mindegyiket, ezért rendszerint olcsóbb azt is újraépítésként kezelni.

A költséget minden uralja, ami nem tartalom. A sablont újraépítik, az egyedi modulokat teljesen más felületre írják át, az integrációkat pedig újrakötik. Tapasztalatunk szerint maga a tartalommigráció általában a költségvetés kisebbik fele, ami az ellenkezője annak, amit a legtöbb tulajdonos vár, amikor árajánlatot kér, és ez az oka annak, hogy ezeket webfejlesztési projektként, nem frissítésként méretezzük.

Ezeknél a webhelyeknél a decemberi határidő máshogy hat, de a Migrate Drupal eltávolítása miatt így is harap. A célnak a Drupal 11-nek kell lennie, nem a Drupal 12-nek, és a Drupal 11 a drupal.org saját dokumentációja szerint 2028 közepéig vagy végéig támogatott. Ez egy Drupal 7-es tulajdonosnak valódi ablakot ad, de kemény véggel záruló ablakot, és 2028-ban indítani egy hathónapos újraépítést egy 2028-as cél eltalálására nem terv.

Mennyibe kerülnek az egyes útvonalak az Egyesült Királyságban

Ezek házon belüli becslések a saját munkánkból, nem közzétett díjszabás, és az egyes sávokon belüli szórást szinte teljesen a contrib modulok állapota mozgatja, nem a webhely mérete. A brit ügynökségek nagyjából 600 és 900 font között számláznak naponta ezért a munkáért. Egy Drupal 11-ről 12-re való frissítés karbantartott webhelyen három-nyolc nap teszteléssel együtt, ami nagyjából 2000 és 6000 font közé esik. Ha ugyanannak a webhelynek elavult contrib moduljai vannak, számoljon két-négy héttel és 6000 és 12 000 font közötti összeggel.

Egy Drupal 10-es webhely mindkét ugrást megfizeti. Jól karbantartva a Drupal 10-ről 11-re tartó ugrás 6000 és 15 000 font közötti, a Drupal 12-es ugrás pedig 2000 és 6000 fonttal told hozzá, tehát összesen 8000 és 21 000 font között, négy-nyolc hét alatt. Elhanyagolva már az első ugrás önmagában 15 000 és 35 000 font közötti, a végösszeg pedig 17 000 és 41 000 font közé esik. Egy Drupal 7-es újraépítés három-hat hónap, és jellemzően 40 000 és 120 000 font közötti, nagy vagy erősen testreszabott webhelyeknél több.

A contrib modulok auditja, amely kijelöli a dátumot

A frissítési projektek ritkán buknak el a magon. A lista tizennegyedik modulján buknak el, azon, amelynek telepítésére senki sem emlékszik, amelynek nincs a következő főverzióval kompatibilis kiadása, és amelynek karbantartója utoljára 2023-ban szólalt meg. Végezze el ezt az auditot, mielőtt dátumot vállal, mert az audit az, ami a dátumot előállítja.

Futtassa az Upgrade Statust, exportálja a jelentést, majd sorolja a moduljait négy vödörbe. Az elsőben azok a projektek vannak, amelyeknek van a célverziót támogató stabil kiadásuk, és ezek semmibe sem kerülnek. A másodikban azok, amelyekhez javítás vagy fejlesztői kiadás van a hibalistán, ezek kevés integrációs munkába kerülnek, és hordozzák a kockázatot, hogy a javítás soha nem érkezik meg. A harmadikban azok, amelyekhez nyitott hibajegy tartozik javítás nélkül, ezekhez valakinek meg kell írnia egyet. A negyedikben azok, amelyekben egyáltalán nincs aktivitás.

A negyedik vödör szabja meg az ütemtervét, és a mérete ma is megismerhető, nem csak novemberben. Egy harminc contrib modult futtató webhely, amelynek a negyedik vödre üres, egyszerű munka. Ugyanaz a webhely négy modullal a negyedik vödörben már más megbízás, más költségvetéssel, és a két árajánlat közti különbséget egy nap szkennelés dönti el.

Mit kezdjen egy elhagyott modullal

Négy őszinte lehetőség van, és a helyes attól függ, mit csinál a modul. Eltávolítja, ha a nyújtott funkciót már nem használják, ami néhány év szerkesztőségi sodródás után gyakrabban igaz, mint a csapatok várnák. Lecseréli egy karbantartott projektre, amely ugyanazt a munkát végzi, elfogadva a vele járó konfigurációs migrációt.

Átveszi a karbantartást, ami a Drupalban valós lehetőség, és kevésbé ijesztő, mint amilyennek hangzik. A drupal.orgnak dokumentált folyamata van arra, hogy valaki egy nem támogatott projekt karbantartója legyen, és egy kis modulnál, amelytől az üzlete függ, az örökbefogadás olcsóbb lehet a cserénél. A költség folyamatos, nem egyszeri, ezért tervezze be őszintén.

Vagy újraírja a viselkedést egy egyedi modulban, arra szűkítve, amit valóban használ. Egy contrib modul mindenki számára megoldja az általános esetet, önnek viszont rendszerint egy keskeny szelet kell belőle. Ezt a szeletet az aktuális felületekre újraírni gyakran kétnapos munka a kéthetes portolás helyett, és véglegesen megszünteti a függőséget. A Drupal fejlesztő felvételéről szóló útmutatónk arról szól, hogyan mérje fel valakinél pontosan ezt az ítélőképességet.

Visszafelé tervezett ütemterv 2026. december 9-től

Induljon a záró dátumból, és a terv megírja magát. Szeptember végéig futtassa le az Upgrade Statust a Drupal 12-re a produkció egy másolatán, és tegye papírra a négy vödröt. Ez két-három napos gyakorlat, és ez az egyetlen dokumentum, amellyel bármi mást őszintén be lehet árazni.

Október közepéig erősítse meg, hogy a tárhelye tud PHP 8.5-öt és az adatbázis-küszöböket, és ha nem, indítsa el a költözést. Döntse el a contrib modulokkal kapcsolatos kérdéseket is, mert mindegyikhez átfutási idő tartozik. November elejéig egy Drupal 10-es webhelyen legyen kész a Drupal 11.4-re vagy 11.5-re frissítés, és a webhely fusson élesben az új ágon.

December elejére már a 12.0.0 kiadását figyeli, nem reagál rá. Ha akkor Drupal 11-en van, vegye a Drupal 12-t 2027 januárjában vagy februárjában, miután a contrib projektek stabil kiadásokat címkéztek rá. A kiadás hetében történő frissítésért nem jár díj, és a Drupal 11.5 továbbra is támogatott lesz. A díj azért jár, hogy ne legyen Drupal 10-en, amikor a közlemények megszűnnek.

Mennyibe kerül a semmittevés

A közvetlen költség az, hogy a Drupal magjának minden, 2026. december 9-e után nyilvánosságra hozott sebezhetősége véglegesen nyitva marad a webhelyén. A Drupal közleménytörténete tartalmaz olyan súlyos távoli kódfuttatási hibákat, amelyeket a közzététel után órákon belül kihasználtak, és egy nyilvános IP-címen futó, javítatlan CMS-t automatizált szkennelés talál meg, nem egy célzott támadó, aki éppen önt választotta.

A közvetett költségek hamarabb jönnek, és általában nagyobbak. Ha egy Cyber Essentials értékelésen elbukik a támogatott szoftverre vonatkozó kontroll, az befolyásolhatja a tanúsítványt megkövetelő szerződésekre való jogosultságot, ami a brit közbeszerzésben gyakori. A contrib modulok abbahagyják a javítások kiadását az ön ágára. Maga a frissítés pedig havonta drágul, mert a kódbázisa és a karbantartott ökoszisztéma közti szakadék úgy nő, hogy senki nem nyúl semmihez.

Van egy csendesebb költség is. Az a webhely, amelyet senkinek sem szabad frissítenie, hajlamos olyan webhellyé válni, amelyet senkinek sem szabad megváltoztatnia, és a funkciófejlesztés leáll, mert minden módosítást egy eltűnőben lévő felületre kellene építeni. Így lesz egy ötéves Drupal webhelyből újraépítés frissítés helyett. Ha ezt a döntést mérlegeli, a Drupal webfejlesztési útmutatónk jobb kiindulópont, mint egy árajánlat.

Két jogos ok a várakozásra

A várakozás két helyzetben védhető, és csak akkor, ha tudatosan vár. Az első az, hogy már Drupal 11.4-en vagy 11.5-ön van. Ezek az ágak támogatottak, ezek a Drupal 12 kijelölt kilövőállásai, és semmi előnye nincs annak, hogy egy vadonatúj főverziót az első heteiben vegyen, miközben a contrib projektek még kiadásokat címkéznek. A 2027 első negyedévéig való várakozás a szakszerű választás, nem a lusta.

A második egy Drupal 7-es webhely, amelynek újraépítése már finanszírozott és ütemezett. A Drupal 7-et Drupal 11-be migrálni, majd rögtön Drupal 12-be, elpazarolt mozgás. Érkezzen meg a Drupal 11-re, futtassa, és vegye a Drupal 12-t később, szokásos karbantartásként.

Ami nem védhető, az az, hogy lefoglalt terv nélkül ül a Drupal 10-en. Ha ez a helyzet, szeptember végéig a minimálisan elfogadható állapot egy szkennelési jelentés, egy megnevezett célág és egy dátum a naptárban. Minden más mozoghat. Ha ezt az értékelést olyasvalakivel akarja elvégeztetni, aki már csinálta, a szoftverfejlesztési csapatunk fix hatókörű munkaként végez verzióauditokat.

Hol kezdje

Először a szkennelést csinálja meg. A létező rossz Drupal frissítési árajánlatok szinte mindegyike enélkül készült, és ezért téves annyi közülük mindkét irányban. Két-három nap Upgrade Status és Drupal Rector kimenet megmondja, hogy a fenti öt költségsáv közül valójában melyikben van, és ez az egyetlen szám többet változtat az igazgatósággal folytatott beszélgetésen, mint bármennyi általános tanács a főverziókról.

A Mecanik elvégzi ezeket az auditokat és az utánuk következő frissítéseket, decemberrel szembenéző Drupal 10-es webhelyeken és 2027-re nyugodtabb váltást tervező Drupal 11-es webhelyeken egyaránt. Az egyedi modulmunka, az integrációk és az elavulások takarítása a szoftverfejlesztési gyakorlatunkhoz tartozik, míg egy újraépítés vagy tárhelyváltás a webfejlesztéshez. Ha a biztonsági helyzet miatt került ez az ön asztalára, kezdje a Drupal biztonsági közleményekről és a valós kockázatról szóló jegyzetünkkel, ha pedig verzióváltás közben az organikus forgalom aggasztja, a Drupal technikai SEO beállításáról szóló írás mondja meg, mit kell védeni.

Gyakran ismételt kérdések

Mikor jelenik meg a Drupal 12, és mikor ér véget a Drupal 10 támogatása? A Drupal 12.0.0 a 2026. december 7-i hétre van ütemezve, a Drupal 11.5.0 kíséretében, a Drupal 10 támogatása pedig 2026. december 9-én ér véget. Mindkét dátum a Drupal mag kiadási menetrendjében szerepel. Ugyanezen a héten véget ér a biztonsági támogatás a 11.3.x és a 10.6.x alverziós ágakon. A Drupal 12.0.0-alpha1 címkézése 2026. szeptember 2-án történt.

Frissíthetek közvetlenül Drupal 10-ről Drupal 12-re? Nem. A Drupal 11.4.0 előtti kiadásokból induló adatbázis-frissítési útvonalat eltávolították a Drupal 12-ből, tehát egy Drupal 10-es webhelynek előbb a Drupal 11.4-re vagy újabbra, majd a Drupal 12-re kell lépnie. A drupal.org a főverzióváltás előtt a 11.5.0 vagy újabb verziót ajánlja. Tervezze két ugrásként, ahol a Drupal 10-ről 11-re tartó ugrás viszi szinte a teljes kockázatot és költséget.

Mik a Drupal 12 rendszerkövetelményei? A Drupal 12 PHP 8.5 verziót igényel, és elejti a PHP 8.4 és korábbi verziók támogatását. Az adatbázis-küszöbök a MySQL 8.0, a MariaDB 10.11, a PostgreSQL 18 és az SQLite 3.45 a json1 kiterjesztéssel. A Symfony 8.1-re, a Guzzle 8.0-ra lép. A Drupal közvetlen üzemeltetése Windowson éles környezetben elavult, bár a helyi fejlesztéshez a Windows továbbra is támogatott.

Mi az igazi újdonság a Drupal 12-ben a Drupal 11.5-höz képest? Szinte semmi, és ez szándékos. Az alpha1 kiadási jegyzete szerint a 12.0.x szinte azonos a 11.5.x ággal, leszámítva az eltávolított elavult kódot, a megemelt függőségi főverziókat és a magasabb rendszerkövetelményeket. Az említésre méltó viselkedésbeli változások az argon2id mint alapértelmezett jelszóhasító algoritmus, a HTMX 4-es verzióra lépése, és a mag robots.txt fájlja, amely blokkolja a lekérdezési paraméteres keresési találati oldalakat.

Mennyibe kerül egy Drupal 12 frissítés az Egyesült Királyságban? Karbantartott Drupal 11-es webhelyen három-nyolc nap munka a szokásos brit ügynökségi díjakon, napi 600 és 900 font között, tehát nagyjából 2000 és 6000 font között. Egy Drupal 10-es webhely mindkét ugrást megfizeti, jól karbantartva 8000 és 21 000 font közé, elhanyagolva 17 000 és 41 000 font közé esik. Egy Drupal 7-es újraépítés három-hat hónap, és jellemzően 40 000 és 120 000 font közötti. Ezek házon belüli becslések, nem közzétett díjszabás.