Drupal 12: Ce Se Schimbă Și Când Să Vă Mutați

Drupal 12 este programat pentru săptămâna de 7 decembrie 2026, iar Drupal 10 ajunge la sfârșitul suportului pe 9 decembrie 2026. Ambele date stau pe aceeași pagină a calendarului de lansări al nucleului Drupal, la două rânduri distanță, și aproape nimeni dintre cei care administrează un site Drupal 10 nu le-a observat. Prima versiune alpha a noii versiuni majore a fost etichetată pe 2 septembrie 2026, așa că forma lansării este acum un fapt consemnat, nu o speculație.

Această coliziune este toată povestea. Sosirea unei versiuni majore nu este de obicei urgentă pentru cine deține un site, fiindcă poți rămâne un an sau doi pe majora precedentă cât timp ecosistemul recuperează. De data aceasta, majora precedentă încetează să mai primească alerte de securitate exact în săptămâna în care apare cea nouă, iar asta transformă un eveniment tehnic într-un termen limită cu tăiș de conformitate.

Urmează calendarul așa cum îl publică drupal.org, ce se schimbă efectiv în cod, ce impun găzduirii noile praguri de platformă, cele trei trasee realiste de upgrade cu benzile lor de cost și un plan construit înapoi din decembrie. Partea liniștitoare vine devreme: un salt de versiune majoră în Drupal înseamnă mai ales ștergere, nu reinventare.

Când apare Drupal 12 și trebuie să mă mut? Drupal 12.0.0 este programat pentru săptămâna de 7 decembrie 2026, lansat împreună cu Drupal 11.5.0. Drupal 10 ajunge la sfârșitul suportului două zile mai târziu, pe 9 decembrie 2026, iar după acea dată nu se mai emite nicio alertă de securitate pentru el. Un site Drupal 11 are în față un upgrade mic. Un site Drupal 10 trebuie să treacă mai întâi prin Drupal 11.4 sau mai nou, deci munca înseamnă doi pași, nu unul.

Cele două date care vă decid următoarele șase luni

Managerii de lansare publică întregul ciclu din timp, iar cel actual este neobișnuit de ordonat. Drupal 11.4.0 a apărut în săptămâna de 29 iunie 2026, iar acea lansare a încheiat suportul de securitate atât pentru Drupal 11.2.x, cât și pentru Drupal 10.5.x. Eticheta 12.0.0-alpha1 a plecat pe 2 septembrie 2026. Cerințele pentru beta trebuiau să fie complete până pe 11 septembrie 2026, cu 12.0.0-beta1 și 11.5.0-beta1 în săptămâna de 14 septembrie și versiunile candidat în săptămâna de 9 noiembrie.

Apoi săptămâna de 7 decembrie face trei lucruri deodată. Apare Drupal 12.0.0, apare alături Drupal 11.5.0 și se încheie suportul de securitate pentru Drupal 11.3.x și Drupal 10.6.x. Două zile mai târziu, pe 9 decembrie 2026, Drupal 10 în ansamblu ajunge la sfârșitul suportului și nu se va mai face nicio lansare a lui.

De ce Drupal 10 și Drupal 12 ajung în aceeași săptămână

Aceasta este politică, nu coincidență. Prezentarea procesului de lansare stabilește că versiunile majore apar o dată la doi ani, în anii pari, și că fiecare majoră este susținută minimum patru ani, până când mai apar încă două majore. Drupal 10.0.0 a apărut pe 15 decembrie 2022. Drupal 11 a venit în august 2024, iar Drupal 12 vine în decembrie 2026, adică a doua majoră următoare, și au trecut patru ani. Ceasul a expirat exact conform planului.

Aceeași politică guvernează versiunile minore. Fiecare minoră este susținută un an, cu corecții de erori și de securitate în primele șase luni și doar corecții de securitate în ultimele șase. De aceea numai 10.6.x mai primește alerte astăzi și de aceea 11.3.x își pierde acoperirea în clipa în care apare 11.5.0.

Drupal 11 nu se oprește când începe Drupal 12. Lansarea versiunii 11.5.0 în aceeași săptămână deschide ceea ce politica numește faza de suport pe termen lung, în care majora precedentă păstrează o minoră aliniată la aceeași interfață publică, trece pe o lansare LTS de Symfony și primește o minoră de întreținere la fiecare șase luni, cu domeniu tot mai restrâns. Drupal.org nu publică o dată fermă de sfârșit al suportului pentru Drupal 11, însă propria documentație despre extensiile depreciate spune că Drupal 11 va fi susținut până la mijlocul sau sfârșitul lui 2028.

