Edit: First followup posted.
Are you choosing a Content Management System for your next site? Allow me to throw in my two cents against Drupal. In theory, Drupal is a CMS that lets you control your site out of the box. In practice, it’s a nightmare to configure and maintain.
I recognize that Drupal might work for small sites: install the software, upload your custom theme, and start adding content. But if you’re planning a serious site, with custom features and potential for high traffic, Droople, as I’ve christened it, might not be your best bet.
Apologists may protest that module X or hack Y might fix my gripes with Drupal. I think this is irrelevant. 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. (Hint, hint. Build it in Rails.)
Without further ado, here is a breakdown of why Drupal is bad for the various parties involved, together with Why It’s Bad (WIB) notes for the less tech-savvy.
Gripe #1: Drupal Stores Just About Everything in the Database
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.
WIB: Best practices dictate using a version control tool like Subversion or Git which, among other things, lets two developers “download” the same code so they can work on it simultaneously. Unfortunately for Drupal developers, database settings are not typically stored in version control. This means that two developers have no easy way of coordinating their work. Further, it means you’ll have a heck of a time replicating your settings across multiple servers if you have a high-traffic site that requires load balancing, or a staging server where you want to preview changes before they go live.
Another thing Drupal stores in the database? Logs. In the database. Drupal stores logs in the database.
WIB: Logs record visits to your website, together with other useful details like errors. When you get lots of traffic, logs tend to get huge – we’re talking gigs. Logs are important for debugging, but, unless you’re a high-security outfit, they do not need to be permanently stored. If you back up your database regularly – and you should – you’ll be transferring all that unnecessary data every time you run a backup. Further, you might want to grant a sysadmin or programmer access to your logs to help diagnose a problem. You don’t want that person digging around in your database for this information: one bad search query and your data is gone.
Gripe #2: Drupal is Freaking Hard to Use and Has a High Learning Curve
In the good old days, building a website meant coding a page in HTML and uploading it to a server. If you wanted to update the page, you edited the HTML, and re-uploaded the file. Then people who didn’t know HTML started clamoring for a way to edit their own sites. Along came Content Management Systems, presumably to let an admin log in, edit, save, and call it a day.
Enter Drupal. This CMS, my friends, is so bloated that it takes days, if not weeks, for the layperson to learn their way around it. 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.
WIB: The whole point of a CMS is enabling a layperson to update a website. I think the average person can learn basic HTML and FTP within weeks. So if a CMS takes weeks to learn, and you still need a techie to help you find your way around it, the CMS is not doing its job of simplifying the website update process.
Why is Drupal so hard to use? It’s a combination of bad usability and confusing navigation. An example of Drupal’s bad usability is requiring a user to confirm changes twice before they’re saved—often with the Save button located below the jump, i.e. out of view. As for confusing navigation: creating a blog post is under “Create Content” but editing a blog post is under “Manage Content” and sidebar content is under “Site Building / Blocks”. What?
Gripe #3: Drupal’s Design is Piss-Poor
Drupal has a history of security vulnerabilities and is written in ugly spaghetti code (guys, have you heard of classes? Objects? Inheritance? Oh, nevermind).
It also has poor maintainability. In other words, upgrading to a newer Drupal version breaks templates and other code you may have written for an older version. Fixing this, of course, costs time and money. Other frameworks also deprecate older APIs, but in my experience, the changes between versions of other frameworks are not so drastic, and there is often a helpful process built in to migrate your code.
Gripe #4: Drupal’s None Too Friendly
There’s been quite a backlash over Drupal’s new trademark policy, which is rather contrary to the spirit of open-source software. Why protect your trademark so fiercely, Drupal? Your product is open, and great, so why the need to protect it against sites like DrupalSucks.com? Oh, right…
Conclusion: Drupal Sucks
If you are on a low budget and do not plan on hiring a developer, give Drupal a whirl (I guess). However, if you find yourself needing an oxymoronic “Drupal programmer” to do extensive configuration, consider hiring a Ruby on Rails developer instead. Chances are, you can get a custom CMS at the same price and with half the frustration.
Edit: Oh, and Drupal’s search also sucks. Thanks YCombinator.
Edit #2: I was unclear re. the templates in the database. I wasn’t referring to .tpl files, but to Drupal Views.
Edit #3: Oh, and for the templates you do store in the filesystem, the naming conventions for overriding a particular item are horrendous. For example, block-block-5.tpl.php contains the auto-generated id in the filename. So if the node/block has a different id in a different environment (dev vs. production) you’re out of luck, and the template won’t work.
Edit #4: Thanks for the amazing feedback everyone, both positive and negative. There have definitely been a lot of helpful suggestions. I’ll look into them all and write a followup with the results!
187 Comments
I’ve started with Drupal for a small web site for a local sports organization. Aside from clients not being able to manage content, the biggest problem was it’s way of upgrading. That is download the newset version, put the site in maintenance mode, backup the database, upload SOME files, upgrade. And you need to upgrade all the time to patch the new vulnerabilities discovered. After 4 upgrades, I’ve switched them to WordPress which is MUCH simpler for the clients to maintain and has a nice one-click-upgrade that has always worked without a problem.
On first read, this is quite hilarious.
On second read, you better go through Drupal and through your post when you’re sober.
i’m just happy that you did not see that even php code gets stored in the DB.
what the heck i don’t care! every system sucks balls at some point, from some view, even ruby. it’s just like religions, the best is only your own.
Ah, yes. Forgot about that. Indeed, you can store PHP code in the database.
And Rails does have plenty of its own limitations, of course!
Just to counter a few points, it also logs to a file if you want it to. Out of the box. Just a configuration.
But you’re right. How the hell would you know that, because the white elephant in the room in the Drupal community is usability. It all makes sense to us, because we use it everyday.
To counter the upgrade problems, check out Acquia. They release their own Drupal version which is upgraded through Subversion. just a quick “svn up” and a visit to example.com/update.php and you’re done. That mixed with Drush (a command-line script to install / enable / update / anything else with drupal) you can update a site in under a minute.
Re. the logging: yeah. You can configure it to log to a file on dev, as long as you don’t forget to replicate that configuration manually when you release your site to production! Therein lies the rub…
Thanks for the other tips though. I’ll def. look into it if I have the misfortune of having to use Drupal again.
Hey Mariya, you’re the top post on Hacker News
Things like Drupal are what give php a worse name than it deserves. A “framework” to let people shoot themselves in the foot. A little knowledge is a dangerous thing, right?
I know! Exciting times. By the way, we should meet up for that coffee at some point! Email me.
hey… was hoping you guys could offer some advice. I’m interning @ a startup that’s in development mode, as a biz dev guy I’d really like to have a better understanding of the development process. We ask for things to be done to the UI or the functionality of the site, but have no idea what’s involved in our request. I don’t plan on becoming a devleoper or design person, but still would like a basic understanding, just as some developers have a basic understanding of the sales engagement process. Would you suggest, I get a basic understanding of HTML, then move to a more advanced language ? Or perhaps there is a book you can suggest that outlines the various elements of website design, from UI to Databases to back-end infrastructure…. thanks for any advice you can lend.
Hey John! I think the best advice I can give is for you to try setting up a basic site, on a topic you’re interested in. That will teach you the basics of HTML, CSS, FTP/servers and maybe databases. I’m sure the techs at work (and on the interwebs) will be more than happy to answer your questions as you go along. Kudos on trying to understand “the other side”.
thanks Mariya!
The author dismissed Drupal because it does not handle issues ‘out of the box,’ and then list complaints that apply to “serious sites, with custom features.” The thing is, the serious sites don’t need to handle issues out of the box, they can be customized with modules. By very virtue of being serious they should have administrators available to find or write new modules and to deal with the admittedly annoying yet solvable issues regarding overuse of the database and staging server / deployment issues. For example, the issue of logging in the databases (which is very convenient for low bandwidth sites, by the way) can be fixed for high bandwidth site in minutes with the installation of the logtofile module.
Drupal is all about add on modules by design. If you want a one size fits all blog that takes 5 minutes to set up, get word press. If you want to write custom applications quickly and don’t mind being limited to their conventions and limited code universe, use ruby on rails. But if you want to build a web application that strings together many problems that have already been solved by the multitude of Drupal module writers, with the ability to customize the source or add new modules when needed, Drupal is a great platform.
How does your deployment process look? Have you found an easy way to push *all* changes from e.g. development to production with one command? I’ve yet to be able to do this with Drupal and that is my #1 problem with it.
As a contributor to the core Drupal project and the maintainer of the large number of modules, I’m far from unbiased. And I definitely understand Mariya’s frustration on a couple of these points. However, a couple of the issues mentioned demonstrate a relatively shallow understanding of the system. For example:
“Views are stored in the database.” That’s correct — unless you click the ‘export’ button and put the definition of the View into a PHP .inc file. That mechanism allows newcomers to use a UI-driven builder to construct their data listings, then ‘lock them in’ as source-controlled code once they’re defined. It’s not perfect, but it’s certainly the worst example to pick on if you don’t like things stored in the database.
The search system that Mariya slagged on is also pluggable — for small sites, it works well but can be replaced by a Solr server just by installing the Solr software and dropping in the ApacheSolr module for Drupal. Obviously, the system that makes that stuff easy to rip out and replace transparently implies a degree of abstraction overhead. That’s a compromise that every system makes; for some sites, Drupal’s pros and cons won’t work well. For others, they’ll be a great fit.
And finally, the ‘template naming’ complaint that Mariya mentions, regarding auto-generated IDs, is a bit deceptive. HTML templates in Drupal control the markup for a given type of element — block.tpl.php for sidebar widgets, for example. The output for specific instance of one of those elements can also be overridden by using a template with a more specific name. For example, block-view-recent.tpl.php for a ‘recent items’ block generated by the Views module. One module that ships with Drupal allows users to whip up hand-rolled blocks containing static HTML, to populate sidebars and feature areas quickly. The blocks output by that module use numeric identifiers rather than human-readable ones, and that should certainly be fixed, but the limitation is specific to hand-rolled blocks from that module, not inherent to the templating system.
Drupal’s learning curve is a frequent topic of complaints: especially for those coming from simpler systems like Wordpress, or ‘just-the-foundation’ frameworks like Rails, it can be confusing and full of inexplicable legacy decisions. It would be nice, though, if the criticisms of it could stick to problems that *actually exist* — it’s easier to fix that kind.
^ .inc files? Seriously? This isn’t 2004.
Also, Solr SUCKS. Please, PLEASE use Sphinx if you need a full-text search engine.
>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. (Hint, hint. Build it in Rails.)
Instead of adding a voice to the problem, please spend 2 days custom building a Rails CMS and release it as an open source sane alternative.
Apologists are annoying. People that possess the power to create change, yet do nothing but whinge, deserve a special place in Hell. (Hint, hint. Put up or Shut up.)
I agree with your conclusions, and may I recommend Joomla as an alternative. Unlike Drupal, it actually is easy to use. I’ve used it extensively, both before and after trying out Drupal, and I have to say the difference is like night and day.
“Code it in a couple of days” ahh yes, the mythical man weekend. Good luck with that.
If you don’t like Solr, fine. Someone implemented a drop-in Sphinx replacement for the default indexer, too. That’s my point — those pieces of functionality are swappable, and the default out-of-box implementation is geared towards the lowest common denominator, to avoid alienating the folks who run a small site from shared hosting rather than their Awesome Server Cluster.
Complaining that Drupal’s built-in search indexer sucks is like complaining that django’s built-in http server sucks.
If you really, really want to put your code in a .fluffy-bunnies file, PHP won’t stop you. Come on, seriously. There are legitimate, factual criticisms of Drupal’s architecture that can be made without resorting to this kind of silliness.
Wow, where to start? I guess I’m a drupal apologist… I’ve been using it for 4 years, so I think I qualify. That said, let’s dispell the fud:
1.) “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.”
As you clarified, you actually mean drupal views, which are a FAR cry from “templates”… (For those who are wondering “views” is basically a query builder, so we’re storing the configuration for these queries.) However, it’s worth noting that the suggested use case on “views” is to export them as code into a module of their own for all the reasons you mentioned. The author of the module has done a lot of great work to make that as simple and straight-forward as possible.
2.) “Enter Drupal. This CMS, my friends, is so bloated that it takes days, if not weeks, for the layperson to learn their way around it. 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.”
If that’s the case, then you’ve obviously failed to grok quite a few of the things that Drupal does to make your clients life easier. We train clients on drupal in about 2 hours, and usually have little in the way of re-training afterwards. The $tabs variable in your templates (I mean specifically page.tpl.php and the like) is your friend. Navigate to the page you want to change, hit edit… change as necessary, hit save. Wow that was hard
Admittedly, creating content can be a bit more in depth, especially “pages” that need to be inserted into the menu system. That one use case aside, “goto create content, and add the new type of content you need” is straight forward enough for most customers. If you’ve done your job, it should be as simple as that.
“An example of Drupal’s bad usability is requiring a user to confirm changes twice before they’re saved”
I have no clue what you’re talking about… and I use drupal every day. Comments sort of do this, but you can turn it off… other then that the only things that do this are way high end admin things like “Views” that allows you to configure and test before saving.
“editing a blog post is under “Manage Content” and sidebar content is under “Site Building / Blocks”. What?”
As I mentioned you can just visit the blog you want to edit, and if you’d utilize the zen theme to build your custom templates on top of, you’d find wonderful little “edit block” roll overs on each individual block. (Yes learning curve for sure, but the community is not blind).
3.) “Drupal has a history of security vulnerabilities and is written in ugly spaghetti code”
Spoken like a true closed-source proponent. Entice people with a “custom” system that’s specific to their needs, is only maintainable by the person who wrote it, and OH BTW unless that person decides to give you the code, you’re screwed… I deal with this every day, and it’s a horrible way to take advantage of clients. That said, “history of security vulnerabilities” translates in reality to “Drupal actually reports when there’s a problem, unlike most close source alternatives, so you can trust that they’ll tell you when you need to upgrade, instead of leaving your butt hanging out there w/o telling you there’s a problem.” Bottom line, every software has security issues, the question at hand is how those responsible handle them. Pick your poison, I’d rather know there’s a problem than stick my head in the sand.
4.) “It also has poor maintainability. In other words, upgrading to a newer Drupal version breaks templates and other code you may have written for an older version. Fixing this, of course, costs time and money. Other frameworks also deprecate older APIs, but in my experience, the changes between versions of other frameworks are not so drastic, and there is often a helpful process built in to migrate your code.”
We should be more specific with this… namely upgrading to a new major version release can potentially (actually almost certainly) break existing themes and modules within your system… Which really isn’t that surprising when you consider that that new version has been under development for somewhere between 12-24 months, and is constantly being improved. Minor version releases (6.13 – 6.14) are very simple to upgrade, as are most modules. This is also why the drupal community supports back versions for QUITE a while after new releases.
5.) Trademark stuff… yeah, a little OT for the software topic, but whatever…
6.) “If you are on a low budget and do not plan on hiring a developer, give Drupal a whirl (I guess). However, if you find yourself needing an oxymoronic “Drupal programmer” to do extensive configuration, consider hiring a Ruby on Rails developer instead. Chances are, you can get a custom CMS at the same price and with half the frustration.”
We already know my opinion on close source solutions… needless to say, the words “custom CMS” always make me shudder. You better trust that dev completely… and I mean trust that he knows security, caching, scaling, search engines, etc, and also have a rock solid contract in place that guarantees anything he codes is your property not his… and most devs aren’t into that for very good reasons so… good luck.
7.) “Edit #3: Oh, and for the templates you do store in the filesystem, the naming conventions for overriding a particular item are horrendous. For example, block-block-5.tpl.php contains the auto-generated id in the filename. So if the node/block has a different id in a different environment (dev vs. production) you’re out of luck, and the template won’t work.”
Admittedly, there are a couple WTFs on the naming schemes… blocks especially. But the supposition that a block would have a different numeric convention on dev/production is akin to supposing that your node ids are going to change… this is just fear-mongering for those who don’t actually know the system, and is a real testament to either your ignorance of the system, or your dislike for it… take your pick.
Uh, no. I never said you can build a Drupal equivalent in two days. I said you can build a custom web app in two days.
I can give it a whirl, although I’ve heard the code is even worse.
Thanks!
Dismissing includes as antiquated is laughable at best.
Drupal’s real issues, for me, amount to the comments listed here about migration from development to live. I’ve gone to great lengths to solve many of those issues with elaborate hacks, but it still doesn’t feel worth it. Ultimately, development of modules is handled wonderfully (especially when you can just drush the new stuff in to production) but lacks elegance and isn’t easier than alt-tabbing around to drop in changes via FTP. In fact, it takes more clicks/commands. Muscle memory has it happening very quickly, now-a-days, but I wish it felt more like responsible development and less like I’m digging up my entire garden to plant a new bulb.
AMEN brother! Drupal has been a NIGHTMARE
I think if you have a low-budget Drupal could be suitable for your needs, of course if your needs don’t involve hard customization!
Privet Mariya,
What would be a good and easy out-of-the-box CMS then?
All the best,
Victor
Honestly, I don’t think there is one. For something super-simple: Wordpress. For something pretty simple: Drupal. For anything remotely interesting: start from scratch.
I must admit that I recognised a lot of the problems you descrbed for my work
with drupal, especially those around deployment/staging and DB bloat.
I still think there are lots of great things about the droopy ecosystem, not least
the development communuity around it, but there are some issues you always
run into that stop it being my CMS of choice.
What about Radiant CMS? It’s in Rails, so *you* can easily extend it. However, it also stores views in the database.
I don’t like Radiant either. I don’t think these issues are unique to Drupal.
Well, I’ve been using Drupal for years, and probably will use something else for my next project, but not for any of the reasons sited above.
The fact that caching only works for anonymous users, and that Drupal has a hard time scaling without caching, is what’s likely to drive me away. Correct me if I’m wrong, though.
The other thing is that I’d rather be writing my extensions in Ruby than PHP.
But in Drupal’s defense, it is absolutely trivial to write new modules for. The architecture is great (again, for a PHP-based project), which is saying a lot from someone who tends to be critical of API architecture. In fact, the comment above about Joomla made me laugh. I started out on Joomla, and after working with it for weeks, decided that it was terrible and jumped to Drupal, which is much, much better designed.
My users (when they are site editors) have an “Edit” link on the top of every page, as was mentioned above, so I have to say that the complaints about it being hard for end users means that you configured the site badly. Sorry. Not Drupal’s fault. Other complaints have been addressed as well–I’m sorry that you’ve been having a hard time dealing with it, but it just doesn’t suck.
Not to say that your projects might not have been better done on Rails. Each project certainly has a toolset that matches its needs the best. But I feel that your slamming of Drupal just means that you ended up using it for a task it wasn’t appropriate for–or didn’t understand the best ways to configure it.
Hey, your ideas are pretty common and there’s quite a bit to not like about Drupal. But it seems like you haven’t done much research, so I’ll post some points.
Views in the database: this was true for a while, but now Views are exportable, and it’s extremely easy to do so with Features, a Drupal module which will also export “Pretty much everything” else that Drupal customarily stores in the database, and it is moving to support export of everything. Note that this is different than systems that only store these portions in code, because Drupal provides web interfaces to configure, and then export functionality to play nice with VCSes and provide a speed boost.
Object-orientation: Drupal is moving towards this slowly (with ctools object plugins), but the reasons for the current design are well-explained here, mostly centering around performance and the fact that the system is often object-oriented, but doesn’t use PHP’s constructs.
Talking about Drupal 6 security, you should link to Secunia on Drupal 6, not Drupal 4.x. That probably isn’t deliberate, but it’s misleading. All security advisories have been of moderate influence, and all have been fixed with vendor patches. Reference WordPress 2.x with lots of unpatched vulns, and let’s not forget that custom code often exposes much more of a risk than core code.
>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, you’re writing this in WordPress, a PHP projec that, unlike Drupal, really *does* have security 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.
Oh gosh! I have never read such childish post on a software. Before blogging about anything it is worth spending an hour to check the facts yourself. Had you spent few minutes going through drupal manual(s) you would have realized how stupid is this blog post.
Information given in this blog post is at best “incomplete”.
#FAIL
Well duh, it’s written in PHP.
Your arguments are strong, but VIES is way to query database for speciefic type of content, so you do not need to write custom queries (if you do not know this), but if you think – developing custom CMS is great, and even on RoR – jump through the window. After the end of support, when companies changes supporter or want build new look (template), with Drupal (preety well documented) it is easy, but if you’ll try to figure out “what is this button do” in custom CMS – price ups ups grows grows several times… RoR is cool, – use CakePHP, CodeIgniter – never find problems with platform. And if you want realy great CMS/CMF – Drupal 4u!
Thanks for the amazing feedback everyone, both positive and negative. There have definitely been a lot of helpful suggestions. I’ll look into them all and write a followup with the results!
If you are a person that loves to write beautiful code and wants to create an efficent information system based on a “framework” you may be happy with Django.
No idea why there’re so many postings about Ruby on Rails. If you have seen Django once you may will never return to Ruby on Rails.
If you are using something like a blog (WordPress) as a CMS that’s ok, but it will result in limitations -> Hacking. Indeed there’re some good plugins available for WP. Best thing with WordPress is the great documentation.
Other options ( Open Source PHP CMS) may be: CMS made simple, Typo Light, Concrete 5, Jaws etc. Just have a look at the demo pages.
I’ve actually wanted to learn Django for ages. Should look into it soon. I used RoR as an example framework, not necessarily as the best one.
as a person who started programming, drupal taught me much of a certain way to do things, it was great when looking at its source code then compared to not being able to learn from it…
I never was able to install everything correctly, and always ended up hacking the menu structure to accept my variables.
Having used Drupal for about 1.5 years now, I fully agree, although for slightly different reasons. Drupal sucks in a number of ways.
Problem is, there is no open-source CMS that doesn’t suck. I tried silverstripe and it also sucks, albeit differently.
Drupal far from sucks. I used Joomla for over a year and wish I would have started with it in stead of Joomla.
The way you wrote the post seems like you literally installed it, gave it 10 hours and said screw it. Yes, there is a learning curve but well worth it!
Drupal is so amazing once you get the hang of it. It is NOT even close to bloated, I have no clue what you are talking about.
Anybody had experience with dotCMS or something like that?
Any thoughts?
You complain about Drupal’s security, but you use Wordpress?
I would never run Wordpress on my server.
I think Wordpress is a hunk of poo for anything other than what it was intended to be – a blogging engine. My blog is a hobby and not a production-grade project.
Seconding (thirding?) the django recommendation for those who want something that’s pure framework. I build a lot of stuff personally and for clients in Drupal, but I also tinker with Django, and it’s a pleasure.
A good review, if a little negative. I think you have missed some basic points, although I see from your edits that you now realise that Views is not templating. Templating is done in the file system via tpl files. As for the logs, that is optional. Many of us just use Google Analytics instead.
You also fail to mention the Cache system which greatly increases speed.
Drupal is a great CMS, it is easy to use and can create content out of the box for a multitude of sites (see http://nickbits.co.uk/blog/2009/09/book-review-drupal-6-site-blueprints ). You may have to install additional modules, but it is so much easier than coding from scratch.
Sure you could code your own from scratch, but why? Drupal is faster, easier, safer, more secure. Like any tool, Rails, WordPress, etc. you just have to take the time to read the documentation and learn the basics.
Nick
Amen,
I have worked extensively with Drupal, and the main problems with it are described quite well in this article. There is no ability for reliable change management in Drupal, and it’s only somewhat pleasant making version 1 of a site with Drupal.
If you’ve EVER had to make version 2 of a site, or if you’ve EVER had to inherit a previously developed Drupal site, then you know it’s truly a nightmare to wrap your head around.
Some elements are files (tpl), some are database settings, others are conditional blocks, others are javascript, etc.
No one can deny that Drupal is a powerful and flexible platform. They’ve accomplished this. However, in this day of age, people want to be able to make changes quickly, and you just can’t do that with Drupal.
Nice article.
A good programmer could program a basic CMS in any language in a day or two.
12 Trackbacks
[...] el blog Robozen me encuentro con una serie de 3 puntos por los que Drupal apesta como CMS o como sistema para blogs. ¿Es que todo en Drupal se almacena en la base de [...]
[...] as a Tucker Max story is challenging There’s no better way to start a Monday morning with a hilarious rant about Drupal. Despite the mild headache, tis gonna be a good [...]
[...] Drupal Sucks [...]
[...] the posting and the comments here. Share and [...]
[...] Drupal sucks: http://robozen.com/technology/drupal-sucks/ [...]
[...] of all, thanks to everyone who read and commented on the original post. If nothing else, I got some (angry) tips for how to improve my Drupal experience when I do have to [...]
[...] Drupal Sucks: Un très bon article, en anglais, sur les défauts du CMS Drupal. Travaillant actuellement sur cette plateforme pour un projet, j’ai apprécier le libre ton et les précisions de cet article. [...]
[...] Drupal Sucks ou “Drupal Sucks” Followup: Drupal Alternatives par Mariya [...]
[...] worst thing about all the documentation over on Drupal.org is that it’s just not very accessible to non-developers. But first I want to address the [...]
[...] Yet Drupal is much like a modern-day Achilles. It has small weaknesses that, for the basic user, cause the whole CMS to fall. By way of two examples, Drupal lack basic image uploading and manipulation as well as custom permalink structure (views is confusing as hell, I’m sorry). In the end I found that Drupal is freaking hard to use and has a high learning curve (via). [...]
[...] I want?Edited:can you please share your cons and pros from your experiences of these 2 cms.Edited:http://robozen.com/technology/drupal-sucks/jsut read all the comments here. hmmm, drupal kind of worried me :/ since I’m looking for a [...]
[...] A good debate is located here, by the way: http://robozen.com/technology/drupal-sucks/ [...]