End-of-lifedatum van Drupal 7 is een jaar opgeschoven naar 1 november 2023

De end-of-lifedatum voor Drupal 7 is opnieuw een jaar opgeschoven. De ondersteuning voor het cms eindigt pas op 1 november 2023, een jaar later dan oorspronkelijk gepland. Volgens de Drupal Foundation wordt de software nog te veel gebruikt.

Drupal 7 is vanaf 1 november 2023 end-of-life, schrijven de ontwikkelaars van de Drupal Foundation, maar de organisatie houdt de mogelijkheid open dat nog later te doen. De stichting neemt die beslissing in juli van dat jaar. De end-of-lifedatum wordt vanaf dan jaarlijks opnieuw geëvalueerd. "Factoren die we daarin meenemen, zijn community-ondersteuning, gebruik van Drupal 7 en actieve maintainers", schrijven de ontwikkelaars.

Drupal 7 wordt volgens de makers nog steeds veel gebruikt. Een meerderheid van de websites waar het cms op draait, draait op versie 7, hoewel Drupal 9 inmiddels ook al uit is. "Drupal 9 wordt goed onderhouden, is veilig, stabiel en vol met functies, maar veel organisaties zijn nog afhankelijk van Drupal 7", zeggen de makers. "Hoewel deze gebruikers alvast plannen zouden moeten maken om te upgraden naar een nieuwere versie, is het onverantwoordelijk om ze kwetsbaar achter te laten als ze dat niet kunnen doen."

De end-of-lifedatum van Drupal 7 werd vorig jaar al een jaar opgeschoven en zou aanvankelijk pas op 28 november 2022 vallen. Toen noemden de ontwikkelaars de coronacrisis als reden voor het uitstel. De makers schrijven niets over de eol-datum voor Drupal 8; die lijkt voorlopig te blijven staan op 2 november van dit jaar.

Reacties (42)

[Raem]

De makers schrijven niets over de eol-datum voor Drupal 8; die lijkt voorlopig te blijven staan op 2 november van dit jaar.

Dat was dus 2 november vorig jaar (2021), Drupal 8 is al EOL.

[bartvb]

Wat ook geen enorm probleem is want de stap van Drupal 8 naar Drupal 9 is relatief klein.

Van 7 naar 8 is helaas een heel ander verhaal. Wij hebben een marktplaats-achtig platform in Drupal 7 gebouwd met veel Content Type, Views en Search functionaliteit. Laatste keer dat ik dat bekeken heb betekende dat bijna een complete rewrite/herbouwen van de site als we over willen van D7 naar D8. Vervelende is dat er ook relatief weinig voordelen zitten aan D8, op security/maintenance na. Drupal blijft een framework met een nogal vreemde manier van werken met eindeloze arrays die worden doorgegeven en hooks die werken door specifieke functienamen. Ik krijg daar jeuk van sinds ik Symfony gewend ben, dus de motivatie om te migreren is vrij laag.

Vervelende is echter dat er ook geen goede 'classifieds' producten lijken te zijn in modern PHP land dus overstappen naar Symfony (of eventueel Laravel) is ook niet bepaald triviaal. Ik snap iig goed waarom de adoptie van D7 hoog blijft, over naar Backdrop zou kunnen maar is voor de lange termijn ook een doodlopende weg.

[RoofTurkey]

Wat betreft events ben ik het zeker met je eens, gelukkig zijn hier wel wat contrib modules voor. Zoals deze: https://www.drupal.org/project/hook_event_dispatcher

[beerendlauwers]

Gelukkig worden de hooks gaandeweg vervangen door events en event subscribers. Met "drush gen" kan je snel zo'n event subscriber genereren en aan de slag gaan met code te schrijven. Het hoog-systeem zelf vond ik wel altijd een elegante manier van aspect-oriented programming, ik stoor me inderdaad vooral aan de loosely-typed render arrays die worden doorgegeven. Ik hoop heel hard dat men een goede DTO architectuur opzet. Eigenlijk moet er gewoon goede typed data-structuren komen binnen Drupal. Als je al van render arrays af bent, ben je al een heel stuk verder. De rest van Drupal 8-9 gebruikt heel erg veel Symfony infrastructuur.