Câte site-uri stau încă pe Drupal 10

Cifrele sunt publice și nu sunt comode. Statisticile de utilizare a nucleului de pe drupal.org, pentru săptămâna care începe pe 23 august 2026, înregistrează 468.877 de site-uri care raportează o versiune de nucleu. Dintre ele, 205.568 sunt pe o ramură oarecare de Drupal 10 și 168.857 pe Drupal 11. Aproximativ 44 la sută din baza instalată raportoare rulează versiunea care în decembrie nu mai primește alerte.

Cifra mai tăioasă stă în interiorul acesteia. Doar 10.6.x mai are acoperire de securitate, iar 10.6.x adună 139.911 dintre aceste site-uri. Celelalte 65.657 sunt pe versiuni de la 10.0 la 10.5, ceea ce înseamnă că rulează deja azi, în septembrie, o minoră fără suport, fără să aștepte decembrie.

Aceste numărători vin de la site-uri care raportează voluntar prin modulul Update Status, deci populația reală este mai mare și înclină la fel. Citirea practică este că foarte multe organizații vor încerca să rezerve aceeași muncă în același trimestru, iar capacitatea agențiilor în octombrie și noiembrie va fi constrângerea, nu codul.

Ce înseamnă cu adevărat sfârșitul suportului pentru un site Drupal

Sfârșitul suportului nu este un întrerupător care strică site-ul. Instalarea voastră de Drupal 10 va servi pagini pe 10 decembrie exact cum o făcea pe 8 decembrie. Ce se schimbă este că echipa de securitate Drupal încetează să mai publice alerte și corecții pentru acel cod, deci din acea dată orice vulnerabilitate nou descoperită în nucleul Drupal 10 rămâne permanent deschisă.

Al doilea efect este mai lent și face mai multe pagube. Acoperirea de securitate a unui modul contribuit depinde de existența unei lansări stabile pe o ramură de nucleu susținută, așa că pe măsură ce mentenanții renunță la compatibilitatea cu Drupal 10, și modulele de pe site-ul vostru părăsesc discret procesul de alerte. Nu primiți nicio notificare când se întâmplă. Modulul pur și simplu nu mai apare în lansările de securitate, iar raportul actualizărilor disponibile de pe propriul vostru site arată în continuare verde.

Al treilea efect este că ieșirea devine mai scumpă cu cât amânați mai mult. Un site Drupal 10 actualizat în noiembrie este actualizat pe o ramură de nucleu întreținută, cu o cale de actualizare funcțională. Același site actualizat în iunie următor este un proiect de salvare, fiindcă modulele contribuite de care depinde au avut încă șase luni ca să meargă mai departe fără el.

Cyber Essentials, asigurări și clauze contractuale

Aici un CMS fără suport încetează să fie o chestiune de inginerie. Cerințele Cyber Essentials pentru infrastructura IT v3.3 ale NCSC, datate aprilie 2026, prevăd că orice software aflat pe dispozitivele din perimetru trebuie să fie licențiat și susținut și trebuie eliminat de pe dispozitive când rămâne fără suport, ori scos din perimetru printr-un subset definit care blochează orice trafic dinspre și înspre internet. Controlul se aplică serverelor, IaaS, PaaS și SaaS, deci o instalare Drupal pe un server din perimetru intră clar sub el.

Un site Drupal 10 public nu poate fi izolat de internet, așa că după 9 decembrie 2026 cele două răspunsuri disponibile sunt să îl actualizați sau să acceptați că nu trece acel control. Dacă organizația voastră deține Cyber Essentials sau Cyber Essentials Plus și îl reînnoiește anual, este o întrebare care vi se va pune în scris la următoarea evaluare.

Fiți prudenți cu ce afirmați dincolo de asta. Dacă o anumită poliță de asigurare cibernetică sau un contract cu un client este afectat depinde în întregime de formularea lui, iar clauzele care contează cer de obicei software susținut sau versiuni întreținute de furnizor, în loc să numească Drupal. Citiți-vă propria poliță și propriile contracte-cadru înainte de decembrie, nu după un incident, fiindcă acela este momentul ieftin pentru a afla.

Ce se schimbă de fapt în Drupal 12

