This is based on a project I did for the agency A&B One Digital, to implement a customer engagement platform for endica, which is a service provider for communal energy suppliers.
The customer wanted something akin to a mini-Facebook, so we chose Open Social as the starting point for this project. It provides a multitude of community features, among them a timeline-like content feed, event signup, groups, and private messaging.
Most people categorize Drupal as a framework and not a content management system. This comes from its core principles: modularity and flexibility.
Where other systems decide on a fixed set of properties that represent “a page”, Drupal disaggregates and abstracts into nodes and fields. As a result, each Drupal deployment develops its own unique content model over time. The fact that everything is configurable, even after the development phase is over, means you have a system that can grow and change with you, instead of being replaced after a few years.
Open Social embraces this modularity, offering a buffet of features you can pick and choose as needed. For endica, this was the a perfect fit, as the previous platform was based around forums dedicated to distinct topics. This could be emulated with the social groups feature, which allows aggregating users and content around a subject.
In some industries, having a data lake is an innovation. For editors who have worked with Drupal for a longer time, this is an old hat. Every content in Drupal lives in one big tub, with the meaning and structure created by orthogonal tools like menus and views.
This flexibility of how to structure your content has some downsides, of course. People who are new to content management, or who have previously worked with a much more restricted CMS, will need to adjust and learn quite a bit.
As the sea grows, it becomes harder and harder to keep the overall view of what you have. Giving meaningful names to nodes becomes necessary. Ten nodes called ‘Contact’? Bad idea.
Another small feature of Drupal that helps a lot: integrating contextual links in the template makes edit buttons appear right next to the rendered items in the frontend. This way the navigation of the page can be used to find what you are working on.
The way Drupal works internally, almost any aspect of how it works can be modified. Hooks allow influencing core and extension functionality at a myriad of points; the template hierarchy makes it is possible to extend the backend with very little effort. Any displayed piece of data can be amended this way.
Drupal makes no difference between how the backend and frontend work, both go through the same routing, same controller (page callback) mechanism, and same template rendering. As a result, there is a huge number of third-party modules that make Drupal even more powerful.
When you have a customer with a long whish list, this is great. It changes how you work a little, less coding and much more configuration, but it also happens to make setting up a working system extremely fast.
If you would like to know more about my experience with Drupal, feel free to send me an email.