End-of-lifedatum van Drupal 7 wordt opgeschoven naar 28 november 2022

De Drupal Association kondigt aan dat de ondersteuning voor Drupal 7 een jaar langer wordt doorgezet. Oorspronkelijk zou de software vanaf november 2021 een end-of-lifestatus krijgen, maar dit wordt nu opgeschoven naar 28 november 2022.

De ontwikkelaars maken dit bekend via een security advisory. Drupal is een opensource-contentmanagementsysteem dat wordt gebruikt om websites en blogs te beheren. De ontwikkelaars van het cms geven de impact van covid-19 als reden voor de verlengde levensduur van Drupal 7, dat in 2011 werd geïntroduceerd. Op die manier krijgen gebruikers van Drupal 7 tot en met 28 november 2022 beveiligingsupdates, en hebben daarmee een jaar langer de tijd om over te stappen op Drupal 9.

De eol-datum van Drupal 8 blijft 2 november 2021, omdat ondersteuning voor Symfony 3 op die datum stopt. Dat is een php-framework waar Drupal 8 gebruik van maakt. Volgens de Drupal Association is de upgrade van Drupal 8 naar Drupal 9 makkelijker dan de overstap van 7 naar 8, waardoor het bedrijf naar eigen zeggen niet dezelfde impact voor gebruikers verwacht.

Volgens de statistieken van Drupal maken op het moment van schrijven nog ruim 750.000 websites gebruik van Drupal 7. Dat is goed voor ruim 63 procent van alle Drupal-gebruikers. Alle verschillende versies van Drupal 8 zijn goed voor 30 procent van alle Drupal-installaties. Zo'n 8,8 procent van alle gebruikers gebruikt een versie van Drupal 9, de meest recente uitgave van de software.

Reacties (51)

Dus, op 5 jaar tijd is nog maar goeie 30% overgestapt naar Drupal 8 of later? Da's nogal een erg triestige vooruitgang. Hoe hopen ze dat dit over 2 jaar wel een acceptabel laag aantal gaat zijn? Zo te zien is het gebruik van Drupal sinds versie 8 ook gestagneerd. Hoe gaan ze mensen pushen om naar versie 8 of 9 te upgraden?

In vergelijking; WordPress 5.x heeft momenteel 75% van het aandeel van WordPress in handen en is maar 1,5 jaar oud. WordPress 4.4 is van eind 2015, alle versies daarvoor houden momenteel een gezamelijk marktaandeel van zo'n 5%, met de niet-ondersteunde versies (3.0 - 3.6) maar 1,2%. (Over WordPress 2.9 en eerder zijn er geen gegevens)

[Reactie gewijzigd door Loller1 op 25 juni 2020 16:42]

Je kan WordPress niet echt vergelijken met Drupal. WordPress is meestal voor simpele websites, Drupal voor meer complexe websites.

In Drupal 8 hebben ze de code flink op de schop genomen zodat het toekomstbestendig is (object georiënteerd en gebruik maken van het Symphony framework). Veel modules waren eerst nog niet beschikbaar en je kon ook nog niet upgraden van 7 naar 8. Dat is pas in een latere minor toegevoegd.
Onlangs is Drupal 9 uitgekomen, maar die is niet opnieuw opgebouwd, maar is bijna hetzelfde als Drupal 8.9.

WordPress was vroeger een blog en tegenwoordig een CMS en dat is te zien aan de code, die al een tijdje niet op de schop is gegaan. Ze brengen nieuwe versies hierdoor sneller uit.

Dus, op 5 jaar tijd is nog maar goeie 30% overgestapt naar Drupal 8 of later? Da's nogal een erg triestige vooruitgang.

Het is inderdaad triestig. Wordpress is op andere wijze triestig, plugins breken regelmatig bij updates die toch vlot worden doorgevoerd. Maar Drupal breekt steeds bijna helemaal bij een major update. Van 7 naar 8 was dat in hoge mate het geval. Mensen maken vaak ook complexere websites natuurlijk, anders gebruikten ze wel Wordpress. Maar gevolg is dat je wel 3x uitkijkt voordat je upgrade. Het kost bakken aan tijd/geld.