[pagani]

Bezig met een grote migratie van Drupal 7 naar 9, maar het grootste probleem voor ons is dat veel functionaliteit die we gebruiken (zeg Rules en Subscriptions) niet (goed) meer werkt in 9. Dan is de "oplossing" om custom code te schrijven, maar dat introduceert weer extra risico's voor een volgende upgrade.

[Menesis]

Ja het is inderdaad geen makkelijk pad. Zit hier ook met een relatief simpele site voor een festival, maar upgraden gaat een hoop tijd kosten ben ik bang...
Zoals we het nu gebruiken (wat plaatjes en tekst kunnen aanpassen) lijkt het beter om voor wat simpelers te gaan.

[Reactie gewijzigd door Menesis op 24 juli 2024 15:04]

[Borromini]

Ik heb het ook een paar jaren gebruikt, uiteindelijk toch maar naar een flat CMS overgestapt. PHP zitten patchen is ook niet mijn idee van een eenvoudige website, maar goed .

[Menesis]

Gebruik je iets wat je kunt aanraden?

[Euronitwit]

1/ Als essentiële Drupal 7 modules als date en calendar nog steeds niet compleet zijn aangepast voor D8/9, maar er slechts een uitgeklede versie is geïntegreerd word het niets.
2/ De van D7 afwijkende eisen aan de databases, welke niet bij elke provider mogelijk is.
3/ Composer afdwingen.
4/ mindere views.

Mijn 4 redenen om lekker bij D7 te blijven.

[SvenHe]

Je kan drupal wel zonder composer gebruiken en up to date houden, gewoon met ftp.

Ik weet niet of je dat bedoeld maar die stap op zich is me goed bevallen.
Maar ik gebruik de sites voor mijn eigen bedrijf en houd het aardig basic. Ik hoef geen sites voor derden te onderhouden.

Ik heb nog geprobeerd om ubercart om te zetten naar drupal commerce. Dat is op zich gelukt maar ik vind commerce een draak van een systeem voor een "gewone" en heel kleine shop.
Uiteindelijk heb ik het er weer uit gehaald en overgegaan op een ander systeem.

[jurroen]

Je kan drupal wel zonder composer gebruiken en up to date houden, gewoon met ftp.

Drush werkt ook lekker als je comfortabel bent met de commandline

[Euronitwit]

Ik kan prima met ftp overweg. Doe het daar al 30 jaar mee.
Eerst bij Publisher en daarna Drupal 4 , 5 , 6 en nu 7

Het zijn meer de libraries, welke problemen geven als je die zonder composer wilt installeren.

[The Zep Man]

Als ik de grafiek zo zie en de lijn doortrek, gaat het nog heel wat jaar duren voordat het gebruik van Drupal 7 net zo laag is als de minst gebruikte ondersteunende (major) versie. Op een moment in de toekomst moeten ze toch pijnlijk die knoop doorhakken.

[haling]

Het laat ook zien hoe Drupal 8+ ontzettend gefaald heeft en dat de kloof tussen 7 en 8 gewoon veel te groot was.

Verder kan ik alle D7-gebruikers aanraden over te stappen op Backdrop, een moderne fork van Drupal 7.

[dsmink]

Gefaald? Ik begrijp dat het wellicht onwenselijk is om van een puur procedural naar een OOP codebase over te stappen. Ik begrijp ook goed dat dat een migratie enorm in de weg staat. Maar je kunt toch niet ontkennen dat het in the end een logische stap is?

De stap van 8 naar 9 en in de toekomst ook Drupal 10 zal veel makkelijker verlopen.

Als ik het vergelijk met de codebase van WordPress dan waardeer ik alleeen maar dat men uiteindelijk de keuze voor OOP heeft gemaakt. Toegegeven het is lastig en echt wel een drempel voor veel Drupal 7 websites, maar op de oude voet doorgaan was mijns inziens ook geen optie.

[divvid]

Waarom is dat toch zon drama in php. Een paar jaar geleden hebben we onze hele codebase van een complexe django site omgezet van function based naar class based. Was ff doorwerken maar spannend, nee.

[dsmink]

Wat heeft dat met PHP te maken? Dat heeft puur met de software te maken waarop het gebouwd is. De taal staat daar volgens mij los van.

[brabbelaar]

Men kan ook migreren naar Backdrop, een fork die al een aantal jaar bestaat en D7 compatible is en wil blijven.

Persoonlijk heb ik net geen trauma van het gedoe van migreren van D6 naar D7 jaren her, maar de stap naar D8 is typisch nóg lastiger. Ik snap dat men het uitstelt.

Daarnaast vind ik dat Drupal al vroeg een hoop campagne begint met 'stap nu over', maar voor dat een serieus aantal modules ook gemigreerd is zijn we jaren verder. Dus begrijpelijk dat uiteindelijk support dan wordt verlengd.

[RoestVrijStaal]

"Hoewel deze gebruikers alvast plannen zouden moeten maken om te upgraden naar een nieuwere versie, is het onverantwoordelijk om ze kwetsbaar achter te laten als ze dat niet kunnen doen."

Enkel de EoL opschuiven gaat niet helpen dat die gebruikers gaan migreren.

Een migratie-tool bouwen, waardoor upgraden klik-klik wordt, zou meer helpen.
Of een crackdown op te trage plugin-makers die voor dit soort situaties zorgen, zodat die Drupal moeten forken om op hun eigen tempo hun product kunnen releasen. Dan is het niet meer het probleem van het Drupal dev team.

[brabbelaar]

Hoe zou zo'n crackdown eruit moeten zien? Ik vind dit meer de verantwoordelijkheid van gebruikers van die plugins. Wordpress heeft dit ook, regelmatig worden plugins niet meer compatible of slechts traag ge-update.

Wat is hier tegen te doen? Check je plugin voor dat je hem gebruikt. Is het een one man show en dan ook nog gratis? Het risico lijkt me evident. Zijn er maar 200 downloads? Idem. Zijn er 400 duizend gebruikers? Bestaat de plugin al 10 jaar? Is er een betaalde versie? Dat is veelbelovend. Er zijn weinig zekerheden qua support voor dit soort dingen, maar een beetje logisch nadenken lijkt me wel helpen.

[Tielenaar]

Ik heb nog een Drupal 7 site draaien en die bevat dusdanig veel custom code gebaseerd op het oude hook systeem van Drupal 7 dat dit sowieso niet te upgraden valt. Een upgrade is evenveel werk als de hele site herbouwen waarschijnlijk, daar gaan een paar tools niet bij helpen.

[SvenHe]

Die migratietool is er maar hoe afwijkender de site is opgebouwd hoe minder compleet het resultaat is.

Voor mijn twee eenvoudigste sites was het echt alleen databasegegevens invullen en op knop drukken, alle gegevens geimporteerd.

Daarna alleen de layout en indeling daarvan vernieuwen.

En zelfs het omzetten van ubercart naar commerce liep via de migratietool, alleen is ubercart een ikea en commerce een bouwmaterialenhandel.

[IrBaboon79]

Het bekende probleem dat bijna elke vendor heeft : van een bestaande userbase/functionaliteit migreren naar een nieuwe ‘betere’ versie…maar de klant wil niet want <reden X>. Het enige wat je eigenlijk kunt doen is de jaarlijkse support in prijs laten stijgen zodat uiteindelijk het kostenplaatje omslaat in het voordeel van de nieuwere versie en/of duidelijke voordelen bieden tov de vorige; veel andere stokken achter de deur zijn meestal niet echt super motiverend om een migratie te bevorderen. Het is natuurlijk helemaal een feest als je er gratis afhankelijkheid van 3e partijen bijkrijgt in de vorm van populaire, maar niet langer onderhouden, plug-in/extensie/apps, etc…

Ik wens ze succes maar drupal 7 zal waarschijnlijk nog wel een tijdje mee gaan…

[HollowGamer]

Wat een onzin, een goed geschreven framework zorgt voor een zo'n pijnloze upgrade.
Bijvoorbeeld begonnen met Laravel 5, elke stap kunnen doen van 6, 7, 8 en nu zelfs 9.

Drupal 7 (en oudere versies) zijn gewoon heel slecht geschreven. De nieuwe >8 is gewoon niet af en je hebt allemaal vage tools/documentatie nodig om te upgraden. De meeste dingen slaan op versie 7, maar zijn ook ontzettend out-of-dated.