Foarte puțin, iar acesta este răspunsul cinstit și util. Notele de lansare pentru 12.0.0-alpha1 o spun direct: 12.0.x va fi aproape identică cu 11.5.x, cu excepția faptului că se elimină codul depreciat, inclusiv module depreciate întregi, că dependențele urcă la versiuni majore noi și că cerințele de sistem cresc. Pentru orice altă schimbare, notele vă trimit la ramura 11.5.x.

Există câteva schimbări reale de comportament care merită știute. Algoritmul implicit de hashing al parolelor trece la argon2id, cu bcrypt disponibil prin parametrii de kernel acolo unde argon2 lipsește. Fișierul robots.txt din nucleu blochează acum paginile de rezultate ale căutării care poartă parametri de interogare, ceea ce oprește motoarele să parcurgă combinații fațetate infinite, iar site-urile cu un robots.txt personalizat trebuie să adauge acele reguli de mână. HTMX, pe care nucleul îl livrează deja, trece de la versiunea 2 la versiunea 4 pentru beta1.

Mai este una ușor de ratat. Găzduirea Drupal direct pe Windows într-un mediu de producție este depreciată în Drupal 12, pe motiv că nu există un mediu de testare Windows automatizat și că puțini dezvoltatori testează pe el. Windows rămâne susținut pentru dezvoltarea locală. Dacă rulați producția pe Windows, aceasta este o decizie de găzduire de luat în lunile următoare, nu o modificare de cod.

Extensiile care părăsesc nucleul

Drupal scoate de ani buni module înguste din nucleu în proiecte contribuite, iar Drupal 12 continuă asta. Notele alpha1 listează ca eliminate Ban, Contact, Field Layout, History, Settings Tray, Shortcut și Telephone, alături de tema Stable 9. Și pluginul de câmp Text with Summary a plecat într-un modul contribuit propriu. Ban fusese depreciat încă din 11.3, Contact, Field Layout, History și Telephone în 11.4, iar Settings Tray, Shortcut și Text with Summary în 11.5.

Două dintre ele vor surprinde. Shortcut și Settings Tray sunt funcții administrative pe care foarte multe echipe editoriale le folosesc zilnic fără să le considere vreodată opționale, iar Settings Tray susține în special configurarea blocurilor direct în pagină, pe care editorii se bazează.

Mecanica de a gestiona asta contează mai mult decât lista. Mișcarea corectă este să adăugați versiunea contribuită în cerințele voastre Composer înainte de upgrade, nu să dezinstalați modulul. Dezinstalarea distruge configurația extensiei, iar descoperirea de module din Drupal se uită în nucleu ultima dată, deci imediat ce proiectul contribuit este prezent, Drupal îl folosește pur și simplu pe acela. Rețineți și că Drush poate ocoli avertismentele din update.php despre extensiile lipsă, iar eșecul apare abia după aceea, ca erori în raportul de stare.

Pierderea Migrate Drupal este schimbarea care doare cel mai tare

Modulele Migrate Drupal și Migrate Drupal UI sunt eliminate în Drupal 12 și, spre deosebire de restul, nu sunt mutate într-un proiect contribuit. Drupal 12 păstrează interfața Migrate și pluginurile de destinație pentru Drupal modern, dar nu păstrează pluginurile sursă pentru Drupal 6 și Drupal 7.

Recitiți fraza dacă dețineți un site Drupal 7. Uneltele care citesc o bază de date Drupal veche și o scriu într-una modernă există în Drupal 11 și nu există în Drupal 12. Indicația de pe drupal.org este explicită: site-urile pe Drupal 6 sau Drupal 7 care intenționează să folosească interfața de migrare trebuie să migreze în continuare către Drupal 11, apoi să folosească procesul obișnuit de actualizare pentru a trece de la Drupal 11 la Drupal 12.

Asta transformă o intenție vagă într-o constrângere strictă de ordine. O reconstrucție de Drupal 7 care aterizează după ieșirea din suport a lui Drupal 11 va trebui fie să își scrie propriile pluginuri sursă, fie să restaureze un nucleu mai vechi ca să ruleze migrarea într-un mediu de unică folosință, fie să exporte și să reimporte conținutul pe alte căi. Toate trei costă mai mult decât migrarea în Drupal 11 cât timp Drupal 11 este o țintă curentă și întreținută. Ghidul nostru despre costurile, opțiunile și termenele unei migrări Drupal descrie în detaliu forma acelei munci.

Noile praguri de dependențe

O versiune majoră este momentul în care Drupal are voie să își ridice cerințele de platformă, iar Drupal 12 folosește acea permisiune pe toată linia. Aceste praguri sunt partea din upgrade cu care nu se negociază, fiindcă sunt impuse la instalare.

