Drupal Inconveniences

I have been using Drupal for at least five years now and I’m thinking highly of it. But even though Drupal is an amazing CMS with tons of possibilities, it lacks at least a few things. However, the list of things that annoyed me shrunk more and more with every new version of Drupal. So this list of things that annoyed me recently might be outdated with the next version of Drupal.

Reasonable text formaters/filters

I always write without using WYSIWYG editors, and because of that I end up writing HTML instead. It’s not much of a problem, but it still is quite annoying to be forced to interrupt your writing flow just to highlight something. That is especially bad with a German keyboard, because almost all the important characters (like <, =, ” or /) are only accessible via modifier keys.

What I would like is a simple, wiki-like markup that would be converted to HTML with a filter. Flexifilter looked quite promising, but the GUI really frustrated me. It’s inability to keep the order of the rules, the inflexible positioning of the rules (it’s not possible to move a rule into another hierarchy level), the impossibility to name and in return identify the rules and last but not least the cluttered interface, which makes it impossible to see at a glance where you are now and what you are doing annoyed me like the WordPress theme system did when I started blogging 360 years ago.

Update: Programming a custom filter turned out to be childs play (and it’s a lot easier, than using Flexifilter). I’ll play with it a little longer and maybe post it here when it’s ready.

Asset and Image Management

This really is messed up in Drupal. The upload module does work, but you cannot even look what files are on the server and you cannot see a preview of uploaded images (although there are a lot of complicated possible module combinations to achieve that).

Deployment

Drupal gives you a lot of configureability, which is good. Sadly all the configuration goes to the database, is stored in different tables and together with the content. There is no real separation of configuration and content. The result is, that you cannot track the configuration like you can track your source code and that you cannot deploy the configuration alone without the content. The real life looks like this: First, try a configuration option, or more often a complex set of options, on the development site until you have achieved the desired result. And then reproduce all the steps you did previously on the production site.