When was the last time that people had an easy enough time of keeping their drupal sites up-to-date with the latest patches without breaking their existing site ?
This is a major and often overlooked problem, it really isn't rare for minor (often security related) upgrades to break the site. You then have two choices, dig in (which is what you should do) or roll back (which is what plenty of people do) and cross your fingers.
Sure, they only have themselves to blame. But still, the number of out-of-date drupal sites out there is very large.
If the upgrade process (and imo that's drupals achilles heel) would be smoother a lot of these headaches would go away.
It's the major version updates where APIs change that are tough and it's no different for any other project with an ecosystem as large as Drupal's.
If it works. I've seen several cases where such a minor update broke the system in non-obvious ways.
> It's the major version updates where APIs change that are tough and it's no different for any other project with an ecosystem as large as Drupal's.
That's a real problem and I think it is seriously limiting.
Over the years I've upgraded quite a few pieces of software with at least as large an ecosystem (Apache, linux, python, PHP to name a few) and I've never had things break as spectacularly as with drupal. There really is no excuse for this, it is causing a lot of grief and a very negative experience for drupal users.
Instead of chasing the features I really think drupal should start to take backwards compatibility and API design a lot more serious than they've done to date.
There seems to be some movement in that direction, but they haven't made it the central point of their offering yet.
Until they do I'll be advising people against using drupal, because effectively I'd be telling them that within two years they can throw their site away.
To make an architectural analogy, the foundation you build on should be at least as long lived as your house. Otherwise you have a very serious problem.
In other words, a system one doesn't know is useless to someone who knows an other system with a similar purpose. Right. Use the system you know.
While I agree with some of this critique, here are some points I take issue with.
>Databases are great for storing passwords, content, and countless other things. These things do not include “views”, i.e. templates. That’s right, templates. In the database. Drupal stores templates in the database.
Views are not templates. Views are more analogous to database queries. Drupal does, in fact, store templates in the filesystem.
>Drupal has a history of security vulnerabilities and is written in ugly spaghetti code
Ironically, the OP's blog post is hosted in WordPress, a PHP project that, unlike Drupal, has had security response issues.
Drupal's security response is great. When's the last time an update-to-date Drupal site was hacked? The code isn't object oriented, but is clean and a coding standing is upheld.
>Gripe #4: Drupal’s None Too Friendly
Drupal's community is one of the friendliest, non-elitist out there. Really. The Drupal project has a higher percentage of women involved than any other open source project of a comparable size.
>There’s been quite a backlash over Drupal’s new trademark policy, which is rather contrary to the spirit of open-source software.
The backlash has been by folks who don't realize that protecting trademark is standard practice for large open source projects. Look at the license of MySQL, for example.
>Drupal's search sucks
What CMS, out of the box, has a search that doesn't suck? Use Solr or Sphinx.