PHP 8.5, și nimic mai vechi

Drupal 12 cere PHP 8.5. Tabelul cerințelor PHP arată Drupal 12.0 susținând PHP 8.5 și refuzând tot ce este sub, în timp ce Drupal 11.3 și 11.4 acceptă 8.3, 8.4 și 8.5. Acea suprapunere este ruta voastră de migrare: treceți site-ul pe PHP 8.5 cât timp încă rulează Drupal 11.4, confirmați că se comportă bine, apoi schimbați Drupal.

Pragul este generos, nu punitiv. PHP 8.5 a apărut pe 20 noiembrie 2025, iar pagina versiunilor susținute de pe php.net fixează suportul activ până la 31 decembrie 2027 și cel de securitate până la 31 decembrie 2029. Aterizarea acolo cumpără trei ani până când discuția aceasta revine.

Baze de date și Symfony

Cerințele pentru serverul de baze de date la Drupal 12 sunt MySQL 8.0 sau mai nou, MariaDB 10.11 sau mai nou, PostgreSQL 18 sau mai nou și SQLite 3.45 cu extensia json1. Site-urile pe PostgreSQL ar trebui să verifice acest prag cu grijă deosebită, fiindcă notele alpha1 spun PostgreSQL 19, în timp ce pagina de cerințe și codul instalatorului spun amândouă 18. Verificați din nou la beta1 înainte să rezervați lucrări pe bază.

Dedesubt, Symfony trece de la 7.4 la 8.1, iar Guzzle de la 7 la 8. Se renunță la suportul pentru mai multe versiuni majore vechi de biblioteci, printre care doctrine/lexer 2, egulias/email-validator 3 și guzzlehttp/psr7 2. Codul propriu care tipizează direct clase Symfony este locul unde asta iese la iveală.

Ce impun pragurile găzduirii voastre

Saltul de MariaDB este cel care prinde pe picior greșit găzduirile partajate și administrate. Drupal 11 acceptă MariaDB 10.6, a cărei întreținere comunitară s-a încheiat pe 6 iulie 2026 potrivit politicii de întreținere MariaDB, deci un site Drupal 11 poate sta în prezent, perfect legitim, pe un motor de bază de date fără suport. Drupal 12 ridică pragul la 10.11, întreținută până pe 16 februarie 2028. Dacă găzduirea voastră nu oferă azi PHP 8.5 și MariaDB 10.11, mutarea trebuie să se întâmple înaintea schimbării de Drupal, iar tocmai această reordonare transformă o treabă de două săptămâni în una de două luni. Nota noastră despre ce rulează Drupal cu adevărat bine acoperă partea de platformă.

De ce modelul de deprecare face Drupal 12 abordabil

Iată mecanismul pe care celor mai mulți deținători de site-uri nu li l-a explicat nimeni și care este motivul pentru care majorele Drupal nu mai sperie. Politica upgrade-urilor continue angajează nucleul într-o promisiune simplă: următoarea lansare majoră are aceeași interfață publică precum ultima minoră a majorei precedente. Interfețele noi se adaugă în minore, cele vechi sunt marcate ca depreciate în minore, iar ștergerea se întâmplă numai la granița de majoră.

Consecința practică merită spusă pe șleau. Dacă propriul vostru cod și modulele voastre contribuite rulează pe Drupal 11.5 fără avertismente de depreciere, rulează și pe Drupal 12. Upgrade-ul încetează să fie o rescriere și devine o ridicare de dependențe plus o actualizare de bază de date, fiindcă tot ce s-ar fi rupt v-a fost deja raportat cu luni înainte, ca un avertisment pe care îl puteați rezolva pe îndelete.

Tot de aceea notele de lansare spun să actualizați mai întâi la 11.4 sau mai nou și recomandă apăsat 11.5. Calea de actualizare a bazei de date din lansările anterioare versiunii 11.4.0 a fost scoasă complet din Drupal 12, deci un site pe 11.3 sau mai vechi nu are nicio rută către 12 până nu urcă pe ramura 11. Nu este un sfat, este o cale de cod care lipsește.

Uneltele care raportează deprecările