Nee, de fout ligt hier enkel bij Drupal, zelfs met Windows kun je eenvoudig* upgraden tussen versies.

[Reactie gewijzigd door HollowGamer op 24 juli 2024 15:04]

[IrBaboon79]

Pijnloze upgrades - major versie iig - zijn naar mijn ervaring redelijk zeldzaam hoewel je met veel testen en voorbereiden een heel eind kunt komen maar er moet wel een business case zijn om die trajecten te verantwoorden. Ik kan niet voor webhosters/cms hostende clubjes spreken want dat is niet mijn tak van sport, echter het kosten aspect (ook effort en resources zijn kosten) telt altijd mee. Kost iets veel moeite, tijd, resources en is er een hoog risico profiel dan kiest men naar mijn ervaring er vrij vaak voor om het uit te stellen…want: het ding werkt, het nieuwe ding is vervelend, dus afblijven.

Dan kun je wel een mooi framework hebben, etc…het staat of valt bij de kwaliteit van je upgrade traject van je vendor, in dit geval dus zeker de fout van drupal dat die upgrade blijkbaar geen schoonheidsprijs krijgt en bijbehorende problemen om upgrades erdoor te krijgen.

[demon326]

De stap van 7 naar > 8 is serieus veel werk, maar het helpt wel dat intussen veel verbeterd zou zijn op migratie vlak. Jammer genoeg is er geen automatische views migratie, dus die mag je weert helemaal vanaf 0 opbouwen.

En zolang drupal.org op 7 blijft draaien, zal versie 7 ook ondersteund worden..

[Grert]

Ik ken geen enkel serieus alfternatief voor drupal.


Wordpress/octobercms/Statamic is leuk voor blogs of kleinere websites maar komen totaal niet in de buurt van wat drupal out of the box levert.

[Kosmetdesnor123]

Contentful?

[Henk Poley]

Drupal 7 is al beschikbaar sinds januari 2011, dat is al even.

Klinkt alsof ze de upgrade makkelijker moeten maken. Ze zouden eens met rector en php-cs-fixer ontwikkelaars kunnen bakkeleien, om te kijken of dat te automatiseren valt.

[Reactie gewijzigd door Henk Poley op 24 juli 2024 15:04]

[HollowGamer]

Ik zou nog liever in WP programmeren dan in een Drupal-project:
- Niet versie-upgrade vriendelijk
- Migrations zijn een puinzooi
- Heel veel legacy code/opzet
- Heel veel developers kunnen enkel legacy code schrijven (dat geld ook voor WP)
- Onduidelijke documentatie
- ..

Versie 8 is echt niet veel beter, ook weer een hele hoop legacy en slecht geschreven code.

Nee, het is mij echt een raadsel waarom je als webdeveloper zou kiezen voor Drupal.
Persoonlijk zou ik eerder gaan kijken naar Laravel (eventueel OctoberCMS/Statamic) of andere betere (hybrid) frameworks.

[Reactie gewijzigd door HollowGamer op 24 juli 2024 15:04]

[Grert]

Lavarel is een framework geen cms, kunnen mensen dus niks mee.


Zowel octobercms als Statamic zijn allebei wordpress achtige systemen dat komt niet eens in de buurt van wat drupal te bieden heeft.

[Reactie gewijzigd door Grert op 24 juli 2024 15:04]

[Groningerkoek]

Afhankelijk van de use-case kan Drupal de veel betere oplossing dan Laravel zijn,, je kunt dus geen algemene opmerking maken als dat Laravel veel beter is.

[Grert]

Misschien moet je eens kijken hoeveel grote websites op drupal draaien.

[HollowGamer]

Je was goed bezig, maar je comment over PHP klopt niet. Geef dan voorbeelden wat er mis is met PHP.

[aikebah]

Om te beginnen dat dit
https://www.php.net/manua....get-magic-quotes-gpc.php

pas bij versie 8.0 er eeeiiiindelijk een keer uitgesloopt is.

nou https://www.php.net/manual/en/reserved.variables.request.php nog een keer slopen

[Reactie gewijzigd door aikebah op 24 juli 2024 15:04]