[mgkimsal]

> It's just impossible to match it with the number of extensions

It's almost precisely because there's very little uniformity between anything.

It's often much more efficient to just install a new wordpress, migrate some content over and start 'fresh' than it is to modify an existing theme with new functionality; just find a different theme that does what you want and migrate your content and images over to that.

That said, I seem to remember drupal's CCK impressing me some time ago - if that was a default option (IIRC at the time it was a separate plugin) that might have done more for Drupal's "configurability ease" story early on. But.. I may be misremembering with rose-colored glasses.

[rhblake]

CCK has been part of Drupal core since version 7 (2011). Now simply known as "fields". Fields+views is simply fantastic compared to what WordPress - including its plugins - gives you. (Views will by the way be in Drupal 8 core.)

[mercer]

In my experience the problem with Drupal is that on the one hand it's too customizable, and on the other it will never beat a proper code-based framework in actual ease of customization.

Because it's so customizable, it's admin interface is too complex for many users. It has to be to be as customizable as it is. And to get a site going you often need to do a whole bunch of work up-front: configuring views, creating content types, taxonomies, rules, workflows, etc. This is often not needed with Wordpress because you just pick a theme, dump in a few plugins if necessary, and it 'works'.

On the other hand, if you really do need all that customization, you're often better off with a proper framework like Ruby on Rails. You can build features in code rather than clicking around the CCK/Fields/Views interfaces, and keep them and other configuration in version control. Most importantly, if you're capable of building complex views and workflows in Drupal, you probably have the ability to do so in code as well. And the latter is generally better in every way if you are capable of it.

Drupal strikes me as the kind of thing that looks good on paper, and that project managers would like, because in theory it can be customized by anyone, and in theory you can build anything you need with it, all without writing code!

In practice, however, you end up paying a lot to get Drupal developers/consultancies to fix whatever mess you're left with. And what do most of these shops do? Use things like the Features module to store everything in code/configuration files, which kind of goes against the whole point of using Drupal in the first place.

The end result is that nobody is really happy, other than perhaps the Drupal consultants who happen to know the ins and outs of the crufty framework/CMS hybrid, and can charge a premium for their knowledge of the dark internals of Drupal.