Două proiecte fac treaba și amândouă sunt întreținute în prezent. Upgrade Status este scanerul care acoperă tot site-ul. Îl instalați pe site-ul de pe care faceți upgrade, nu pe cel către care faceți upgrade, fiindcă interfețele depreciate trebuie să existe ca el să găsească apeluri la ele. Verifică dacă mediul vostru satisface cerințele de sistem ale majorei următoare, compară proiectele voastre contribuite cu actualizările disponibile, rulează PHPStan pentru utilizarea de interfețe PHP depreciate și citește șabloanele Twig, fișierele info.yml, composer.json și cheile de configurare depreciate. Lansarea 5.0.0-alpha3, din 2 iulie 2026, declară compatibilitate cu Drupal 10.4, 11 și 12.

Clasifică și ce găsește, iar aceasta este partea care economisește bani. Problemele sunt împărțite între cele pe care le poate rezolva o mașină și cele care cer un om, așa că puteți evalua jumătatea manuală înainte să vă angajați la o dată. Rulează sub Drush ca upgrade_status:analyze, iar ieșirea lui JSON în format Code Climate se conectează la GitLab CI.

Drupal Rector este cealaltă jumătate. Rescrie deprecările reparabile mecanic în modulele și temele voastre proprii, cu opțiunea --dry-run pentru a vedea diferențele în avans. Versiunea 1.1.2 a apărut pe 7 august 2026. Cu amândouă la un loc, un dezvoltator competent poate produce un raport de pregătire credibil pentru un site mediu în două sau trei zile.

Traseul unu: de la Drupal 11 la Drupal 12

Dacă sunteți pe Drupal 11.4 sau 11.5 cu module contribuite la zi, este o bucată mică de muncă. Ghidul oficial de upgrade este în cea mai mare parte comenzi Composer: cereți metapachetele versiunii 12 cu --no-update, scoateți orice cerință explicită de drupal/core, rulați composer update --dry-run, apoi rulați-l pe bune și aplicați actualizările de bază de date cu drush updatedb.

Munca adevărată stă de o parte și de alta. Înainte: rulați Upgrade Status, adăugați înlocuitorii contribuiți pentru fiecare extensie de nucleu eliminată pe care chiar o folosiți și confirmați că găzduirea oferă PHP 8.5. După: așteptați-vă ca fiecare fișier de schelet al nucleului să se fi schimbat, inclusiv .htaccess, deci orice personalizare făcută pe ele trebuie reaplicată deliberat, nu îmbinată orbește.

Când o dependență refuză să se rezolve, composer why-not drupal/core ^12 numește blocajul. Permiterea a două majore ale unui modul în composer.json, de pildă "^6.1 || ^7.0", este modul standard de a face punte pentru un proiect aflat în tranziție. Dacă aveți nevoie de un modul care are un patch funcțional, dar nicio lansare etichetată, endpointul Composer Drupal Lenient există exact pentru asta și este încă întreținut.

Traseul doi: de la Drupal 10 la Drupal 12 sunt doi pași

Nu există upgrade direct de la Drupal 10 la Drupal 12. Documentația Upgrade Status o spune explicit, iar eliminarea căii de actualizare a bazei de date dinainte de 11.4 o impune. Mergeți de la Drupal 10.6 la Drupal 11.4 sau 11.5, verificați site-ul, apoi mergeți de acolo la Drupal 12.

Planificat cum trebuie, nu înseamnă dublu de muncă. Pasul de la Drupal 10 la Drupal 11 duce aproape tot riscul, fiindcă acolo trăiesc problemele de compatibilitate ale modulelor contribuite și acolo întâlnește codul propriu interfețe eliminate. Al doilea pas este cel mic, descris mai sus. Echipele care încearcă să comprime ambii pași într-o singură fereastră de schimbare ajung de obicei să nu mai poată spune care dintre ei a stricat ceva.

Ordinea care funcționează este să faceți acum pasul spre Drupal 11, să lăsați site-ul pe 11.4 sau 11.5 mai multe săptămâni ca să scoată la iveală ciudățenii comportamentul real al redacției și al traficului, și să luați Drupal 12 în noul an, după ce modulele contribuite au etichetat lansări stabile față de el. Ce contează este ca primul pas să se întâmple înainte de decembrie, fiindcă el este pasul care vă scoate de pe cod fără suport.

Traseul trei: Drupal 7 sau 8 este o reconstrucție, nu un upgrade

Orice este mai vechi decât Drupal 9 înseamnă un exercițiu diferit. Drupal 7 a ajuns la sfârșitul suportului pe 5 ianuarie 2025, iar Drupal 6 în februarie 2016. Niciunul nu se actualizează pe loc, fiindcă preced complet arhitectura modernă. Ele se migrează, adică se construiește un site nou pe Drupal curent, iar conținutul este mutat în el cu interfața Migrate. Un site Drupal 8 are tehnic o rută pe loc, dar ea trece prin patru majore consecutive și fiecare modul contribuit trebuie să supraviețuiască fiecăreia, așa că de obicei este mai ieftin să îl tratați tot ca pe o reconstrucție.