Ik erger me overigens in die update cycli ook over de communicatie waarin voortdurend door jan en alleman wordt gesuggereerd dat het 'nu tijd is' en 'makkelijker dan je denkt'. Vrijwel altijd wacht je op projecten/plugins die je nodig hebt en die nog niet zover zijn. "Schrijf dan je eigen" is gewoon makkelijk gezegd moeilijk gedaan.

Tussen 6 en 7 zaten ze met vergelijkbare problemen van langzame adoptie. Het is ook zonde dat zoveel code verloren gaat omdat plugins grotendeels herschreven moeten worden.

En dat hebben ze nu aangepast. Van D8 naar D9 is gewoon deprecated code weggehaald. Contrib modules worden nu vlot geport en er is een tool die automatische patches schrijft om de grootste stukken code van contrib automatisch aan te passen.

Ik verwacht dat migratie van Drupal 7 naar 8 niet zo simpel werkt als met Wordpress, een beetje hetzelfde verhaal als met Joomla. Dat betekend dat zo een migratie vrij kostbaar is ivm. Wordpress en willen mensen zo lang mogelijk gebruik blijven maken van hun huidige investering. In dit geval wacht je dan even op de Drupal 9 release die 3 juni van dit jaar uitkwam, dus drie weken geleden... Dan wacht je even een paar weken/maanden/releases totdat de nieuwe versie als 'stabiel' kan worden gezien en dan ga je pas testen met een nieuwe versie! Daarnaast verwacht ik ook dat er velen zullen overstappen naar iets anders/simplers.

Drupal gebruik heeft het zelfde issue als Joomla gebruik: If you have a hammer, everything looks like a nail! In veel gevallen is gebruik van Drupal/Joomla zwaar overkill waarvoor het wordt gebruikt, laat staan dat het een relatief hoge onderhoud/migratie kostenpost met zich meeneemt. Iets als Wordpress is veel goedkoper of zelfs iets als Squarespace nog goedkoper/efficiënter. En nu beginnen een hoop webbuilders/designers zwaar te stijgeren, maar ik heb het teveel meegemaakt bij klanten die echt niet zoveel spannends doen op hun site, laat staan dat ze specifieke functionaliteit nodig hebben wat de goedkopere varianten niet hebben. Wat ik ook vaak zie is dat de klant een specifiek idee heeft en een webbouwer die wel exact zo wil nabouwen en dat verwerkt in het prijskaartje. Maar als je aan een klant vraagt: "Als ik het zo en zo doe kan dat specifiek niet helemaal zoals je wilt, maar komt dit dicht genoeg in de buurt? Scheelt een paar honderd/duizend euro...". Dan hoor je meestal dat die goedkopere manier prima is. Als je dat doet met custom/proprietary CMSen bij Enterprise klanten kunnen er vaak nog een paar nulletjes bij...

Ik kom uit de PHPnuke (en verschillende afgeleiden)> Mambo> Joomla hoek, het is erg leuk speelgoed, maar op een gegeven moment voelt het aan alsof je met een vrachtwagen boodschappen aan het doen bent...

Dat gevoel heb ik ook, maar dat is hoe ze het tegenwoordig doen, voor een hello world worden eerst tig libraries etc ingeladen, terwijl echo "hello world" niemand meer kan, want het moet lekker eenvoudig via een framework

Dit wil ik wel eens verder verklaard zien:
* Laravel, Symfony, etc. etc. zijn ook speelgoed.
* Het is de schuld van PHP-FIG.

Wat bedoel je nu eigenlijk exact met die uitspraken.

En ook: je eigen CMS schrijven, dat getuigt van weinig inzicht. CMS'en en frameworks hebben ook een bepaalde kracht. Je kan er snel mee ontwikkelen, ze voorzien een basis waar ook al heel wat security measures ingebakken zijn. En ja, er worden security issues gevonden, en die worden dan ook gefixt. Wat bij een custom CMS niet het geval zal zijn.

Het is niet per sé dat jouw code stom is, het is dat jouw code niet generiek genoeg zal zijn, niet genoeg contributors heeft, geen degelijk security team eraan heeft hangen, ...

Bij mijn vorige werk zijn we overgestapt van Joomla naar Wordpress vanwege de security. Joomla had zo veel issues altijd en alle lekken waren kennelijk ook erg makkelijk te gebruiken, want leks die pas een paar dagen bekend waren en soms niet eens gepatched werden al misbruikt. Wordpress met auto updates geeft veel minder problemen, veel klanten van mijn oud werkgever zijn via een overname nu bij mijn huidige, en geven nooit problemen.

Migraties van Drupal zijn aanzienlijk kostbaarder dan die van Wordpress (we ontwikkelen op basis van beide platformen).
En er is geen reden om te migreren naar Drupal 8 omdat er nog security updates zijn voor 7, dus investeren bedrijven daar ook niet in.

if it ain't broke, don't fix it

[Reactie gewijzigd door Bender op 25 juni 2020 16:55]

Ik werk al met Drupal sinds juli 2007. Toen werd net Drupal 5 uitgebracht.
De overstap naar D6 was nog redelijk te doen. Van D6 naar D7 was al gecompliceerder, omdat sommig modules zoals Date en Calendar niet lekker migreerde. Moest die 10.000 nodes handmatig overzetten.

Toen D8 een jaar oud was -en ik mij oriënteerde om over te stappen- kon ik dat nog steeds niet wegens ontbrekende functionaliteit door gebrek aan geschikte modules.
o.a. Date en Calendar gaven weer problemen dus ik ben maar niet verder gegaan, Ook omdat D7 nog steeds bijgewerkt werd/wordt.

Heb D9 nog niet uitgeprobeerd. Het aantal beschikbare extra modules lijkt nog wat mager en ik weet niet of ik met D9 hetzelfde kan als met D7 ik heb niets aan een simpele blog-achtige website.
Er zijn nog steeds meer extra modules voor D7 beschikbaar dan voor de andere versies.

Waarom zijn er nog allemaal van die modules en thema's? Het voelt echt ontzettend oud en inflexibel aan. WP heeft precies hetzelfde euvel.

Worden er in de Drupal wereld geen stappen gemaakt naar frameworks (zoals Laravel/Symfony/OktoberCMS), met daarbij gewoon losse packages via composer en/of gecombineerd met een React/Vue frontend frameworks?

Je bent daardoor niet meer afhankelijk van modules die speciaal geschreven moeten zijn voor een systeem en je kunt in vrijwel alle gevallen eenvoudig een package wisselen. Genoeg Admin templates zijn er beschikbaar, zowel dus voor de voorkant alsook achterkant.

[Reactie gewijzigd door foxgamer2019 op 25 juni 2020 22:13]

In de praktijk besef je toch dat dat ook niet het walhalla is? Je hebt een admin theme, maar je moet daar voor complexe projecten ook nog vanalles bovenop schrijven om dat degelijk te laten werken. Losse packages moet je dan met custom code ook in je systeem gaan lijmen.

Je werkt met Drupal vooral als je een informatieve website maakt waarbij een gestructureerd datamodel heel belangrijk is. Dat is de grootste kracht. Zeker in Drupal 8 met de ingebouwde API functionaliteit werkt dat heel goed voor veel cases.

Je werkt met Symfony als je datamodel ondergeschikt is aan custom logica en je er meer iets applicatief van maakt. Symfony is meer low-level dan Drupal, dus is het logischerwijs ook meer flexibel.

Maar zeggen dat CMS'en geen nut hebben, want je kan het toch wel met Symfony doen, is wel enorm kort door de bocht ... In de praktijk kan je natuurlijk alles in beide systemen, het is een kwestie van de juiste match te zoeken.

dat is precies wat Drupal 8 en hoger gedaan heeft: Symphony / composer setup: veel generieke packages. Maar die moeten nog wel integreren met het platform natuurlijk. Daarom is de overstap van 7 naar 8 ook veel lastiger. Drupal 7 was 1 codebase: download t en gooi t in www-data: iedere beginner heeft t aan de praat. Toen 8 uitkwam moest je aan de slag: package managers etc. Er waren bijna geen hosting partijen die dat aanboden. Dus voor veel gebruikers was de stap te groot. Het is nu wel beter geworden, (makkelijker), maar Drupal is meer en meer een framework voor grotere sites.

(edit: zinsconstructie)

[Reactie gewijzigd door Sicco2 op 26 juni 2020 10:57]

