Recent Posts15501
General Software Discussion / Re: Drupal is f*cked
« Last post by mouser on September 23, 2010, 11:30 PM »Now that is the great question.. and it's why even after being so angry and frustrated with drupal after i used it for my first project, i found myself using it again..
From a programmer's perspective, and under the hood -- Drupal is a remarkable achievement. I'm just having a very hard time thinking of many use-cases where it is a good choice.
I can't really answer that in a way that would meaningfully help someone who is considering using a CMS (content management system) for their site. because i'm not really an end user utilizing it as a CMS -- I'm using it as the foundation of a larger web service, that shares some overlap in functionality with a CMS.
Having said that, if you are really looking mainly for a CMS, i can't imagine any justification for going through the hall of configuring drupal; as impressive an achievement as it is -- it's just awful to configure -- orders of magnitude worse than anything else. powerful yes, but a recipe for pain and disaster.
The one viable use case for Drupal is if you are a serious coder (or plan to hire one), and basically want a full CMS *and* want to add serious custom functionality on top of that CMS. That is, if you are going to have users, forums, blogs, stories, etc. and then will add your own new kinds of complex content types -- that is the *one* use case where Drupal starts to make sense; that's because it allows you to code independent addon modules that can do a lot of things and don't require you to modify the core Drupal code, making maintenance easier.
That's basically how i used it when i created tfdocs.com; the idea was to preserve a full cms system where users could create forms and tag them and catalog them, and do all kinds of normal CMS stuff, but also work with this new content type. From a coding standpoint that project was more suitable to Drupal than my latest one (UQ), which is much less of a traditional CMS, and is proving to be much more painful and difficult to add the kinds of things I need to add.
One might say that I'm expecting too much from Drupal -- expecting it to be something it's not; in some sense that's a fair point -- but on the other hand, the things that i still get insanely frustrated about are some of the most obscenely straightforward things (creating sidebar links) etc.; nothing is simple in Drupal, and often the more simple it should be, the more impossibly convoluted it is to perform (and once you do figure it out you'll never remember how you did it in the future since it involved the coordination of settings in 10 different places, etc.).
You asked what I would choose as an alternative.. In the past I have piggybacked on a framework (CodeIgniter) as the starting point for a large web service -- and in many ways i regret that i didn't polish up all of the user management code i added to that, because that would have been a far saner and more straightforward starting point for building a system.
The dilemma I faced this time, and face over and over -- is figuring out when it would be better to leverage existing flawed and over-complicated code -- vs. writing new code from scratch. Drupal has a system for managing groups (allowing people to invite others to groups, manage them, etc.), and an elaborate system for tagging, etc. -- these are all things that one would have to code into a lightweight framework like CodeIgniter if you didn't build on top of something like Drupal.
Ideally though, i think that the better approach might be to spend some time building just such a foundational framework -- sort of midway between Drupal and something like CodeIgniter (or CakePhp or Ruby on Rails, etc.).. something much more focused on serving programmer's needs as opposed to the frankenstein approach of Drupal.
From a programmer's perspective, and under the hood -- Drupal is a remarkable achievement. I'm just having a very hard time thinking of many use-cases where it is a good choice.
I can't really answer that in a way that would meaningfully help someone who is considering using a CMS (content management system) for their site. because i'm not really an end user utilizing it as a CMS -- I'm using it as the foundation of a larger web service, that shares some overlap in functionality with a CMS.
Having said that, if you are really looking mainly for a CMS, i can't imagine any justification for going through the hall of configuring drupal; as impressive an achievement as it is -- it's just awful to configure -- orders of magnitude worse than anything else. powerful yes, but a recipe for pain and disaster.
The one viable use case for Drupal is if you are a serious coder (or plan to hire one), and basically want a full CMS *and* want to add serious custom functionality on top of that CMS. That is, if you are going to have users, forums, blogs, stories, etc. and then will add your own new kinds of complex content types -- that is the *one* use case where Drupal starts to make sense; that's because it allows you to code independent addon modules that can do a lot of things and don't require you to modify the core Drupal code, making maintenance easier.
That's basically how i used it when i created tfdocs.com; the idea was to preserve a full cms system where users could create forms and tag them and catalog them, and do all kinds of normal CMS stuff, but also work with this new content type. From a coding standpoint that project was more suitable to Drupal than my latest one (UQ), which is much less of a traditional CMS, and is proving to be much more painful and difficult to add the kinds of things I need to add.
One might say that I'm expecting too much from Drupal -- expecting it to be something it's not; in some sense that's a fair point -- but on the other hand, the things that i still get insanely frustrated about are some of the most obscenely straightforward things (creating sidebar links) etc.; nothing is simple in Drupal, and often the more simple it should be, the more impossibly convoluted it is to perform (and once you do figure it out you'll never remember how you did it in the future since it involved the coordination of settings in 10 different places, etc.).
You asked what I would choose as an alternative.. In the past I have piggybacked on a framework (CodeIgniter) as the starting point for a large web service -- and in many ways i regret that i didn't polish up all of the user management code i added to that, because that would have been a far saner and more straightforward starting point for building a system.
The dilemma I faced this time, and face over and over -- is figuring out when it would be better to leverage existing flawed and over-complicated code -- vs. writing new code from scratch. Drupal has a system for managing groups (allowing people to invite others to groups, manage them, etc.), and an elaborate system for tagging, etc. -- these are all things that one would have to code into a lightweight framework like CodeIgniter if you didn't build on top of something like Drupal.
Ideally though, i think that the better approach might be to spend some time building just such a foundational framework -- sort of midway between Drupal and something like CodeIgniter (or CakePhp or Ruby on Rails, etc.).. something much more focused on serving programmer's needs as opposed to the frankenstein approach of Drupal.