Costul este dominat de tot ce nu este conținut. Tema se reconstruiește, modulele proprii se rescriu pe o interfață complet diferită, iar integrările se reconectează. Din experiența noastră, migrarea conținutului în sine este de obicei jumătatea mai mică a bugetului, ceea ce este opusul a ce așteaptă majoritatea deținătorilor când cer o ofertă, și este motivul pentru care încadrăm aceste proiecte drept dezvoltare web, nu drept upgrade-uri.

Pentru aceste site-uri termenul din decembrie acționează altfel, dar tot mușcă, din cauza eliminării Migrate Drupal. Ținta voastră trebuie să fie Drupal 11, nu Drupal 12, iar Drupal 11 este susținut până la mijlocul sau sfârșitul lui 2028, potrivit documentației proprii de pe drupal.org. Asta dă unui deținător de Drupal 7 o fereastră reală, dar o fereastră cu un capăt ferm, iar pornirea în 2028 a unei reconstrucții de șase luni ca să prindeți o țintă din 2028 nu este un plan.

Cât costă fiecare traseu în Regatul Unit

Acestea sunt estimări interne, nu tarife publicate, iar diferența din fiecare bandă vine aproape numai din sănătatea modulelor contribuite, nu din mărimea site-ului. Agențiile britanice facturează între 600 și 900 de lire pe zi. Un upgrade de la Drupal 11 la 12 pe un site întreținut înseamnă trei până la opt zile, testare inclusă, adică în jur de 2.000 până la 6.000 de lire. Când același site are module contribuite învechite, socotiți două până la patru săptămâni și 6.000 până la 12.000 de lire.

Un site Drupal 10 plătește ambii pași. Bine întreținut, pasul de la Drupal 10 la 11 costă 6.000 până la 15.000 de lire, iar pasul spre Drupal 12 adaugă 2.000 până la 6.000 de lire, deci 8.000 până la 21.000 de lire în total, pe patru până la opt săptămâni. Neglijat, numai primul pas urcă la 15.000 până la 35.000 de lire, iar totalul aterizează între 17.000 și 41.000 de lire. O reconstrucție de Drupal 7 durează trei până la șase luni și costă de obicei 40.000 până la 120.000 de lire, mai mult pentru site-uri mari sau foarte personalizate.

Auditul modulelor contribuite care vă fixează data

Proiectele de upgrade mor rareori din cauza nucleului. Mor la al paisprezecelea modul din listă, cel de a cărui instalare nu își amintește nimeni, care nu are nicio lansare compatibilă cu majora următoare și un mentenant care a comentat ultima oară în 2023. Faceți acest audit înainte să vă angajați la o dată, fiindcă auditul este cel care produce data.

Rulați Upgrade Status, exportați raportul, apoi împărțiți modulele în patru găleți. Prima cuprinde proiectele cu o lansare stabilă care susține majora țintă, iar acestea nu costă nimic. A doua cuprinde proiectele cu un patch sau o lansare de dezvoltare în coada de probleme, care cer puțină muncă de integrare și poartă riscul ca patch-ul să nu ajungă niciodată. A treia cuprinde proiectele cu o problemă deschisă și niciun patch, pentru care trebuie ca cineva să scrie unul. A patra cuprinde proiectele fără nicio activitate.

A patra găleată vă fixează calendarul, iar mărimea ei se poate afla azi, nu în noiembrie. Un site cu treizeci de module contribuite și nimic în a patra găleată este o treabă simplă. Același site cu patru module în a patra găleată este un alt angajament, cu alt buget, iar diferența dintre cele două oferte se joacă pe o zi de scanare.

Ce faceți cu un modul abandonat

Există patru opțiuni cinstite, iar cea potrivită depinde de ce face modulul. Îl eliminați, dacă funcția pe care o oferă nu mai este folosită, ceea ce se dovedește adevărat mai des decât se așteaptă echipele după câțiva ani de derivă editorială. Îl înlocuiți cu un proiect întreținut care face aceeași treabă, acceptând migrarea de configurare care vine la pachet.

