Drupal Sucks(robozen.com)
robozen.com
Drupal Sucks
http://robozen.com/technology/drupal-sucks/
25 comments
Hint, hint: you will not build a production quality CMS in a day or two, nor a month or two. Not with Rails, not with pixie dust.
This is absolutely true. The core of my Rails site, prior to adding the web application, was essentially a gussied-up single-purpose CMS. It is not publicly accessible, supports one fairly easy editing workflow, doesn't have to worry about e.g. HTML input, would be very insecure if my freelancers were of a mind to destroy me, and very, very uncustomizable as compared to e.g. Wordpress or any site you could cobble together from Drupal plugins.
Even with all that, the CMS portion of my site would take me probably about a week to build from scratch. There's just a lot more to it than the 15 minute build-a-blog video.
This is absolutely true. The core of my Rails site, prior to adding the web application, was essentially a gussied-up single-purpose CMS. It is not publicly accessible, supports one fairly easy editing workflow, doesn't have to worry about e.g. HTML input, would be very insecure if my freelancers were of a mind to destroy me, and very, very uncustomizable as compared to e.g. Wordpress or any site you could cobble together from Drupal plugins.
Even with all that, the CMS portion of my site would take me probably about a week to build from scratch. There's just a lot more to it than the 15 minute build-a-blog video.
I think the post speaks much more generally to why CMS's suck in general. I've developed sites using Drupal and reviewed many many others when I was deciding what to use.
Most of the weaknesses of Drupal are shared by all other CMS's. The author's alternative is to custom code a solution using Rails. (or some other framework)
That way, you don't have to worry about all the cruft that goes into a CMS codebase to make it flexible and support everyone's needs.
All that said, I still don't think Drupal sucks. It can definitely be frustrating to use and configure, but in a situation where you need to have laypeople or relative laypeople making changes to a site and its functionality, beyond merely adding and editing content, its the best option.
Most of the weaknesses of Drupal are shared by all other CMS's. The author's alternative is to custom code a solution using Rails. (or some other framework)
That way, you don't have to worry about all the cruft that goes into a CMS codebase to make it flexible and support everyone's needs.
All that said, I still don't think Drupal sucks. It can definitely be frustrating to use and configure, but in a situation where you need to have laypeople or relative laypeople making changes to a site and its functionality, beyond merely adding and editing content, its the best option.
The author's alternative is to custom code a solution using Rails. (or some other framework)
This reminds me of an old Steve Martin routine:
"How can [you] be a millionaire... and never pay taxes?
First.. get a million dollars."
If you've got your hands on a developer who is capable of custom-coding your solution in Rails within your timeframe, and you can afford to pay them to do it, and to pay them to maintain and augment it, and to cajole them into writing extensive documentation (they have, after all, built a custom solution, so if you want to read the manual they have to write the manual), and to recruit and pay a series of equally-talented successors to replace them when they get bored, and to pay a security auditor to look for the custom-built security holes in their custom-built code -- then, yeah, you don't have a problem. It must be nice to be you.
But when, as a Drupal consultant, I would suggest to my more... imaginative prospective clients that their proposed projects were outside Drupal's sweet spot and that they should instead look for a Rails developer, it tended to stun them into silence. It was like suggesting that they recruit and hire a brain surgeon.
People are desperate to find halfway-competent Drupal developers -- and, though it does have a learning curve like the face of El Capitan, Drupal is much easier to pick up than Rails, unless you are already a Java developer. [1] Competent Rails developers are far harder to find. They're all too busy applying to YC, plotting to take over Java shops, or counting their profits. ;) [2]
---
[1] To get started in Drupal, you don't necessarily need to know what "OO" means. You don't need to know what MVC means. You don't need to know what REST is. You don't need to know what "routing" means. You don't need to know what SQL is or write a single migration. You don't necessarily need to use the command line, or a text editor, or -- god help us -- a version control system. Drupal is written in PHP, but you don't necessarily need to know any PHP.
Of course, to the extent that you don't know any of these things, you are going to hit the wall someday, perhaps painfully. But at least you won't find yourself staring at a blinking cursor on day one, wondering how to start your application.
[2] And if you hire an incompetent Rails developer, you will find yourself wishing that you'd simply set a pile of dollar bills on fire.
This reminds me of an old Steve Martin routine:
"How can [you] be a millionaire... and never pay taxes?
First.. get a million dollars."
If you've got your hands on a developer who is capable of custom-coding your solution in Rails within your timeframe, and you can afford to pay them to do it, and to pay them to maintain and augment it, and to cajole them into writing extensive documentation (they have, after all, built a custom solution, so if you want to read the manual they have to write the manual), and to recruit and pay a series of equally-talented successors to replace them when they get bored, and to pay a security auditor to look for the custom-built security holes in their custom-built code -- then, yeah, you don't have a problem. It must be nice to be you.
But when, as a Drupal consultant, I would suggest to my more... imaginative prospective clients that their proposed projects were outside Drupal's sweet spot and that they should instead look for a Rails developer, it tended to stun them into silence. It was like suggesting that they recruit and hire a brain surgeon.
People are desperate to find halfway-competent Drupal developers -- and, though it does have a learning curve like the face of El Capitan, Drupal is much easier to pick up than Rails, unless you are already a Java developer. [1] Competent Rails developers are far harder to find. They're all too busy applying to YC, plotting to take over Java shops, or counting their profits. ;) [2]
---
[1] To get started in Drupal, you don't necessarily need to know what "OO" means. You don't need to know what MVC means. You don't need to know what REST is. You don't need to know what "routing" means. You don't need to know what SQL is or write a single migration. You don't necessarily need to use the command line, or a text editor, or -- god help us -- a version control system. Drupal is written in PHP, but you don't necessarily need to know any PHP.
Of course, to the extent that you don't know any of these things, you are going to hit the wall someday, perhaps painfully. But at least you won't find yourself staring at a blinking cursor on day one, wondering how to start your application.
[2] And if you hire an incompetent Rails developer, you will find yourself wishing that you'd simply set a pile of dollar bills on fire.
You can make a production quality CMS in a few days as long as it is specialized. Genericity is the productivity killer.
I spent some time revamping my website last weekend after having done no web development for about 4 years. I roughly split up my time like this: -2 hours to build a proxy to S3 in GAE (Custom) -2 hours to set-up a pure-Java PHP implementation on my GAE proxy (OSS) -3 hours to set-up a WebDAV interface to S3 in GAE (OSS) -4 hours to create XSLT templates and build them automatically (Custom)
I use NetDrive to connect to S3, and Kompozer to edit the content. Highly scalable, nearly free website with a perfectly good CMS and no need to make back-ups. Updating the software or adding services is as simple as typing my password in Eclipse. (by the way, everything in Java)
Over the years I've found web developers are not the smartest types.
I spent some time revamping my website last weekend after having done no web development for about 4 years. I roughly split up my time like this: -2 hours to build a proxy to S3 in GAE (Custom) -2 hours to set-up a pure-Java PHP implementation on my GAE proxy (OSS) -3 hours to set-up a WebDAV interface to S3 in GAE (OSS) -4 hours to create XSLT templates and build them automatically (Custom)
I use NetDrive to connect to S3, and Kompozer to edit the content. Highly scalable, nearly free website with a perfectly good CMS and no need to make back-ups. Updating the software or adding services is as simple as typing my password in Eclipse. (by the way, everything in Java)
Over the years I've found web developers are not the smartest types.
I don't think CMS means what you think it means ...
You have to manually edit files and code to do things. And that's fine - that's how my website is run too.
But that isn't a CMS. A CMS provides a pretty interface for everything content managers need to do. It allows non-technical people to publish, edit, and collaborate. It has a publishing system so modifications can be approved before being pushed live (which in turn implies an access control system).
You have to manually edit files and code to do things. And that's fine - that's how my website is run too.
But that isn't a CMS. A CMS provides a pretty interface for everything content managers need to do. It allows non-technical people to publish, edit, and collaborate. It has a publishing system so modifications can be approved before being pushed live (which in turn implies an access control system).
I don't edit the pages directly. I edit the content using Kompozer (wysiwyg web authoring) and that gets automatically transformed into a website.
I'm a MySQL DBA, I occasionally work on a database that hosts a few large Drupal sites. While I disagree that Drupal simply sucks and that you'd be better off hacking your own homebrew CMS in rails, the author does make some valid points.
Drupal does indeed store logs in the database, in a table called 'watchdog'. One problem I've run into is that if a popular page generates a bunch of warnings, there ends up being a pretty heavy write load on this table. It doesn't help matters that it's usually a MyISAM table, which means that all these writes stack up when the table gets locked, say when Drupal wants to do prune old entries. I've seen this nearly exhaust all the available MySQL threads. I think there is a module that you can use to stop this behavior. Alternately you can alter the table to use the BLACKHOLE engine.
One thing the author didn't mention, is that Drupal's content search is really bad. In order to perform multiple keyword searches it ends up generating these massive queries that join tens of search index tables. These queries can kill the MySQL join optimizer which can ultimately bring your MySQL server down.
http://drupal.org/node/514366
While this bug has been fixed, the search queries are still gnarly and slow. If you're planning on running a Drupal site with a lot of content you'll definitely want to investigate an alternate search system, perhaps using something like Sphinx or Lucene.
Drupal does indeed store logs in the database, in a table called 'watchdog'. One problem I've run into is that if a popular page generates a bunch of warnings, there ends up being a pretty heavy write load on this table. It doesn't help matters that it's usually a MyISAM table, which means that all these writes stack up when the table gets locked, say when Drupal wants to do prune old entries. I've seen this nearly exhaust all the available MySQL threads. I think there is a module that you can use to stop this behavior. Alternately you can alter the table to use the BLACKHOLE engine.
One thing the author didn't mention, is that Drupal's content search is really bad. In order to perform multiple keyword searches it ends up generating these massive queries that join tens of search index tables. These queries can kill the MySQL join optimizer which can ultimately bring your MySQL server down.
http://drupal.org/node/514366
While this bug has been fixed, the search queries are still gnarly and slow. If you're planning on running a Drupal site with a lot of content you'll definitely want to investigate an alternate search system, perhaps using something like Sphinx or Lucene.
It boggles my mind that NO ONE has mentioned that a CORE module of Drupal that is simply not switched on by default is Syslog. So what if the CMS logs to the database by default? If you know better, switch that off (you have been able to do this since V6 started using dblog and NOT Watchdog) and log using Syslog. Come on people, wake up!
Check these: * http://drupal.org/handbook/modules/syslog * http://drupal.org/handbook/modules/dblog
Check these: * http://drupal.org/handbook/modules/syslog * http://drupal.org/handbook/modules/dblog
The majority of the drupal sites out there are stuck on 5.x and can't upgrade because of the lack of a simple upgrade path.
Upgrading should not be an order of magnitude more work than installing and building the site in the first place.
Upgrading should not be an order of magnitude more work than installing and building the site in the first place.
Majority? Where's your proof? I think "majority" is just conjecture... show me some numbers and I'll believe you.
Ok, you're right, it's just conjecture, but that conjecture is based on looking in to a whole bunch of sites using drupal.
Let me go do my homework and get back to you on that to see if it is the same across a larger sample.
Let me go do my homework and get back to you on that to see if it is the same across a larger sample.
Awesome. I tried finding some numbers myself, but was disappointed in the lack of data. Would be glad to see what you find...
Drupal.org tracks download statistics for contributed modules. So one way to get a sense of how many Drupal 5 sites are out there in comparison to Drupal 6 sites is to look at the versions of popular modules that are getting downloaded. In particular, see CCK and Views.
No, that won't work. You need to know what version someone started on. That's the bigger problem in finding migration data, to find out when someone joined up.
If someone started at version 4 and they've kept current all the way through to version 7 then that would be the kind of stuff we're looking for.
After all, the point I was trying to make was that it is very hard for people to upgrade across major versions, so plenty of them are stuck with whatever was 'hot' when they first started out.
The knowledge required for migrating drupal to a higher level version is a lot more involved than for building the website in the first place.
If someone started at version 4 and they've kept current all the way through to version 7 then that would be the kind of stuff we're looking for.
After all, the point I was trying to make was that it is very hard for people to upgrade across major versions, so plenty of them are stuck with whatever was 'hot' when they first started out.
The knowledge required for migrating drupal to a higher level version is a lot more involved than for building the website in the first place.
Solr seems to have emerged as the new Drupal search standard.
Or perhaps not using MySQL. Table locks indeed, this is 2009!
Meh, it's not so much MySQL that's lame in this case, it's just the MyISAM engine, which depressingly enough is still common in 2009. MyISAM is based on IBM mainframe database technology developed back in the stone age. The InnoDB engine doesn't have these kinds of locking issues.
Getting Drupal to run on a non-MySQL database is non-trivial. Here's an interesting article detailing what folks at Oracle had to do to get it to run on Oracle.
http://www.oracle.com/technology/pub/articles/pedros-drupal....
Getting Drupal to run on a non-MySQL database is non-trivial. Here's an interesting article detailing what folks at Oracle had to do to get it to run on Oracle.
http://www.oracle.com/technology/pub/articles/pedros-drupal....
The article was written about an effort using Drupal 4 ... and it turned out to be suprisingly easy due to the structured nature of the Drupal database api. Did you read the stuff??
I stand behind my use of the phrase "non-trivial". The fact that Drupal has a reasonably clean DB communication layer that separates out bind variables to avoid injection attacks was why they didn't give up on the project at the start. I doubt anyone involved in the project would describe the effort as "surprisingly easy".
Unfortunately, while drupal ostensibly supports other database backends, the reality is that it doesn't support other database backends.
This is something that is being rectified with the upcoming Drupal 7. This is a rather tough nut to crack because different database servers don't actually have compatible SQL syntax even among some basic queries. A lot has been done to improve this, including an API to declare database tables in a way which is SQL server neutral. And Drupal 7 will also have query builders to deal with differences in syntax among some of the more basic queries.
It's not even a matter of SQL syntax. Oracle, for example, uses cursors implicitly and declaring a cursor just gives you a handle to it. In SQL Server, using a cursor is an expensive operation. So if you are trying to be database-neutral, do you use cursors or not? How does that affect the likelihood of deadlocking? Etc etc etc.
In practice if you try to be database agnostic you end up with something like SAP which runs like molasses in Winter equally on all databases...
In practice if you try to be database agnostic you end up with something like SAP which runs like molasses in Winter equally on all databases...
The problem is not enough abstraction. If your application code sees things like cursors or SQL statements, your design is broken.
I'm talking about inside Drupal itself. Locking strategy is another one: it's impossible to optimize for one database without sucking on another. Lots of developers with experience only on one don't even know they're doing it, they think this is just how databases work.
Being database agnostic makes as much sense as trying to write code that compiles in both C and Java.
Being database agnostic makes as much sense as trying to write code that compiles in both C and Java.
Being database agnostic makes as much sense as trying to write code that compiles in both C and Java.
Maybe if you are writing the realtime transaction processing system for Visa... but this is a CMS. Flexibility is more important than absolute speed. 99% of page views are going to be served from the cache.
Maybe if you are writing the realtime transaction processing system for Visa... but this is a CMS. Flexibility is more important than absolute speed. 99% of page views are going to be served from the cache.
The percentage of page views served from cache depends on the type of site you're building. Newspaper site? Sure, cache it all. Social network? It's going to be tough to manage a cache when the content is constantly changing and is viewed differently by each user.
This all sounds like a nightmare for the casual/less-proficient developer to figure out. Is this a problem that a majority of Drupal developers face?
I use Drupal. Drupal was the only option for me when I started Windy Citizen. Drupal gets a qualified thumbs up from me.
That said, it does "suck" in many ways. For example: http://drupal.org/node/65922
I build WindyCitizen in Drupal 5 because when I started, 18 months ago, Drupal 6 was still just a baby release and most major modules hadn't yet been upgraded.
I'm now at the point where I need to upgrade the service to D6 to continue getting new releases of modules I'm using. Unfortunately, upgrading a 70+ module Drupal site is a major undertaking that appears to require a team of developers. One to follow the instructions and another to clean up and troubleshoot the exploding messes that result from following said instructions. I put myself in this position by choosing Drupal, but having to raise money to hire people to help upgrade your site is not my idea of a good time.
That said, it does "suck" in many ways. For example: http://drupal.org/node/65922
I build WindyCitizen in Drupal 5 because when I started, 18 months ago, Drupal 6 was still just a baby release and most major modules hadn't yet been upgraded.
I'm now at the point where I need to upgrade the service to D6 to continue getting new releases of modules I'm using. Unfortunately, upgrading a 70+ module Drupal site is a major undertaking that appears to require a team of developers. One to follow the instructions and another to clean up and troubleshoot the exploding messes that result from following said instructions. I put myself in this position by choosing Drupal, but having to raise money to hire people to help upgrade your site is not my idea of a good time.
Well, that's a function of the complexity and the customisation of your site.
You use 70+ modules? Probably some custom work as well. There's just no easy way to get that. Drupal or no Drupal. You can DIY, which comes with its own troubles.
You could probably do a lot of what you do for free in a couple of hours with Slinkset or a few days with a custom reddit. But if you want to define so much functionality exactly the way you want it, you have complexity.
No way around it.
You use 70+ modules? Probably some custom work as well. There's just no easy way to get that. Drupal or no Drupal. You can DIY, which comes with its own troubles.
You could probably do a lot of what you do for free in a couple of hours with Slinkset or a few days with a custom reddit. But if you want to define so much functionality exactly the way you want it, you have complexity.
No way around it.
Reluctant upvote. Drupal's what I learned in high school. It gives you pretty unparalleled control over your site. Conceptually it's a league above any of its competitors: You can do some incredible things with it without knowing any coding.
It's also ugly and hostile and maintained by some of the least friendly people I've ever had to deal with on a project. There's an insane arrogance in the community.
I wish there was something just as flexible but better. As it is, the choice is between stiff and ugly.
It's also ugly and hostile and maintained by some of the least friendly people I've ever had to deal with on a project. There's an insane arrogance in the community.
I wish there was something just as flexible but better. As it is, the choice is between stiff and ugly.
>There's an insane arrogance in the community.
My experience with the Drupal community has been the opposite. The Drupal community, more than any other project with a similar size I can think of, makes a conscious effort to get people at various skill levels involved (encouraging non-devs to do documentation, etc.). Also, there seems to be more women involved in Drupal than projects of a similar size.
My experience with the Drupal community has been the opposite. The Drupal community, more than any other project with a similar size I can think of, makes a conscious effort to get people at various skill levels involved (encouraging non-devs to do documentation, etc.). Also, there seems to be more women involved in Drupal than projects of a similar size.
Upvoted for the women observation, which I've noticed, too. It speaks well for them.
I can't agree with you more. I recently finished a pretty big project in Drupal that featured some custom functionality that we had to write ourselves. Not only was it a tremendous hassle to get everything to work nicely with all the other modules but the codebase is just ugly and as the article states has a very high learning-curve.
As you say it gives awesome flexibility, but it most definitely comes at a price.
As you say it gives awesome flexibility, but it most definitely comes at a price.
Sorry to self-promote, but I'm the creator of a Drupal competitor that may be worth looking at for you:
http://www.sitellite.org/
It's a mature project (9 years old, so yes there is some cruft, hell PHP 4 was brand new when it started!), but doesn't have the same community size as something like Drupal. It does have a clean UI, decent documentation (manual, courses, API reference, etc), several dozen modules, and while there is a developer learning curve, it's really flexible once you get into it.
http://www.sitellite.org/
It's a mature project (9 years old, so yes there is some cruft, hell PHP 4 was brand new when it started!), but doesn't have the same community size as something like Drupal. It does have a clean UI, decent documentation (manual, courses, API reference, etc), several dozen modules, and while there is a developer learning curve, it's really flexible once you get into it.
Since you've already decided we're "ugly and hostile", I'd like you cite certain examples of this hostility. I've been in the community for almost 3 years now, and its by far the most insanely-motivated and awesome community I know.
I've run into several archetypal "freetards" in the Drupal community - you probably know the type: To any criticism they say, "Well, you were lucky enough to have been given the source for free, and if you don't like it, go write something better!"
I've also found a large part of the Drupal community to be non-technical users attempting to help each other with various technical problems such as module or database upgrades. I never saw this amazing community that i've heard people mention - so I assumed there must be an invite-only mailing list somewhere.
I've also found a large part of the Drupal community to be non-technical users attempting to help each other with various technical problems such as module or database upgrades. I never saw this amazing community that i've heard people mention - so I assumed there must be an invite-only mailing list somewhere.
Your second point is pretty spot on. Asking for technical help in Drupal forums almost guarantees a response from a well-meaning non-technical person who likely can't help you.
Asking in a module's issue queue can be hit or miss. If it's a major project, you'll get a response and it'll be "this has been asked before, here's the link." That's great.
More likely you'll never hear a response.
#drupal-support can have some very helpful people on it. But once your question gets beyond general use of the major modules, the odds of getting useful help approach zero.
Asking in a module's issue queue can be hit or miss. If it's a major project, you'll get a response and it'll be "this has been asked before, here's the link." That's great.
More likely you'll never hear a response.
#drupal-support can have some very helpful people on it. But once your question gets beyond general use of the major modules, the odds of getting useful help approach zero.
Dries Buytaert wrote the first version of Drupal circa 2000, with the almost brand new language PHP whose first real version as we know it (PHP 3.0) was released in 1998. In 2003, Brendan Eich (JavaScript) author helped spin out the Mozilla Foundation.
Take your hat and salute these pioneer programmers, who actually enabled millions of websites to be established at Z E R O cost! Their code has become legacy in the correct meaning of the world and as any legacy_code has limitations and problems.
If the author was around at the time, he could by now be able to modify Drupal within minutes than days and would have used the sexiest language of the day PHP!
A challenge for the article author, release your two day RoR CMS as an open source project and if it can offer 50% of the functionality of Drupal and its various popular modules I will donate $ 2000 to the non-profit you establish to promote it!
Take your hat and salute these pioneer programmers, who actually enabled millions of websites to be established at Z E R O cost! Their code has become legacy in the correct meaning of the world and as any legacy_code has limitations and problems.
If the author was around at the time, he could by now be able to modify Drupal within minutes than days and would have used the sexiest language of the day PHP!
A challenge for the article author, release your two day RoR CMS as an open source project and if it can offer 50% of the functionality of Drupal and its various popular modules I will donate $ 2000 to the non-profit you establish to promote it!
This is an awesome challenge and I would love to see a list of what you would consider basic OOB functionality as provided by Drupal. If the CMS he builds in RoR in 2 days has checks for half the items on the list, his non-profit gets the $2K.
This also reminds me of the SXSW shootout this year, where none of the already built CMS's could meet the site requirements in less than 2 days, and Joomla was the only team that did it in less than 3. And that was just to construct a site with a pre-existing CMS, not build the entire CMS.
This also reminds me of the SXSW shootout this year, where none of the already built CMS's could meet the site requirements in less than 2 days, and Joomla was the only team that did it in less than 3. And that was just to construct a site with a pre-existing CMS, not build the entire CMS.
I took an in-depth look at what Drupal provides out of the box recently. (A lot of my clients use Drupal.) Here's my writeup:
http://returncontrol.com/what-does-drupal-provide-out-of-the...
Thanks polynomial. I threw the challenge as an answer to the 'SUCKS', I found it arrogant and disrespectful and I hate arrogance. If the author takes the challenge I will provide a list of basic OOB functionality and deposit the money with whoever they consider neutral enough and will agree the adjudication.
As I mentioned as a reply to the post below, I am neither a PHP or a DRUPAL evangelist, they are tools that I have used in the past and still using, although currently most of my own work is based on frameworks and they got their limits and issues.
What the heck for $ 2000 to get a :
As I mentioned as a reply to the post below, I am neither a PHP or a DRUPAL evangelist, they are tools that I have used in the past and still using, although currently most of my own work is based on frameworks and they got their limits and issues.
What the heck for $ 2000 to get a :
RoR_CMS_FRAMEWORK = 0.5 Drupal
Hey Yannis,
Awesome idea.
I've had a look at the basics in drupal, here is a minimum I think to be able to be functional and get to the 50% mark:
A framework-and-module loader.
Template hooks.
Url parser and dispatcher.
Database abstraction layer allowing for at least postgres and mysql.
The following modules:
aggregator
block
blog
blogapi
book
cck
comment
i18n
locale
menu
node
path
path_redirect
profile
taxonomy
upload
user
If, after 1.5 days there is still time left over maybe some documentation ?
Please understand, I'm no great fan of drupal, having seen altogether too much of it, but to say out loud that you can duplicate this in a couple of days is really ballsy, and I for one would very much like to see this succeed or be put to rest. (I really doubt it can be done, even in a multiple of that time, but hey, maybe miracles do happen and maybe a true guru is able to do such a thing on such a timescale).
Edit: I dropped search, calendar and contact, search can be done outside of the 'core', calendar is optional and contact can be done with a simple 'node'.
Awesome idea.
I've had a look at the basics in drupal, here is a minimum I think to be able to be functional and get to the 50% mark:
A framework-and-module loader.
Template hooks.
Url parser and dispatcher.
Database abstraction layer allowing for at least postgres and mysql.
The following modules:
aggregator
block
blog
blogapi
book
cck
comment
i18n
locale
menu
node
path
path_redirect
profile
taxonomy
upload
user
If, after 1.5 days there is still time left over maybe some documentation ?
Please understand, I'm no great fan of drupal, having seen altogether too much of it, but to say out loud that you can duplicate this in a couple of days is really ballsy, and I for one would very much like to see this succeed or be put to rest. (I really doubt it can be done, even in a multiple of that time, but hey, maybe miracles do happen and maybe a true guru is able to do such a thing on such a timescale).
Edit: I dropped search, calendar and contact, search can be done outside of the 'core', calendar is optional and contact can be done with a simple 'node'.
Thanks jacquesm, I would be happy with that :)
PHP wasn't "almost brand new" in 2000. It's practically as old as Apache. And not in the way that Ruby existed for a long time before anyone noticed it; PHP has been popular for almost that long, too. I remember having to support it in the 90's.
The development team officially released PHP/FI 2 in November 1997 after months of beta testing. Afterwards, public testing of PHP 3 began, and the official launch came in June 1998. Suraski and Gutmans then started a new rewrite of PHP's core, producing the Zend Engine in 1999. They also founded Zend Technologies in Ramat Gan, Israel. (http://en.wikipedia.org/wiki/PHP).
"Mozilla" is sometimes used to refer to the free and open source software project that was founded in order to create the next-generation Internet suite for Netscape. The Mozilla Organization was founded in 1998 to create the new suite. http://en.wikipedia.org/wiki/Mozilla Apache is a bit older about 1996.
My contention and my challenge is in respect to the "SUCKS". I found it totally disrespectful and arrogant. These programmers were hackers and they still are. They were pioneers they were 'real engineers' that used the available tools to the maximum, pretty much like what people are doing together with whatever product is at the forefront.
I am not an evangelist for either PHP or DRUPAL, I have used both many times over with success, even if the process was painful. For web applications the way most HN users would understand them, they are not the greatest of tools especially DRUPAL, however if one is proficient in PHP they can use one of the frameworks (CAKEPHP, CodeIgniter, Kohana) to pretty do any development within a reasonable time period.
"Mozilla" is sometimes used to refer to the free and open source software project that was founded in order to create the next-generation Internet suite for Netscape. The Mozilla Organization was founded in 1998 to create the new suite. http://en.wikipedia.org/wiki/Mozilla Apache is a bit older about 1996.
My contention and my challenge is in respect to the "SUCKS". I found it totally disrespectful and arrogant. These programmers were hackers and they still are. They were pioneers they were 'real engineers' that used the available tools to the maximum, pretty much like what people are doing together with whatever product is at the forefront.
I am not an evangelist for either PHP or DRUPAL, I have used both many times over with success, even if the process was painful. For web applications the way most HN users would understand them, they are not the greatest of tools especially DRUPAL, however if one is proficient in PHP they can use one of the frameworks (CAKEPHP, CodeIgniter, Kohana) to pretty do any development within a reasonable time period.
[deleted]
I spent some time with Drupal a while back and stubbed my toe on each of these points. My favourite pet peeve was the fact that Drupal was repeatedly upgraded in a manner that broke existing sites, and required users to do hairy manual SQL and theme changes. If you're marketing a CMS to a not-so-sophisticated audience (which is basically who CMSes are aimed at), then an essential part of the upgrade process is the creation of tools to perform the upgrade without having the entire site in pieces on the garage floor.
Out of curiosity, how long ago was "a while back"? I've been building on Drupal since version 4.7 (now on 6.14) and haven't ever had a problem with sites breaking on upgrades within major versions.
It's only when upgrading from v4 to v5 to v6 that I've had to adjust my custom templates and modules to work with new APIs. But that's why major upgrades get new major version numbers and are years in the making (and testing).
It's only when upgrading from v4 to v5 to v6 that I've had to adjust my custom templates and modules to work with new APIs. But that's why major upgrades get new major version numbers and are years in the making (and testing).
>A CMS requiring a slew of third-party mods before it can be usable is useless to someone who can code a custom Rails CMS in a day or two.
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.
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.
> When's the last time an update-to-date Drupal site was hacked?
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.
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.
If you set your Drupal installation up to faciliate it (using symlinks) minor updates take ~5 minutes.
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.
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 you set your Drupal installation up to faciliate it (using symlinks) minor updates take ~5 minutes.
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.
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.
I've built a dozen sites and Drupal and I'm also a Rails contributor. I agree with the sentiment of the post insomuch as I never want to work with Drupal again, but that's a matter of personal taste.
The fact is that Drupal is a viable solution for a huge swath of problems that Rails would cost orders of magnitude more to solve. Namely, boilerplate functionality. Drupal gets extra points because of all CMSes it provides the most hooks and thought towards extendability by developers... nothing else even comes close.
That said, Drupal is not a good design for anything specific. It imposes a lot of overhead in an attempt to be all things to all people. The architecture is actually pretty amazing for what it does, but in my opinion it's the wrong level of abstraction to really be useful to be people who are obsessive about usability, design, performance, or maintainability. That probably describes most people on HN in some regard, but it's far from the majority of people who "want a website".
In the wider business community there are far more people out in the world who have $5000, think its a lot of money, and want a full-featured blog + forum + e-commerce + brochureware site that they can update themselves. Enter Drupal.
The fact is that Drupal is a viable solution for a huge swath of problems that Rails would cost orders of magnitude more to solve. Namely, boilerplate functionality. Drupal gets extra points because of all CMSes it provides the most hooks and thought towards extendability by developers... nothing else even comes close.
That said, Drupal is not a good design for anything specific. It imposes a lot of overhead in an attempt to be all things to all people. The architecture is actually pretty amazing for what it does, but in my opinion it's the wrong level of abstraction to really be useful to be people who are obsessive about usability, design, performance, or maintainability. That probably describes most people on HN in some regard, but it's far from the majority of people who "want a website".
In the wider business community there are far more people out in the world who have $5000, think its a lot of money, and want a full-featured blog + forum + e-commerce + brochureware site that they can update themselves. Enter Drupal.
Couple of other problems with Drupal that haven't been mentioned:
* massive numbers of database queries to build a page (i think 30+ for a relatively boring stock homepage). (Yes, there are cacheing modules - but they only work for anon users. If you are logged in as an admin it feels sluggish.)
* You need to put PHP code in the DB (!) for example, if you only want a search box on some pages. (This is wrong for many reasons, but my fave is that if you make a syntax error, or your whole site will break!)
* massive numbers of database queries to build a page (i think 30+ for a relatively boring stock homepage). (Yes, there are cacheing modules - but they only work for anon users. If you are logged in as an admin it feels sluggish.)
* You need to put PHP code in the DB (!) for example, if you only want a search box on some pages. (This is wrong for many reasons, but my fave is that if you make a syntax error, or your whole site will break!)
Actually, you can exclude blocks, like the search box, by URL pretty easily in the Drupal admin panel. Wildcards are excepted too. No need to use PHP unless you have some very complicated rules on when to show certain blocks to certain users.
And even then, if you make a syntax error in any code in any CMS -- whether it's stored in the DB or not -- your site's gonna break in some way.
And even then, if you make a syntax error in any code in any CMS -- whether it's stored in the DB or not -- your site's gonna break in some way.
I think drupal is cleverly and elegantly designed, given two assumptions:
1. We can only use the LAMP stack. (perhaps with other operating sytems instead of GNU/Linux, but you get the idea).
2. We can't use php's object and class system, we have to create our own using arrays.
Given those, you'd be hard pressed to build a better CMS.
The problem is that I don't see any reason to start with those two assumptions, particularly given advances in web development in the past 5 years.
1. We can only use the LAMP stack. (perhaps with other operating sytems instead of GNU/Linux, but you get the idea).
2. We can't use php's object and class system, we have to create our own using arrays.
Given those, you'd be hard pressed to build a better CMS.
The problem is that I don't see any reason to start with those two assumptions, particularly given advances in web development in the past 5 years.
>1. We can only use the LAMP stack. (perhaps with other operating sytems instead of GNU/Linux, but you get the idea).
You can use nginx (and lighty as well, I believe). You can use Postgres (and Drupal 7's ORM abstracts the data model, opening up the possibility of nosql). The only thing you're really stuck with is PHP.
You can use nginx (and lighty as well, I believe). You can use Postgres (and Drupal 7's ORM abstracts the data model, opening up the possibility of nosql). The only thing you're really stuck with is PHP.
> The only thing you're really stuck with is PHP.
Yeah, we really need to work on that. ;-)
Yeah, we really need to work on that. ;-)
In fact, my Drupal clients are so confused by the
interface that they still send me content and ask me
to input it for them.
So what you're saying is that eventually that clients will get so fed-up with using the CMS that they'll start paying you to make the updates? IMO this is a very bad plan that can easily backfire. You might soon find those clients time-and-materials all their work to a company other than yours.
The whole points of a CMS (for my clients) is to make it easy for them to make changes to their site without involving me. If the CMS is broken (and I've never used Drupal so I have no opinion of it), then it's time to use a different one.
The whole points of a CMS (for my clients) is to make it easy for them to make changes to their site without involving me. If the CMS is broken (and I've never used Drupal so I have no opinion of it), then it's time to use a different one.
When I used to work in the field of small software consulting, I saw a pattern repeat a few times. During the tender phase customers would place a high value on having a CMS. Repeatedly situations developed where - once they'd been live for a year and their orgtree had changed - they found the prospect of maintaining their website themselves to be cumbersome, and found it easier to send changes to us.
Only one customer was different, and they were the exact opposite. It didn't want to pay for a CMS (this is ten years ago when there weren't dozens of generic free software CMS), had little clue about how their website fitted together, wouldn't participate in designs, yet insisted on having complete control over their site. Perhaps a throw-together offering on something like drupal would have been good for them.
Only one customer was different, and they were the exact opposite. It didn't want to pay for a CMS (this is ten years ago when there weren't dozens of generic free software CMS), had little clue about how their website fitted together, wouldn't participate in designs, yet insisted on having complete control over their site. Perhaps a throw-together offering on something like drupal would have been good for them.
I've also found that those clients who want total control, often don't want to learn anything.
The time-and-materials approach makes so much more sense: Steady work for web dev firms, the work can be done by junior workers, the client gets a professional site and can focus on their business instead of messing around with HTML.
The time-and-materials approach makes so much more sense: Steady work for web dev firms, the work can be done by junior workers, the client gets a professional site and can focus on their business instead of messing around with HTML.
These discussions around CMSs are totally alien for me. I have been using Plone for all sorts of sites and, while there is no learning curve at all (it's a completely vertical climb) it does a lot out of the box. I almost never considered using anything else.
And, as my wife discovered the hard way a couple weeks ago, and unlike SharePoint (a monstrosity that is often sold as a CMS), it has a very comprehensive undo facility (one I have used countless times).
And, as my wife discovered the hard way a couple weeks ago, and unlike SharePoint (a monstrosity that is often sold as a CMS), it has a very comprehensive undo facility (one I have used countless times).
I in general like drupal decently but highly agree with the learning curve complaint. My biggest complaint which was left out of the article is the abysmal documentation. I'm sure I could find every thing I needed to know in the site, but the search functionality SUCKS and is incredibly frustrating. This contributes to the steep learning curve and was almost enough to get me to give up on Drupal.
Try searching on google for site:drupal.org your problem here
For sites less than, say, 30 pages - I recommend Wordpress over Drupal. It's easier to use, configure, and works just fine for a small business site. Even with multiple levels of navigation, WP gets the job done.
Why less than 30 "pages"?
I know sites that literally run 100s (if not 1000s) of pages with tens of millions of page views worth of traffic per month with no issues.
IMO wordpress triumphs Drupal is both User-friendliness and performance. The only way drupal might be better than wordpress is on security - and that too not by much.
With wordpress it took me couple of hours to understand 90% of the system, when I gave drupal a shot earlier this year I was still scratching my head after 5 days trying to figure out my way, and I thought I was a fast learner.
Drupal may not "suck" but it got some serious usability problem for as long as I can remember.
I know sites that literally run 100s (if not 1000s) of pages with tens of millions of page views worth of traffic per month with no issues.
IMO wordpress triumphs Drupal is both User-friendliness and performance. The only way drupal might be better than wordpress is on security - and that too not by much.
With wordpress it took me couple of hours to understand 90% of the system, when I gave drupal a shot earlier this year I was still scratching my head after 5 days trying to figure out my way, and I thought I was a fast learner.
Drupal may not "suck" but it got some serious usability problem for as long as I can remember.
Just my opinion - obviously, you can create a million blog posts without issue. But nesting and ordering more than 20-30 pages gets hairy - especially when you start getting paginated results.
Not sure what you are referring to. Why would pagination more than 20-30 pages gets hairy? There is absolutely no reason for that to happen. Can you give an example?
The Drupal people are working hard on Usability. Unfortunately, they put all this effort into future releases rather than releases that people are actually using on production sites.
I am not trying to be sarcastic and it might come out as such. But I have been hearing about them trying to improve usability for couple of years now even before I tried it this year.
Drupal sucks in the same way that Democracy is the worst form of government.
It sucks in the way "US democracy" sucks. The idea is good, but there're a lot of flaws in the system that could be fixed if the system wasn't so dead-set on maintaining status quo.
Have you talked to any of the developers about those issues? I've found every Drupal developer I've dealt with to be extremely friendly and open to improvements. Tickets actually get responses and fixes, and they can be bribed with money and patches to make things better.
Sure, it has many flaws (even deep architectural ones), and there are many things to complain about but compared to the other leading CMS', it's a dream to work with.
Sure, it has many flaws (even deep architectural ones), and there are many things to complain about but compared to the other leading CMS', it's a dream to work with.
For me the point where drupal starts to suck is when the core + modules won't do the job. As soon as you start getting into CCK, Views, etc. you're skating on the edge of real development, without any of the tools that make that productive. Writing PHP code in a textarea is not my idea of a good time. And if you have more than one "developer" working on it, fugehtaboutit. With so much stored in the database, synchronizing changes among various developers is nigh on impossible.
Is Joomla a viable alternative here?
Depending on your needs it may be. The NanoHub project has made good use of Joomla for scientific community websites with extensive integration of resources: http://nanohub.org/about/hubzero http://hubzero.org/
[deleted]
No.
Why not? I'm not intending to be malicious or smart-alecky here.
I've been called for two different cases of compromised Joomla installations. In one case, the 1.0 to 1.5 upgrade process was completely broken; I couldn't get it to work without hacking up the upgrade script.
I didn't play around with it long enough to remember anything about its file or database architecture. But, I think if I were going to develop a CMS, I would want to make it easy to patch and upgrade, and I would want to make sure that it was somewhat secure.
I didn't play around with it long enough to remember anything about its file or database architecture. But, I think if I were going to develop a CMS, I would want to make it easy to patch and upgrade, and I would want to make sure that it was somewhat secure.
Joomla isn't nearly as extensible as Drupal. If you're just trying to put up a few pages and call it a day, it's great, but Drupal can handle practically everything. I use it to mock up web sites because I can't program: It's possible to use Drupal to create a functioning beta of a fairly complex site without writing a line of code. It's slow and results in lots of bugs, but it works.
For building sites or for building apps? While Drupal can be used to build a great web site for a company (and often is!) Joomla's extensibility seems aimed more at rapid application development using a strong mvc framework.
If you don't mind relying on 3rd party contrib modules and external development roadmaps, you can build apps in Drupal, but if you just want a framework to build and deploy your own web apps Joomla is fully extensible in the OOP sense.
Also Joomla is classier than Drupal. :-P
If you don't mind relying on 3rd party contrib modules and external development roadmaps, you can build apps in Drupal, but if you just want a framework to build and deploy your own web apps Joomla is fully extensible in the OOP sense.
Also Joomla is classier than Drupal. :-P
That is a question better asked elsewhere, not HN. CMSses in general, and PHP ones in particular, are mundane topics that shouldn't be brought up in HN unless they advance the state of the 'art' of content management in some manner.
I've got extensive experience with both Joomla and Wordpress and there are things I don't like about either of these - still haven't found anything better in recent years.
Anybody know of some easy to use alternatives that have - so far - managed to stay under the radar?
Anybody know of some easy to use alternatives that have - so far - managed to stay under the radar?
The author of that post, Mariya Lysenkova, runs Verdage, a consultancy whose offerings include the CMS system Webist. Of course she's going to say Drupal CMS sucks. It's free and Open Source! Open Source developers are a threat to her business.
The problem isn't with drupal, its with the concept of content management systems as a whole. Generally they just don't work for the needs of more than individuals. Once a site gets either minimally serious traffic (more than 5,000 UVs a day) OR more than person behind it, then any CMS involved will start to suck more and more as the UVs or people increase.
I don't know why Plone doesn't get more love. Very nice UI, very responsive developer community, active community of 3rd party developers and add-ons...
I've had some experience using drupal and while it can be frustrating at times, my overall experience with it is pretty positivie. I've used it mainly to build websites for clients, these are the usual bread-and-butter variety sites for small businesses. So let me address some of his points.
>>> Drupal is Freaking Hard to Use and Has a High Learning Curve <<<
The author uses the "layperson" as the targeted audience yet the only alternative he offers is rails. Yeah, enter rails, a layperson would have to learn programming, database, deployment just to get a rails site up. Comparing this with the WYSIWYG interface of drupal, I'd say the latter is much much easier for the lay person.
in my experience of working with clients clients, most of them haven't found much trouble making minor edits to the site itself after I've set it up given them some instructions. For me this is godsend compared to 1, doing things the old way of giving them static pages and having them email me every single time they need a change or 2, using my custom cms-like solution which is buggy and hacked together.
For these simple CRUD type operations, drupal is simply the easiest way for the lay person to modify a pre-built website.
>>>>Drupal’s Design is Piss-Poor<<<<
Inheritance? Objects? Keep in mind that drupal was started back then in 2001 when PHP didn't have any real OOP capabilities and that heritage carried through. As for the issues with upgrades, most modules and templates..etc shows prominently what version they are compatible with and if you use the correct versions, it usually doesn't break.
>>>>consider hiring a Ruby on Rails developer<<<
There are so many useful things that are built out of the box for you in drupal, the taxonomy system, thousands of modules for all of the most common operations and a generally helpful and supportive community. Through modules, you can get internationalization for free, you get a free forum, a free user-groups, blogs..etc. You also get a pretty good degree of customization with the Views and CCK module for the edge cases. I really don't see how building it yourself from ground up can be a money saver for 95% of the common cases.
And why specifically rails? compared to other web frameworks like Django, does rails offer something that makes it especially scalable, easy to learn or especially suited to the CMS type application?
From what I know, the Django admin site, its apps system, better documentation and python's consistent syntax makes it easier to learn and more suited for CMS type applications. And if you use Pinax for the some of its out-of-box functionality, it makes life even easier.
>>> Drupal is Freaking Hard to Use and Has a High Learning Curve <<<
The author uses the "layperson" as the targeted audience yet the only alternative he offers is rails. Yeah, enter rails, a layperson would have to learn programming, database, deployment just to get a rails site up. Comparing this with the WYSIWYG interface of drupal, I'd say the latter is much much easier for the lay person.
in my experience of working with clients clients, most of them haven't found much trouble making minor edits to the site itself after I've set it up given them some instructions. For me this is godsend compared to 1, doing things the old way of giving them static pages and having them email me every single time they need a change or 2, using my custom cms-like solution which is buggy and hacked together.
For these simple CRUD type operations, drupal is simply the easiest way for the lay person to modify a pre-built website.
>>>>Drupal’s Design is Piss-Poor<<<<
Inheritance? Objects? Keep in mind that drupal was started back then in 2001 when PHP didn't have any real OOP capabilities and that heritage carried through. As for the issues with upgrades, most modules and templates..etc shows prominently what version they are compatible with and if you use the correct versions, it usually doesn't break.
>>>>consider hiring a Ruby on Rails developer<<<
There are so many useful things that are built out of the box for you in drupal, the taxonomy system, thousands of modules for all of the most common operations and a generally helpful and supportive community. Through modules, you can get internationalization for free, you get a free forum, a free user-groups, blogs..etc. You also get a pretty good degree of customization with the Views and CCK module for the edge cases. I really don't see how building it yourself from ground up can be a money saver for 95% of the common cases.
And why specifically rails? compared to other web frameworks like Django, does rails offer something that makes it especially scalable, easy to learn or especially suited to the CMS type application?
From what I know, the Django admin site, its apps system, better documentation and python's consistent syntax makes it easier to learn and more suited for CMS type applications. And if you use Pinax for the some of its out-of-box functionality, it makes life even easier.
Isn't some portion of the official PostgreSQL website powered by Drupal?
Drupal sucks, America sucks, C++ sucks, life sucks. Basically anything big, complicated and interesting sucks because it's so damn hard. Why is there such a steep learning curve for my life? I've been around for decades and I STILL haven't figured it out?? What's up with that? What's hilarious is the author complains about the extensive history of Drupal vulnerabilities and then advises the reader to go out and write their own. Dude! The history of vulnerabilities is only because a whole pile of people are scanning the Drupal code day in and day out LOOKING for this shit, bringing it into daylight and FIXING it. That's a GOOD THING. That's how open source is supposed to work. You think you'll get better security by writing your own CMS from scratch with noone looking over your shoulder? In your dreams, my friend. In your dreams.
Seriously, this is #1 story in HN? Hint, hint: you will not build a production quality CMS in a day or two, nor a month or two. Not with Rails, not with pixie dust. And if you will take the time to build something comparable to Drupal, it will inevitably have its own design flaws and learning curve and people will blog on how you suck.
Instead of "X sucks" posts, how about writing about viable alternatives to X? A post about a quality replacement for Drupal would be much more interesting.