Setting up a stock 15 year old version of Drupal is an useful reminder that it was clearly a Slashdot era community portal app; the arrival of and tight integration between Views and the Content Construction Kit was what started its shift into the realm of Significant CMSs.
In those days the relationship between a “content type” and a database table was essentially 1:1; defining one required writing and installing a custom plugin module. Many were simply copies of the built in “page” module, with a quick search and replace job to change the name.
CCK let site admins define new content types, add custom fields to them, define how they’d be displayed to visitors… and automatically generated content editing forms for the resulting structures. No code needed.
Meanwhile, the Views module let those same administrators define custom listing pages and sidebar widgets — essentially SQL queries and templating decisions — without writing a line of PHP or SQL.
Significantly, it was smart enough to look at the metadata generated by CCK, using it to give administrators filtering and sorting options that reflected the properties of the content they were building a view of.
The other magic ingredient: one of the standard field types included with CCK that allowed a field on one piece of content to reference other pieces of content.
None of it was particularly radical — it was all stuff that could be done with hand written code, and many developers at the time dismissed it as unnecessary fluff that was less efficient than handwritten SQL and custom code.
Despite that, the metadata-driven UI builder generated structures and forms that were good enough. Allowing site creators to build out complex relational content models and dynamic listing pages without code was a killer app. They steered the entire project in a new direction.
Entire ecosystems of new plugins added new display styles to Views (pipe your latest content into a rotator instead of a page with just one click!) and data types to CCK (add a lat/lon field to your content type… and display the field as a map!)
That modular approach meant that plugin modules that added big, monolithic features (a photo gallery, say) were cannibalized by smaller ones that added specific data types, display styles, and so on — letting site builders assemble their own gallery that worked “just so.”
…But over time, that meant the complexity of content modeling, site IA, business logic, and templating increasingly lived in piles of configuration data for piles of plugin modules, with “glue code” spackling over the gaps.
At the same time, the community of developers who built Drupal and its plugins faced an identity crisis. It had evolved into an “anything tool”, a CMS that could handle incredible complexity… but baffled newcomers and frustrated developers used to lighter web frameworks.
Making it simpler to use required deciding which audience, which use cases, which tasks, “mattered.” Over the years, the Drupal community has put immense energy into resolving technical and architectural issues stemming from its organic evolution.
But the challenge of focusing on an audience remains. Content creators and editors for publications? Developers who need a customizable content store? Marketers who need “page building at scale?”
The answer depends on who you ask, and while it remains an incredibly powerful content platform, today it requires a great deal of expertise to make the content modeling, architectural, and UX customization choices necessary for a successful large-scale scale project.
The arrival of Drupal 9 this year is significant — it’s the first version of Drupal to really benefit from the painful years-long architectural revamp that started in version 7, and the first version that doesn’t require huge swaths of the plugin ecosystem to be rewritten.
Organizations that upgraded to Drupal 8 have a comparatively clean upgrade-in-place path to Drupal 9; they’ll be able to use their resources to focus on more fundamental questions about IA, editorial processes, content architecture, and long term goals.
…So, think carefully about what ideas, what mental models you bake into your cool product. Software shapes the way its users think about and decompose the problems they’re faced with, and that impact lasts much longer than the code itself.