Nieuws

Drupal-bureaus over de ruggengraat van Drupal: de modules

13 maart 2026

Ze zijn er in alle soorten en maten: de Drupal-modules. Sommigen zijn onderdeel van de Drupal core, anderen voegen een extra stukje functionaliteit toe, zoals bijvoorbeeld webformulieren. Niet verwonderlijk dat er letterlijk duizenden modules in omloop zijn. De meesten gemaakt door de community, gedeeld door de community (op Drupal.org) en onderhouden door de community. We vroegen vijf Drupal-bureaus – Flink, iWink, Solvy, Atom en iO – naar hun ervaringen met Drupal-modules. Welke gebruiken zij en wat zijn daarbij best practises?

Drupal druppel in schematische structuur.

Vaste plek in de Drupal-gereedschapkist

Zoals aangegeven: de keuze is reuze als het gaat om modules. Om een beeld van het belang van de Drupal-modules te geven, zegt Paul Dudink (Flink): “Bij een gemiddelde website gebruiken we zoʼn 90 à 100 modules.” Toch worden een aantal modules veelvuldig genoemd door de bureaus (zie onderaan het artikel voor een meer uitgebreide lijst).

  • Paragraphs: vrijwel alle bureaus noemen de module als de standaard voor flexibele, modulaire contentopbouw;
  • Pathauto & Metatag: deze modules worden vaak gebruikt voor SEO-toepassingen;
  • Search API: gewild voor geavanceerde zoekfunctionaliteiten, vaak in combinatie met Solr of Elasticsearch;
  • AI-modules: meerdere bureaus, waaronder iWink en iO, geven aan dat AI-modules (zoals AI Image Alt Text voor automatische alt-teksten) een steeds grotere rol gaan spelen.

Zelf bouwen of hergebruiken?

De keuze tussen een bestaande module of maatwerk is een strategische afweging. Justin van der Raaf (Atom) benadrukt dat Drupal standaard al enorm krachtig is. “Wanneer je volgens standaarden werkt, kan maatwerk soms juist beter en sneller zijn dan voor elke kleine functionaliteit een aparte module te installeren. Een wildgroei aan modules kan namelijk complexiteit introduceren en ten koste gaan van onderhoud en beheersbaarheid.” Delen met de community gaat vervolgens niet altijd. Van der Raaf: “Vaak is nieuwe functionaliteit sterk projectspecifiek of mag deze vanuit een opdrachtgever niet gedeeld worden.” Een module waar Atom momenteel aan werkt is AI Content governance: www.drupal.org/project/ai_content_governance.

Ondanks het veelvuldige maatwerk wordt er veel teruggegeven aan de community. iO ondersteunt zo’n 94 modules op Drupal.org (zie: www.drupal.org/io#projects-supported), en ook bureaus als Flink en Solvy ontwikkelen eigen oplossingen (zoals de Lazy Loading Formatter of Status Dashboards) die ze delen. De belangrijkste reden voor deze 'contributie'? "Bugs die we zelf tegenkomen oplossen voor iedereen verhoogt de stabiliteit van het hele platform," aldus Paul Dudink (Flink). iWink heeft op dit moment geen eigen modules op Drupal.org maar draagt proactief bij door middel van bugfixes en het verbeteren van de stabiliteit van bestaande modules.

Veiligheid boven alles

Als het gaat om het up-to-date zijn van Drupal-modules, zijn de experts helder: security is prioriteit nummer één. Paul Dudink (Flink): “Op het moment dat een module lang niet geüpdate is, is dat altijd wel een puntje van aandacht.” Maarten Heip (iO) beaamt het belang van security. Hij voegt daar aan toe dat ze door de jaren heen meer proactief zijn gaan ontwikkelen: “Proactief updaten is uiteindelijk stukken goedkoper dan reactief trouble shooting.” 

Als het gaat om updates van modules hanteert iO de volgende volgorde. Heip: “Zoals aangegeven, security komt eerst, dan volgt core compatibility (modules moeten compatibel blijven met nieuwe Drupal-versies), PHP version support (ondersteuning voor nieuwere PHP-versies), backward compatibility  (voorkomen van problemen in bestaande projecten), performance improvements (verbeteren gebruikerservaring) en community feedback (verbeteringen op basis van feedback gebruikers).”

Ook de andere bureaus geven aan dat het proces rondom updates strikt is ingeregeld. Solvy en iWink benadrukken het belang van een staging-omgeving: een update gaat nooit rechtstreeks naar productie zonder uitvoerig te zijn getest op compatibiliteit met PHP-versies en de Drupal core. Alexander Buist (iWink) geeft aan dat zijn bureau bewust wacht met updaten bij een nieuwe Drupal versie: “Pas als de kritische modules beschikbaar en stabiel zijn, werken we het systeem bij. Dit voorkomt instabiliteit.”

Wanneer is een module 'goed genoeg'?

Het selecteren van een module gebeurt niet zomaar. De Drupal-bureaus letten op een aantal zaken:

  • Gebruik: hoeveel installaties heeft de module? (Vaak een 'bewijs' van betrouwbaarheid);
  • Onderhoud: hoe actief is de issue queue? Reageren maintainers snel op bugs?;
  • Compabiliteit: is de module compatible met huidige en toekomstige Drupal-versies?;
  • Security: valt de module onder het security-proces van Drupal?;
  • Codekwaliteit: voldoet de code aan de Drupal Coding Standards;
  • Documentatie: zijn documentatie en configuratie-instructies duidelijk en volledig.

Best practises

De Drupal-bureaus hebben een aantal best practises voor ontwikkelaars die zelf modules willen uitbrengen. Een gedeeld advies is, zorg voor een heldere README en hanteer semantic versioning (duidelijke versienummers). Justin van der Raaf (Atom) voegt daar aan toe: "Werk volgens gangbare ontwikkelstandaarden zoals Semantic Versioning en hanteer codeconventies en kwaliteitscontroles.” Ook belangrijk: schrijf tests. Luc Kitslaar  (Solvy): “Waar mogelijk,  is het goed om geautomatiseerde tests toe te voegen.” Tot slot: “Laat een module niet te veel doen,” adviseert Len Swaneveld (iO). “Kleine bouwblokken zorgen ervoor dat een site alleen gebruikt wat echt nodig is.”

Veelgebruikte modules

In hun werk gebruiken de ontwikkelaars van de Drupal-bureaus diverse modules. Dit zijn veelgebruikte voorbeelden:

Content Beheer:

SEO & Performance:

Search & Media:

Security & Integratie: