Except that Drupal is, interface-wise, even worse than Wordpress; and management of the damn thing is difficult even for the developers among us. It's hard to recommend it when you know clients/users will struggle with it.

>and management of the damn thing is difficult even for the developers among us.

Understatement of the year so far.

I love Drupal, but since there's no bright line separating configuration and content, rolling features up from a dev environment to staging to live can sometimes be a nightmare, particularly if the Features and Strongarm modules don't have you covered.

Agreed. Drupal has an incredibly steep learning curve. I was told to learn PHP BEFORE using Drupal and it's been a huge advantage. I can't imagine a non-developer trying to change some content or add a feature themselves.

Drupal is extremely powerful, but would be a nightmare for users used to the WP platform.

I have been presented with relatively straightforward CMS site concepts and come to the conclusion that they would be better done in Rails or Django than Drupal because a) it would be easier to present a usable interface, and b) those would actually be less likely turn out looking like a tower of paperclips and bubblegum.

This may just be my lack of experience in Drupal talking (I've got plenty of experience in PHP, just not Drupal), but I put a pretty decent amount of thought into the matter and even mocked up simple prototypes just to see if there was something I was missing.

The big difference is that in Drupal it's possible to get pretty far without ever writing a single line of code, even templates. For some use cases that's very powerful, especially an environment where you have trainable, reasonably technical people who aren't programmers.

But for the talented developers and/or programmers on the team, it's a complete productivity and sanity drain. Moreso if you're, say, part of HN's target audience, because you'll know all the modern web development techniques, and you'll be able to use none of them.

I have had an absolutely terrible experience with it, which sadly isn't unique amongst these big PHP projects.

It's not bad once you get your head around it. Sure, it's not buzzword compliant (MVC, TDD, ORM OH MY!) but for what it is, it can be pretty compelling.

My primary job for the last 2 years has been developing a Drupal site for a group of daily newspapers with monthly page views in the low 8 figures.

We were in a situation where we had to get a site up quickly (Our small group was bought off from a much larger conglomerate, so the huge $$$$ Java system we had been using went away). Drupal allows us to get a tolerable site up in about 3 months, and a much better site up about 6 months later. Have there been pain points? Sure. But if we'd used anything else there's no way we would have been on our feet nearly as quickly.

Are we investigating other options? Of course, if I wasn't I wouldn't be doing my job. There's a part of me that would love to rewrite the whole thing in Rails or Django. That would be a huge undertaking though.

I really don't doubt that for many people it has its place, as evidenced by your experience, but the moment you want any semblance of interactivity (at which point you can argue that a CMS is the wrong tool for the job) or efficiency/optimisation, you're screwed.

We've had different experiences, but I wouldn't touch it with a 10' bargepole, not any more. And I'm glad I've been managing to encourage my boss to start moving away from it. The only positive thing I've been able to take from it is a list of things never to do in my own code.

Like I say, it's not just Drupal. It's a side-effect of over-complication in the name of simplicity, and trying to run in parallel a system that makes it easy for non-devs to use. It's a recipe for disaster if you want lean, maintainable code.

Depends. We serve ~40 PHP requests a second (and that's NOT counting stuff that hits the cache) on reasonable hardware - an 8G webserver VM, and a 4G DB VM, both with 4 cores allocated, and hot copies of each for failover. Our site is pretty interactive, and even the stuff that's cached is short (5 minutes or less) timeouts.

The drawback to that is that all configuration goes into the database making deployment very, very difficult.

Oh, and it causes performance problems too.

Handing a Drupal website over to a client was always hard. No wysiwyg, no automatic updating, built-in dependency hell (that the client can see in /modules), _constant_ warnings about module updates and security updates and core updates and updates of every other kind, make Drupal an extremely tough sell.

Just a few nitpicks;

Drupal does have wysiwyg implemented as a module http://drupal.org/project/wysiwyg (actually several competing editors are possible),

Drupal also can do automated updates, though I wouldn't advise it. Drush works for it, http://drupal.org/project/drush and a lot of people use it with great success. You would want a carefully vetted rollback plan though. The better road is to forgo updates other than security until scheduled maintenance or a MUST have feature is present. The GUI /update process is actually quite nice if you've set everything up properly.

The thing about Drupal is doing everything doesn't have to be painful, but if you've approached it in a "non-Drupal" way it can get bad quickly. Drupal is complex and the hand off to a customer is never easy with complex software. Have you tried the same with Plone?

When was the last time you tried Drupal?

Yep when we had to do work on drupal sites all the junior staff where frightened to even change add a small piece of content as the interface was so bad an the sites where prone to breaking if you made innocuous changes.