Preluați mentenanța, care în Drupal este o opțiune reală și mai puțin intimidantă decât sună. Drupal.org are un proces documentat pentru a deveni mentenant al unui proiect fără suport, iar pentru un modul mic de care depinde afacerea voastră, adoptarea poate fi mai ieftină decât înlocuirea. Costul este recurent, nu unic, deci treceți-l cinstit în buget.

Sau reimplementați comportamentul într-un modul propriu, limitat la ce folosiți efectiv. Un modul contribuit rezolvă cazul general pentru toată lumea, în timp ce vouă vă trebuie de obicei o felie îngustă din el. Reimplementarea acelei felii pe interfețele actuale înseamnă deseori două zile de muncă față de două săptămâni de portare, și scoate dependența definitiv. Îndrumarul nostru despre angajarea unui dezvoltator Drupal arată cum evaluați pe cineva exact pe acest tip de judecată.

Un calendar înapoi de la 9 decembrie 2026

Porniți de la data finală și planul se scrie singur. Până la finalul lui septembrie, rulați Upgrade Status pe o copie a producției, cu ținta Drupal 12, și puneți cele patru găleți pe hârtie. Este un exercițiu de două sau trei zile și este singurul document care vă lasă să evaluați cinstit orice altceva.

Până la mijlocul lui octombrie, confirmați că găzduirea poate livra PHP 8.5 și pragurile de bază de date și porniți mutarea dacă nu poate. Decideți și întrebările despre modulele contribuite, fiindcă fiecare are atașat un termen de așteptare. Până la începutul lui noiembrie, pe un site Drupal 10 upgrade-ul la Drupal 11.4 sau 11.5 trebuie încheiat, cu site-ul rulând pe noua ramură în producție.

Până la începutul lui decembrie priviți lansarea 12.0.0, în loc să reacționați la ea. Dacă atunci sunteți pe Drupal 11, luați Drupal 12 în ianuarie sau februarie 2027, după ce proiectele contribuite au etichetat lansări stabile față de el. Nu există niciun premiu pentru un upgrade făcut în săptămâna lansării, iar Drupal 11.5 va rămâne susținut. Premiul este pentru a nu fi pe Drupal 10 când se opresc alertele.

Cât costă să nu faceți nimic

Costul direct este că orice vulnerabilitate a nucleului Drupal dezvăluită după 9 decembrie 2026 rămâne deschisă pe site-ul vostru permanent. Istoricul de alerte al Drupal cuprinde probleme de execuție de cod la distanță suficient de grave încât să fie exploatate în câteva ore de la publicare, iar un CMS nepetecit pe o adresă IP publică este găsit de scanări automate, nu de un atacator țintit care v-a ales pe voi.

Costurile indirecte vin mai devreme și de obicei sunt mai mari. Picarea controlului privind software-ul susținut la o evaluare Cyber Essentials poate afecta eligibilitatea pentru contracte care cer certificarea, ceea ce în achizițiile publice britanice este ceva obișnuit. Modulele contribuite încetează să mai livreze corecții pentru ramura voastră. Iar upgrade-ul însuși devine mai scump în fiecare lună, fiindcă distanța dintre baza voastră de cod și ecosistemul întreținut crește fără ca nimeni să atingă nimic.

Există și un cost mai tăcut. Un site pe care nimănui nu îi este permis să îl actualizeze tinde să devină un site pe care nimănui nu îi este permis să îl schimbe, iar munca la funcționalități se oprește, fiindcă orice modificare ar trebui scrisă pe o interfață care dispare. Așa ajunge un site Drupal de cinci ani o reconstrucție în loc de un upgrade. Dacă cântăriți această decizie, ghidul nostru de dezvoltare web cu Drupal este un punct de plecare mai bun decât o ofertă.

Două motive legitime de a aștepta

Așteptarea se poate apăra în două situații și numai dacă așteptați deliberat. Prima este că sunteți deja pe Drupal 11.4 sau 11.5. Acele ramuri sunt susținute, sunt rampa de lansare gândită pentru Drupal 12 și nu există niciun avantaj în a lua o majoră nou-nouță în primele ei săptămâni, cât timp proiectele contribuite încă etichetează lansări. Așteptarea până în primul trimestru din 2027 este alegerea profesionistă, nu cea comodă.

A doua este un site Drupal 7 cu o reconstrucție deja finanțată și programată. Migrarea Drupal 7 în Drupal 11 și imediat după în Drupal 12 este mișcare irosită. Aterizați pe Drupal 11, rulați-l și luați Drupal 12 mai târziu, ca întreținere obișnuită.

