Drupal 8.0.0 released

It replaced a commercial solution bringing more clarity (but that was also thanks to stricter rules in place defining types of docs, fields etc..), better graphic appeal (but just because the previous one was really crap) and also great search experience thanks to Apache Solr.

As I am a sysadmin, not a developer, I used all built-in modules except one that I modified in order to integrate the authentication with another business system via webservices (only code I developed). As I am also not a graphic, I worked with an external one (that prepared design in PSP so it was a bit a pain to convert it to template)

At that time (2009 I think) I reviewed few other options (WP, ezPublish, plone) but I chose Drupal because the authorisation system with roles etc.. was much more powerful than WP one.

Another issue is maintenance. I don't think I've ever met a well-maintained contrib module; even ones that seem to be actively maintained aren't what I would call "well" maintained...reported bugs don't get fixed, patches don't get accepted or commented on (I have a half dozen bugfix patches spread across three or four projects, including one for something in core, that have gotten no response, some for months). While Drupal doesn't suffer from the crass commercialization that has befallen much of the WordPress ecosystem, it seems only companies paying for development get any sort of response. I don't have a problem with developers prioritizing paying customers (I do it with my own Open Source software, as well); but, when someone sends a patch that fixes a bug, at least comment on why you don't want to integrate it or give some guidance on what would make it acceptable for integration. I am beginning to feel like submitting a ticket to the Drupal issue tracker, even with a patch to fix the problem I'm reporting, is a waste of my time. If it were one project or module, this wouldn't be such a big deal; individuals get busy. But, I can't think of any Drupal module or project that I've ever had a good experience reporting issues on. And, if I didn't know that development is still ongoing, and that many new sites are being developed with Drupal, I would assume this extraordinarily poor level of interaction in the tracker was indicative of the impending death of the project.

There is also an academic love of complexity and abstraction in Drupal, almost to the point of absurdity, at times. Every new release introduces vast swaths of new terminology (often used in ways slightly unlike the rest of the industry use the term). Entities, nodes, rules, entity bundles, content types, views, entity references, delta, features, fields, hook, machine name, taxonomy, etc. About half of these do not mean what I would have guessed or are used in subtly different ways from what I would have guessed. And, it's impossible for a casual Drupal developer to stay on top of this stuff; it moves so rapidly, and is so poorly documented, one has to read code. And, there's a lot of code. Somehow, despite all the abstraction, most modules include huge swaths of code, and aren't particularly re-usable. Even very simple functionality seems to require pages of code. It's often more of a pain in the ass to make the re-usable components work in some way that the developers didn't think of than it is to implement from scratch. Partly this is my own shallow knowledge of Drupal, but I see experts building out entirely new modules to address very similar use cases to other modules they've made, so I'm not alone. Somehow, despite WordPress' much uglier code base, I'm generally able to implement stuff more rapidly than in Drupal; and many things that seem really locked down and hard to change in Drupal seem easy in WordPress.

The upgrade path is literally disastrous for non-core modules. One literally can't get from point A (a Drupal 6 site) to point B (a Drupal 7 site) without writing a lot of migration code, unless you're only using the most basic of core functionality. I'm months into a migration from D6 to D7. The new(-ish) Migrate module requires writing code, sometimes significant amounts of it, and is extremely poorly documented (and uses a bunch of its own jargon in confusing ways; the number of contexts in which the word "migration" is used for different purposes makes my head explode), and in-place upgrades don't exist for a large number of modules, including pretty important ones (like Project Issue, the module used by Drupal.org for its own issue tracker...it has no working upgrade path, at all).

I see the benefits that Drupal 8 brings. And, having worked with Drupal 7 for a few months now during this migration, I see that the direction is a positive one. But, I find myself being angry a lot whenever I work with it, because there's so much forward momentum (everything changes! all the time!) but nobody seems to give a shit about bugs, major usability problems, or providing a reasonable upgrade path. Really basic stuff that ought to go without saying, really doesn't in Drupal.

So, it's a real love/hate relationship. Which is true of every CMS I've ever used (and I've used a lot). I have decided to stick with Drupal through at least one more iteration and will launch our Drupal 7 site in a few days (if I'm lucky), but I don't know if I'll ever migrate to Drupal 8.

WordPress's out-of-the-box post install experience is a lot nicer and a lot closer to being a "finished" and ready site.

Performance has been a specialty for me in my own drupal career. Drupal 8 is a whole new ballgame, though. Cache tags are built in from the ground up, and the page render/caching engine is built to mimic a reverse proxy. Rasmus Lerdorf (creator of the PHP language) benchmarked a pre release of drupal 8 at >2500 page views per second with 20 concurrents.