OK, that title's a bit clickbait. We love Drupal. It's a long-term relationship. Many of us have been using it for over 10 years now. But nothing's perfect. It's always good to learn what you could do better. Continuous improvement is our mantra at Code Enigma and we want to support Drupal in being the best it can be.

Rather than working on what we think Drupal should do though, we asked our clients and friends what they think Drupal should do. (The question is forever open, by the way - feel free to join in.)

This post quickly summarises the top three at time of writing, in no particular order…

"Date and calendar. Properly."

The Date API module mostly moved to core with Drupal 8, but there's a load of ongoing issues, so this is a fair comment. There's an opportunity to put some development and design weight behind Date in core and help push some of these issues along.

And porting Calendar to Drupal 8 seems to have died early due to lack of time. I've skimmed the issue. It seems it became too complex and ultimately got closed out. There's a decent calendar and views module called Fullcalendar View, which looks well resolved.

As a quick win, someone could do a video tutorial of that module (assuming there isn't one at this time) to help those struggling with calendars in Drupal 8.

More generally, this just needs someone to throw some organised time at it, starting with some community liaison to find out what would be the best use of time.

We're going to look into this.

Editor experience

We had some interesting feedback on this:

"A tighter and more focused editorial experience out of the box. A tough ask given the variety of use cases, but Drupal often feels a bit wobbly and disjointed in comparison to lighter products like Forestry, TinaCMS or NetlifyCMS. May not be a fair comparison but there's acres of room for improvement in my opinion and would make selling it into teams and refining its usage that little bit easier."

Some time ago there was a major UX piece around Drupal 7, which was something of a watershed moment for Drupal. The good work has continued, there is a Usability Initiative page on Drupal.org which is wonderful to see. Most would agree there is always room for improvement, so the initiative is a great place to focus your effort if you're interested in helping.

If you, like us, want to see Drupal get better, and you have design and UX chops, this initiative could be for you. Because before we build, we need to understand what works.

Data versioning

This is a curious one. It's come up several times but it's mostly the concern of large, mission-critical web applications (to illustrate the point, two of the organisations that mentioned it in our survey were reliant on e-commerce as their business model and a major charity respectively). And the challenge isn't always articulated the same way, for example, one comment was "updates without downtime/maintenance mode" but that's basically the same thing.

It's also a huge undertaking because, as UK Drupalista Eli pointed out in Slack, there are a lot of moving parts:

[…] there was a talk at PHP London where Rasmus Lerdorf talked about how they achieved this at Etsy (I don't think it was recorded but he may have given this elsewhere). They versioned the database, cache keys, routes (maybe other things) because you have to exist in a world where you could be using either schema.

(If anyone has that talk, I'd love to see it.)

The fundamental problem is the way Drupal modules and core are currently developed. There's no promise of backwards compatibility of the schema and other data. That pretty much stops the cool stuff like blue/green deployment, especially with a large database. Your new code might not work with your old database. Your old code might not work with your new database. You basically have to take Drupal offline, deploy the new code, run the database updates and bring Drupal back up again. If anything goes wrong, you have to put your old database back before you can safely use your old code.

What people would like is for Drupal to decouple data from code and allow a point-release of rollback, so the workflow could be different. The process could then be leaving your website online the whole time, update the schema (and other necessaries) then update the code. Job done. Anything goes wrong you revert to the old code. Any database changes were not destructive and the database still works with the previous version.

That's a huge undertaking. There are some workarounds, for example, our deployment scripts support the Read-Only Mode module, which allows you to prevent writes to the database while you're upgrading. Not ideal, but you don't need to go offline. A quicker win to please some of the respondents might be something like this becoming a core option, so while you still can't flip between codebases, at least you don't have to go entirely offline during a deployment.

In any case, there should be some lively discussion around this point at Drupal events during 2020, if there's nothing yet going on. In a world where we're competing against microservices that are specifically designed to have versioned databases, so they can use the most modern continuous deployment techniques, there's a risk of obsolescence here.

Those are the main points. Next step for Code Enigma is to do a bit more fact-finding around these and see if/where we can help. Get in contact.