Ce nu se poate apăra este să stați pe Drupal 10 fără un plan rezervat. Dacă acesta este cazul vostru, poziția minimă acceptabilă până la finalul lui septembrie este un raport de scanare, o ramură țintă cu nume și o dată în calendar. Orice altceva se poate mișca. Dacă vreți acea evaluare făcută de cineva care a mai condus-o, echipa noastră de dezvoltare software face audituri de versiune ca lucrare cu domeniu fix.

De unde începeți

Faceți întâi scanarea. Aproape orice ofertă proastă de upgrade Drupal care există a fost produsă fără ea, și de aceea atât de multe greșesc în ambele direcții. Două sau trei zile de rezultate de la Upgrade Status și Drupal Rector vă spun în care dintre cele cinci benzi de cost de mai sus vă aflați cu adevărat, iar acel singur număr schimbă discuția cu consiliul vostru mai mult decât orice sfat general despre versiuni majore.

Mecanik face aceste audituri și upgrade-urile care urmează, atât pe site-uri Drupal 10 care au decembrie în față, cât și pe site-uri Drupal 11 care plănuiesc o mutare mai calmă în 2027. Munca la modulele proprii, integrările și curățarea deprecărilor stau la practica noastră de dezvoltare software, în timp ce o reconstrucție sau o mutare de găzduire aparține dezvoltării web. Dacă postura de securitate este motivul pentru care subiectul a ajuns pe biroul vostru, începeți cu nota noastră despre alertele de securitate Drupal și riscul real, iar dacă traficul organic vă îngrijorează în timpul unei schimbări de versiune, articolul despre configurarea tehnică SEO pentru Drupal arată ce trebuie protejat.

Întrebări frecvente

Când apare Drupal 12 și când se încheie suportul pentru Drupal 10? Drupal 12.0.0 este programat pentru săptămâna de 7 decembrie 2026, lansat împreună cu Drupal 11.5.0, iar Drupal 10 ajunge la sfârșitul suportului pe 9 decembrie 2026. Ambele date sunt publicate în calendarul de lansări al nucleului Drupal. În aceeași săptămână se încheie suportul de securitate pentru ramurile minore 11.3.x și 10.6.x. Drupal 12.0.0-alpha1 a fost etichetat pe 2 septembrie 2026.

Pot face upgrade direct de la Drupal 10 la Drupal 12? Nu. Calea de actualizare a bazei de date din lansările anterioare versiunii Drupal 11.4.0 a fost scoasă din Drupal 12, deci un site Drupal 10 trebuie să treacă întâi la Drupal 11.4 sau mai nou și apoi la Drupal 12. Drupal.org recomandă 11.5.0 sau mai sus înainte de schimbarea de majoră. Planificați doi pași, pasul de la Drupal 10 la 11 ducând aproape tot riscul și tot costul.

Care sunt cerințele de sistem ale Drupal 12? Drupal 12 cere PHP 8.5 și renunță la suportul pentru PHP 8.4 și versiunile anterioare. Pragurile de bază de date sunt MySQL 8.0, MariaDB 10.11, PostgreSQL 18 și SQLite 3.45 cu extensia json1. Symfony trece la 8.1, iar Guzzle la 8.0. Găzduirea Drupal direct pe Windows în producție este depreciată, deși Windows rămâne susținut pentru dezvoltarea locală.

Ce este cu adevărat nou în Drupal 12 față de Drupal 11.5? Aproape nimic, și asta este intenționat. Notele de lansare alpha1 spun că 12.0.x este aproape identică cu 11.5.x, în afară de codul depreciat eliminat, versiunile majore de dependențe ridicate și cerințele de sistem crescute. Schimbările de comportament care merită reținute sunt argon2id ca algoritm implicit de hashing al parolelor, HTMX care trece la versiunea 4 și un robots.txt din nucleu care blochează paginile de rezultate ale căutării cu parametri de interogare.

Cât costă un upgrade la Drupal 12 în Regatul Unit? Pe un site Drupal 11 întreținut, trei până la opt zile de muncă la tarifele obișnuite ale agențiilor britanice, de 600 până la 900 de lire pe zi, deci aproximativ 2.000 până la 6.000 de lire. Un site Drupal 10 plătește ambii pași și aterizează între 8.000 și 21.000 de lire când este bine întreținut și între 17.000 și 41.000 de lire când este neglijat. O reconstrucție de Drupal 7 durează trei până la șase luni și costă de obicei 40.000 până la 120.000 de lire. Acestea sunt estimări interne, nu tarife publicate.