Maar ja, die updates houden een keer op en het is niet echt slim om door te gaan tot het bittere eind.

Klopt, die houden 28 november 2022 op ;-)

Er is dus ook weinig reden voor de meeste organisaties om echt ver van tevoren er geld in te stoppen als het niet nodig is.

Klopt, die houden 28 november 2022 op ;-)

Ja, nu. Maar lees ook even wat de *oorspronkelijke* einddatum was. De insteek zou moeten zijn "op tijd migreren" en niet "zo lang mogelijk gebruiken en hopen op God's gratie dat we nog een jaartje langer doorkunnen".

Dan heb had je nog steeds 1 jaar en 5 maanden tot de deadline, meer dan genoeg tijd dus.

Maar een migratie kost tijd en je moet ook rekening houden met eventuele bugs of migratieproblemen, zeker bij een upgrade als deze (7 naar waarbij er behoorlijk wat veranderd is. Dan wil je dus zeker wel een jaar van te voren beginnen.

Ik denk dat het voor veel mensen gewoon een rekensommetje is waarbij je bepaalde investeringen zo lang mogelijk wilt uitzitten. Voor de gemiddelde consument niet echt relevant, maar voor bedrijven is dat wat anders.

Maar ja, die updates houden een keer op en het is niet echt slim om door te gaan tot het bittere eind.

Dat is het wel. Het einde is er nog ruim 2 jaar niet, en dus nog lang niet bitter. Maar je hebt dus wel een goed ondersteund goed functionerende site. Maak nu iets, wie weet wat we over twee jaar zien? Maak over 2 jaar iets en D9 is al volwassener, dus migratie is makkelijker.

2021 is toch ook niet morgen al? Gezien hoe met migraties van OS'en wordt omgegaan door bedrijven en overheden moet ik overigens zeggen dat het niet geheel vreemd is om iets wél zolang mogelijk te gebruiken.

2 maanden zou ik daar voor aanhouden, en met nog bijna anderhalf jaar te gaan tot de originele einddatum heb je dus nog meer dan genoeg tijd.

Maar ja, als het zo simpel werkt, ga ik dat ook eens proberen met andere dingen. "Ja, ik ben eigenlijk te laat met het verlengen van mijn ov-abonnement want ik hoopte erop dat jullie de geldigheid met een jaar zouden verlengen".

Er is een verschil tussen laat en te laat. Hoe onvergelijkbaar een OV-abbo ook is met software support, ik ga mijn abonnementen niet verlengen maanden voordat ze aflopen ieder geval.

Ik denk dat geld het probleem is.

Het is nu zomaar een update wizard om van 7 naar 8 te gaan. Hier moeten klanten een expert voor inhuren en dat hebben ze er vaak niet voor over.
Uiteindelijk is het volgens mij heel normaal dat bedrijven na 5 jaar hun website weer helemaal vernieuwen. Bij Drupal websites zullen ze misschien vaker koppelingen met externe systemen eraan hebben (bij Wordpress minder) wat ook moet gaan werken onder de nieuwe versie.

Uiteindelijk is het volgens mij heel normaal dat bedrijven na 5 jaar hun website weer helemaal vernieuwen.

Het roept wel de vraag op of ze hun website vervangen omdat ze dat zo graag willen of omdat de oude versie niet meer te onderhouden is?

Drupal is andere koek dan Wordpress en mag je niet met elkaar vergelijken.
De meer complexere sites met eventueel maatwerk modules worden op Drupal gebouwd. Wordpress is voor de huis-tuin-keuken websites..

[Reactie gewijzigd door chevchelios op 25 juni 2020 17:18]

Deze vergelijking gaat niet helemaal op. Wordpress houdt naar mijn weten geen semantic versioning aan. Wanneer 5.9 aanbreekt, dat de volgende major release 6.0 zijn en bijvoorbeeld geen 5.10. Dit is ook de reden dat je vaak zonder inspanning van 4.9 naar 5.10 kan.

De problemen die optreden zullen dan meer zitten in verouderde plugins die tijdens 4.9 nog gebruik maakte van deprecated code, die vervolgens in 5.0 verwijderd is.

Ik vermoed dat de reden veel meer te maken heeft met zowel budget, want Drupal sites kosten gewoon meer om te maken, maar ook gewoon hoe stabiel Drupal 7 is. Als je nog steeds als je doelen bereikt met jouw huidige D7 site, wat is is dan afgezien van verouderde techniek een goed argument om over te gaan?

De argumenten om over te gaan zijn over het algemeen dat je een nieuwe site moet bouwen omdat je huidige site niet meer voldoet aan de wensen en een nieuwe site kansen beidt nieuwe doelen te stellen en daar je nieuwe site op in te richten. Of het feit dat het platform EOL is, veiligheid niet meer kan garanderen en er geen partijen zijn die de huidige site willen onderhouden.

Dat laatste is voor ondernemers niet altijd even goed te bevatten, omdat ze nog van mening zijn dat de site gewoon prima doet wat het moet doet, wat ik niet kan ontkennen dat vaak het geval is.

Het grootste probleem is volgens mij dat ze de core van Drupal flink hebben omgegooid tussen versie 7 en 8 (en dat was nodig ook). Dat maakt het dat een upgrade niet zomaar gedaan is.

Daarnaast speelt het probleem dat site-eigenaren over het algemeen niet overtuigd zijn van het feit om te upgraden 'mijn site werkt toch'. Ik werk nu 10 jaar als webdeveloper en zie dat veel partijen na de initiële levering vaak niet of nauwelijks willen investeren in upgrades. Iemand moet wel dat onderhoud betalen, maar veel site-eigenaren hebben er geen zin in, hoe goed de argumenten ook zijn.

Zo draaien er bijvoorbeeld nog legio PHP 5.3/MySQL 5.0/Apache 2.0 servers, ook met gevoelige data! Als bouwende partij een onderhoudscontract verplichten werkt ook niet, want dan loopt een groot deel van je klanten direct naar een andere partij die deze voorwaarde niet heeft.

[Reactie gewijzigd door Gustaaf437 op 25 juni 2020 17:06]

Jij ziet het nu vanuit jou kant (en dat zie ik ook), maar ik zie ook vanuit de klant kant dat webbouwers er een potje van bouwen. Met geen woord reppen over onderhoudskosten tot na dat de site is gebouwd, met uitloop/hogere kosten. Klanten schrikken zich dan kapot en kunnen/willen dat niet betalen omdat dit niet begroot is. Dit gebeurt omdat de meeste mensen in kleine bedrijven geen flauw benul hebben van hoe dat computer gebeuren allemaal werkt, laat staan een website, hun expertise ligt ergens anders.

Als je als externe ITer dan bij zo een gesprek komt te zitten tussen zo een webbouwer die normaal de kleine MKBer wel even uitkleed via hun favorite CMS of nog mooier, hun eigen CMS. Dan krijg je opeens hele boze blikken vanuit die hoek...

Zo zie ik het ook. Ik werk in een klein bedrijf waarbij ik regelmatig met verschillende dienstenleveranciers in contact kom en ik blijf me verbazen van de agressieve werkwijze van IT-bedrijven.

Men belooft eerst de hemel voor vaak te veel geld maar als puntje bij paaltje komt en er duikt een probleem op, dan schuift men de oorzaak steeds af op anderen.

Klantonvriendelijkheid zien we ook soms bij andere leveranciers, maar toch zeker niet zo vaak.

Ik kan dan ook goed begrijpen dat veel bedrijven terughoudend zijn om te beslissen om met een IT-bedrijf in zee te gaan en dat liefst zo lang mogelijk uitstellen.

Mensen denken vaak dat ze met iets digitaals een soort aankoop doen als een tafel. Die je 1 keer koopt, 1 keer kosten er aan hebt, een jaar in de schuur kan zetten en daarna weer pakken en hij functioneert nog zoals op dag 1. Echter is het eerder alsof je een kat aanschaft. Als je daar geen onderhoud aan pleegt en geen eten geeft, zie je gauw wat dan het resultaat is. Zo is het meestal ook met digitale oplossingen.

Laatst ook zo’n klant. Hele website op Django 1.2 nog. Dat wordt wat dachten we, veel kotsten en tijd. Tot onze verbazing viel de migratie naar Django 3 reuze mee.

Drupal heeft overigens ook nog extended security updates na de EOL datum; het extended vendor support programma zoals genoemd in de Drupal advisory is voor Drupal 6 nog steeds gaande. Deze komen uit als losse patches via het d6lts project, ondersteund door enkele commerciële vendors maar de patches zijn gewoon publiekelijk beschikbaar (als patch files in de repo van het LTS project). Volgens een blog post van een van de vendors gaat dat nog minstens tot feb 2022 door.

Is het ook niet zo dat Drupal veel meer een CMS voor specifieke maatwerkoplossingen is? Dat maakt migratie naar een nieuwere versie ook een stuk ingewikkelder.

Klopt, veelal grotere en complexere websites.
En dat kan ook in Wordpress, maar de markt van de Wordpress websites zijn voornamelijk kleinere,

Een leuk overzicht in bruikbaarheid op drupaloverheid.nl
eenvoudige website
(alles op één server, 2 users, 150 webpagina's, basisfunctionaliteiten)
Composite C1
Joomla!
Typo3
Umbraco
Wordpress

Website met webshop of intranet
(twee servers, 20 users, 1.000 webpagina's, basisfunctionaliteiten, aantal geavanceerde functionaliteiten)
Drupal
Hippo
Plone

Internationale multi-lingual webomgeving
(meerdere installaties, onbeperkt aantal users, tevens een intranet, veel geavanceerde functionaliteiten)
Composite C1
Hippo

Een goed startpunt voor de selectie van een Content Management Systeem (CMS) is de Hartmangids.

Die website werkt al een aantal jaar niet meer. Zegt wat over hoe actueel dit is ...

Dit is exact de reden wat er mis is met dat soort sites, worden niet geupdate:

Een goed startpunt voor de selectie van een Content Management Systeem (CMS) is de Hartmangids.

Klik in het originele artikel eens op het Hartmangids linkje waar ze naar verwijzen. Die site is al minstens drie jaar uit de lucht.

Deze pagina is ook minstens sinds januari 2017 niet geupdate:
https://www.drupaloverheid.nl/content/over-drupaloverheid
Sinds die tijd is Esther de Koning namelijk geen Deliverymanager meer bij Sogeti (Capgemini), maar Docent Biologie...

Als we naar de genoemde website van Ministerie van Economische zaken gaan kijken, dan vermoed ik sterk (na de source van de pagina te hebben bekeken) dat deze site van de overheid in ieder geval geen Drupal meer gebruikt...

Drupal != Wordpress. Waar je in Drupal een beperkte set plugins hebt, is dat bij WP anders. Juist het vastzitten in bepaalde plugins of maatwerkoplossingen, maakt overstappen geen 'appeltje eitje'.

Modules in Drupal zijn normaliter gratis. Plugins in Wordpress waar je wat aan hebt kosten in het algemeen geld.

En daardoor vaak ook beter ondersteund en voor elke wp versie een update van de plugin want anders blijft het niet verkopen.

Het zijn echt twee werelden. Ik zit nu wat in Wordpress te maken, en word helemaal gek van de rommelige admin-interface en het commerciele karakter van Wordpress.

Bij Drupal weet ik dat ik veel meer werk heb, maar het landschap is zoveel rustiger.

Het grote verschil is dat je nu aan het knutselen bent voor jezelf, als je gaat knutselen voor iemand anders dan gaat opeens dat metertje tikken met dat Euroteken erop (tijd=geld)... En dan mag jij lekker werken met Drupal, maar in de meeste gevallen is het niet geschikt voor de doorsnee klant (door de eerder genoemde complexiteit), ga je het dan alsnog die klant aansmeren? En als je op een gegeven moment voldoende CMSen heb gehad, dan lijkt de een op de ander in het admin panel. Natuurlijk houd je altijd nog een eigen voorkeur...

Het 'knutselen' noemen, komt over als een frame.

Als ik iets in Drupal maak, weet ik dat het de komende 5 jaar werkt. Met een kleine kans op verrassingen, en in elk geval eenn subset gecontroleerde plugins. Bij Wordpress wordt ik elke keer gespammed met update dit, like dit of koop dit.

Ga je voor de sprint (Wordpress) of de duurloop (Drupal). Inderdaad, dat hangt van het doel af.

Het 'knutselen' noemen, komt over als een frame.

Dat is het nadeel als je in je profiel niets zet! ;-) Sorry, maar dit kwam ook deels door de opmerkingen van Euronitwit. En je weet wel, aanname, de moeder van...

Back on topic: Als jij iets maakt weet jij niet dat het de komende 5 jaar werkt. Je heb zoiets als (security) updates en soms breken die bestaande functionaliteit. Daarnaast heb je twee opties, alle modules zelf maken, dat kan redelijk risicovol zijn voor de klant, want veel webdesigners zijn geen security specialisten. Als je ze uit de pool van tienduizenden beschikbare modules haalt is ook nog maar de vraag of men deze blijft onder steunen met (security) updates.

Datzelfde issue hebben we natuurlijk met WP, maar daar is het natuurlijk zo dat populaire betaalde plugins wel voor langere tijd worden onderhouden en voorzien van (security) updates. Vaak is het zo dat wat wordt aangeboden vaak effectief veel goedkoper is dan het zelf (laten) bouwen (als je je tijd op waarde inschat). Natuurlijk kan het zo zijn dat je je custom stuff inzet bij al je klanten, maar als ITer zou ik je dan nooit aanraden omdat dit de eindklant verplicht bind aan een leverancier. Met Wordpress is het ook de kunst om de juiste plugins te kiezen, maar daar kom ik ook regelmatig tegen dat mensen wel steeds op het update WP knopje hebben geklikt, maar niet de plugins zijn gaan checken en vaak al jaren niet meer ondersteund worden omdat 'vlotte' webdesigners die het wel effe voor een prikkie hebben geregeld de verkeerde plugins hebben uitgezocht en geen waarschuwingen hebben achtergelaten... Dit komt niet alleen voor bij kleine vlut bedrijfjes, ook bij grotere bedrijven die daar geen dedicated afdelingen voor hebben.

Nu kost mij een website gebouwd in Drupal €0 buiten de hosting kosten.
Thema's en modules worden prima onderhouden of anders duidelijk aangemerkt als un-supported.
Als er een nieuwe update van de Drupal core is vanwege veiligheidsproblemen, dan worden de modulen, die dat nodig hebben, ook bijgewerkt.
Er zijn D7 (of D8) modules die na eerste publicatie geen update meer hebben gehad, omdat ze gewoon nog werken met alle versies van D7 (of D8)
Over ondersteuning bij Wordpress kan ik niet oordelen.

Dries Buytaert, oprichter van Drupal vond technische hoogstandjes en een leidende positie in de Development platform markt (voorheen CMS-markt) belangrijk om zijn bedrijf Acquia naar grote hoogten te stuwen.
Hierbij liet hij bestaande klanten en developers keihard in de kou staan met de introductie van Drupal 8.
Daar waar Drupal 7 nog geschikt was voor kleinere websites, was Drupal 8 en hoger bedoeld voor 'ambitious digital experiences' (bron: Driesnote Drupalcon Vienna 2017): "Drupal is no longer for simple sites".
Zelf ben ik sinds 2006 enthousiast fan van Drupal geweest en heb vele Drupal sites gemaakt en heel veel tijd geïnvesteerd ins scholing om Drupal 7 module development e.d te kunnen doen.

Van de moeizaam opgebouwde PHP/Drupal kennis kon ik gewoon 70% weggooien bij de overgang naar D8.
Los daarvan is de complexiteit (die al hoog was) alleen nog aanzienlijk toegenomen. Als zelfstandig consultant is het me daarom onmogelijk gebleken om nog een keer jaren te investeren in scholing om op ditzelfde niveau te komen. Dit kost simpelweg te veel tijd en geld. Best frustrerend ook.
Na deze Drupalcon in 2017 is mijn enthousiasme voor Drupal geheel weggezakt, en wel door de redenen die ik hierboven heb genoemd.

Het is dan ook goed om te zien dat het merendeel van de Drupal websites, nog gebaseerd is op Drupal 7.
Dat zal Dries en Acquia niet deren. Die halen hun omzet niet uit dat segment. Dat gebeurt er wanneer een sympathiek opens source systeem wordt overgenomen door Big Bucks en mr. American Dream.
En die kleine sites, die nu nog op Drupal 7 draaien? Die verdwijnen gewoon. Of dat worden Wordpress sites. En dat is jammer...