Why we stopped using Drupal for our platform

Me with Dries Buytaert, creator of Drupal
Me with Dries Buytaert, creator of Drupal

I love Drupal. I have been engaged with the technology, the community and the vision for about 2 years now. So much so that I attended DrupalCon 2012 in Denver and loved it (I compare it to Google I/O when I consider the quality of tech conferences I have been to). But unfortunately, due to the reasons I am about to describe, I have come to the realization that Drupal is actually a horrible solution to build apps (content or non-content heavy) in agile environments, which is pretty much the case with most web start-ups. This has led me, the sole developer/engineer of my startup, to switch from building our core platform on Drupal (which I did for several months) to now building it in Django from scratch. This is not a pro-Django article, as I think I could accomplish the same with more or less similar difficulties in the 7+ MVC frameworks I have worked with in the past. I want to tell you exactly why Drupal is not right for such a context.

Drupal, much like many other CMSs, follows a development methodology that I call reverse development. It is the simple idea that the most fundamental moving parts of the technology have been already built for you, or are modifiable using a trivial UI, and for you to be able to accomplish a certain special functionality, you are required to engineer your way backwards by “hooking” in to its current processes, and modifying the functionality or data to your preferences. This is not only true with non-user-facing functionality, but also with views data fed into templates, and sometimes also with designing themes. The benefit of this approach is that it allows non-developer site administrators to do simple changes to functionality with modules/plugins without ever writing a line of code. In fact, Drupal today supports creating models and model objects (using concepts like “Field”s and “Entity”s) using amazingly intuitive UIs. Unfortunately, this has some very serious bad implications for developers trying to build “apps” (CRUD++):

  1. Lack of familiarity with core functionality. Because most functionality is actually hidden from the developer, as the process of development involves interacting with an API and “injecting” code snippets in existing operation flows rather than defining the flows by yourself with rich abstractions, he/she has no idea how most things work. This includes having no idea what the database schema looks like, or having any clue that you’re modestly small app has already left a footprint of over 200 MySQL tables. This not only gives rise to horrible debugging experiences (for which there may be good tools) but also inability to optimize performance.
  2. High development time. I have personally trained at least 3 developers to get started with Drupal. Unfortunately, they say the exact same thing as I said when I first started learning: this takes way too long as is too confusing. If you’re going by the assumption that someone who can write PHP can easily pick up Drupal-like CMS development, you couldn’t be further from the truth. Despite spending so many nights on their API docs, I still require tremendous reading time whenever I am confronted with a new situation. What’s worse is the fact that a lot of the API changes with every new release, making half of the StackOverflow debates on “how to get xx done” outdated after a couple of years.  No start-up can afford a high initial learning curve, as it just doesn’t fit into their agile development practices or MVP goals with often scant freelance tech labor. It just takes way too long to get really really simple things done at times. There is a reason why Drupal devs are some of the most hotly desired tech talent in the market.
  3. Custom comes at a big cost. Drupal comes with rich defaults in just about everything it comes packaged with. It is a pleasure to use these when you want to play nice. But unfortunately, when you are trying to build an app with a very specific look, feel and functionality, you often want to build things from scratch. Trying to do anything custom, such as pump in your own variables into overly complicated and obscure views objects, can suck up your time and energy before you know it.

Another really important development concept around Drupal is modules. This is the equivalent to modules or plugins or extensions in most of the CMS world. One can say this is similar to apps in MVC frameworks like Django, but no, its not. It’s not similar because writing a module in Drupal requires a massive amount of boilerplate. It’s not similar because one never defines models or views or controllers or templates in their traditional sense, but rather writes functions and functions and more functions not forgetting helper functions. It’s not similar because the scope of a module’s functionality is not just confusing, it’s scope is undefined. Sure modules are re-usable and distributable, but they are barely comprehensible because of the breadth of API hooks they use and implement themselves.


To sum it up, Drupal, for the reasons mentioned above and more, may not be a good environment for your agile development needs. It is an extremely robust, powerful and beautifully architectured technology ecosystem for its purposes, but can easily become a developer nightmare in ambitious contexts. Some people consider it a good tool to build an MVP – I won’t debate that, but I do not fully agree too, as it can very easily become a pain depending on what you are trying to do. All hope is not lost, there is good news – Drupal has partnered with the Symfony (a dying PHP MVC framework) community to bring some of its components and app development philosophies into Drupal 8, Drupal’s next release. I have been witness to the discussions on what is planned for the same, and I am sincerely impressed. With the amazing brains behind the same, I won’t be surprised if one day Drupal is amazing to build things from “scratch” with, but unfortunately, today, it’s not.


UPDATE: I take back the adjective “dying” for Symfony. I do not actively follow the progress on Symfony and Symfony2, but my friends following the community closely mentioned that it is certainly not thriving in popularity. I pissed off a couple of people I sincerely respect, in the process. So, apologies for that!

147 thoughts on “Why we stopped using Drupal for our platform”

  1. I guess this is normal for every CMS out there. You get a lot out of the box but as soon as you need more and more custom code the CMS starts to get in your way.

    1. Not sure, Terje. I haven’t done too deep a research, but I am sure there are CMSs that are more developer oriented. Which is the direction Drupal 8 is embracing. Which makes me really happy :)

      1. Check out Processwire – it is very delevoper friendly. I used to build my own custom CMS’s until I discovered ProcessWire – it rarely gets in the way like the other ones I have tried.

      1. We also have experiences more than 10 websites we built with Drupal. Lots of hassle, especially when we have more than 15 modules installed, next to our own developed module.

        We are moving to Django, especially mezzanine, which I am happy with the decision.

      2. IMHO Drupal is a huge nightmare. I’m a Django developer as well. Never used other python frameworks like web2py, so i can’t say it’s the best, since i can’t comapre it with anything.

        But i can’t compare using Drupal with using Laravel, for PHP, even when i’m also a total n00b @ that. And since i’m a developer and not a final user, I can say Drupal is HORRIBLE regarding coding. “Drupal is good despite php” is FALSE: Laravel is good despite PHP, in comparisson. Developing in Laravel is beautiful (even when PHP has serious disadvantages against python, Laravel circumvents many of them and “emulates” many of the django features).

  2. I have not worked with Drupal, but if it’s a content management system like WordPress, then I agree that programmers would be better served working from scratch. In fact, I was asked to debug a WordPress site because of my knowledge of PHP/MySQL. In response, I advised that they should look specifically for a WordPress plugin designer.

  3. This post does a great job of saying something I’ve been wanting to say myself. I am moving away from the excellent WordPress platform in favor of developing in scratch using light frameworks like PHP/Slim and Python/Bottle.

    It could be that greatness is what has made WordPress big and sophisticated. If you are doing a blog it can’t be beat. I know WordPress ninja guys can make it do anything.

    For me the time and energy to figure out how to do what I want within the framework and workflow that they have defined is simply too large and doesn’t create the kind of snappy and unique look and feel that I want. The power comes at a great cost to flexibility, simplicity and efficiency. I like the idea of having just the code that is needed – not an extra line or module.


  4. Senior drupal developer, i allmost agree with this in general. Being agile with drupal ! that is a real challenge.

    Laravel is the php framework to follow these times

  5. Whilst I agree with everything you have to say about Drupal 7, Symfony2 is NOT a dying PHP MVC Framework.. have a look at their github and their current bundles, the work that has been created as a result of symfony2 – composer, etc…

  6. Interesting points and I’d agree that I wouldn’t use Drupal for application development but for content site development it’s very powerful if you know how to use it. I would however disagree that symfony is a dying framework, what leads you to draw that conclusion?

      1. Hm, if your project dont have “Drupal Expert” dont go with it, wrapping your head around different concepts take time in drupal. On the other hand Django is really easy to learn and you can implement features on the day one. I will not ask anyone to switch but should take decision based on resource in his team.

    1. Thanks for pointing that out, TPP. Definitely did not know as I haven’t heard the phrase before. I am sure there a tonne of similar phrases floating around the web, we all need to come to a consenses on what to call this.

  7. I’m curious why you call Symfony a dying MVC framework. Symfony is observed to be growing rather than dying and it doesn’t say it’s based on the MVC pattern. MVC is a specific pattern. Do you mean MVC or separation or concerns? In either case, I’ve used Symfony or parts of it in ver non-MVC setups.

    I also find some of your assumptions interesting.

    1. The scant freelance tech labor force goes beyond freelance. I’ve observed a lack of a experienced web tech labor force going well beyond freelancers. I see people who claim to be experienced doing bad work and not able to talk through the technologies. Or, I’ve seen them not understand simple solution patterns to common problems (e.g., CSRF protection).

    2. High development time depends on what you’re trying to do and who you have. A handful of experienced Drupal developers can build something faster than a handful of people who need to learn Rails at the same time they are starting something up. What you use, the time it takes, and how it turns out is often related to people and not a particular piece of technology.

    3. The reverse development (as you call it) can be a real problem for a lot of developers. Novices and site builders seem to really like it. Many more experienced developers complain about EXACTLY this same problem.

    Good luck with Django. I hope that works out better for you with what you’re building.

    1. Matt, first off, thanks for reading and responding. I am a fan of yours.

      I have taken the use of that adjective back. My apologies. I meant the use of Symfony with the MVC pattern there. Should/could have been more clear there.

      To respond to your points:

      1. Agreed. I think I meant scant tech labor, but in the context of start-ups, freelance. Semantics
      2. I think I mentioned that to be true only for CRUD plus a little more functionality apps. Which is very much the case for prototyping. Unfortunately, I don’t think that Drupal has only a high initial learning curve. It generally takes a lot more code, a lot more understanding of distributed files, to get stuff done. The correct answer is “it depends”. But most web startups don’t have or have access to experienced Drupal talent, so this would hold true for them.
      3. Agreed. I would say site adminisitrators like it. Not people who have previously played around with app development using this fancy frameworks built in the last 10-ish years.

      Thanks for your wishes! I hope it works better too. Have to write all the content revisioning code from scratch this time around, but in all honesty, I don’t mind as I am finally understanding how it works, rather than node magic

  8. This is where Drupal’s dual-personality as a CMS application and a quasi-framework can cause problems. It’s so tempting to use as a pure app framework, because it offers so much for you… except when you want to go outside of the normal workflow, and then the normal workflow gets in your way. I’ve seen some really compelling application-esque systems built on Drupal, but truth be told that’s not its sweet spot.

    I’ve written about the difference between an additive and a subtractive (what you call “reverse development”) system before: http://www.garfieldtech.com/blog/small-core-big-ideas

    Symfony is anything but dying. The reason we adopted it was because it was doing so much well, and it would save Drupal 8 a lot of time reinventing wheels we didn’t need to invent. As they like to brag, it’s the most watched PHP project on GitHub. :-)

    An important side-effect of that, however, is that the distance between Drupal and Symfony gets smaller. That means even though Drupal 8 should be a more additive, flexible platform than Drupal 7, if you find you really need a for-reals framework instead of a super-flexible application (which is often the case), Symfony is right there and shares many of the same concepts. In fact, with HttpKernel it should be possible to embed one within the other. Neat. :-)

    The distinction I usually draw is “Which is more important, your content, or your business logic?” If your content is foremost, and your business logic is just variations on the usual CRUD theme, then a good CMS (such as Drupal) will serve you well. If, however, your business logic is more important, and easily configurable content is there to support the business logic and not vice versa, then you’ll be better served by a “true” framework (Symfony, Django, CakePHP, take your pick).

    Drupal 8 will definitely be better for what you’re describing than Drupal 7. However, if you want to “build everything from scratch” and not use UI-based configuration… then yes, Drupal is not the tool for you, and that’s OK.

    1. Larry, thanks so much for taking the time to read this and comment. I remember meeting you at the DrupalCon and was just so impressed on where you are taking this. I am a big fan of yours.

      Thanks for sharing your blogpost on your ideas on addtive and subtractive development. It is similar to what I am calling “reverse development”, but I am sure you understand this problem way more deeply than I ever will.

      My sincere apologies calling Symfony “dying”. I have taken that back! I am fully aware why it is being adopted in Drupal 8, and I cannot wait to see how it gets integrated into core.

      I like the distinction you are drawing out there between content and business logic. But I feel that it isn’t all that simple of a question to ask. And this I say from personal experience. The site/platform/app (whatever you call it) that I built, all revolves around content. In fact, its core goals are good content and revision management. With little business logic around it. And looking at great contrib modules like workbench and the node revisioning system, I thought Drupal was the best bet. Until, 8 months into it, I realized how painful the journey had been. Business logic and content cannot be separated in an “app”. In a static public facing organization website, your distinction would make perfect and complete sense.

      Looking forward to everything you are working on for D8. I think my “” were around scratch and not the “build everything from scratch”. But I get and appreciate your point – thanks!

  9. It sounds like this post is making a case that Drupal has a steep learning curve and a strong understanding of how to develop productively was never achieved.

    I definitely agree, the learning curve is steep, but the technical arguments beyond the learning curve are a little weak.

    For example

    because writing a module in Drupal requires a massive amount of boilerplate

    This is pretty far from the truth. A .info file with a few lines that tells the system the name and version of your module, and a .module file itself, is all you need to create a module. Depending on what that module does, it could be a few lines of code. As with any app you develop, the code is going to grow with the functionality you need to implmement, but in general, a module definitely does not need a massive amount of boilerplate.

    It’s not similar [to MVC] because one never defines models or views or controllers or templates in their traditional sense, but rather writes functions and functions and more functions not forgetting helper functions.

    It’s not MVC in the traditional sense, but it does good at providing the tools to separate the display logic. The developer could apply MVC principles in practice by using the module as your controller. Within a module, you have the full capability of defining your own templates to separate the display logic. Then treat the entities (nodes, users, etc…) as models.

    Writing functions and helper functions sounds like standard development to me. If you feel you’re writing too many functions, you may be taking the wrong approach.

    High development time. I have personally trained at least 3 developers to get started with Drupal.

    Respectfully, I am not sure how effective training developers would be when so much doesn’t make sense to you. With the steep learning curve, maybe “high development time” should be “high learning time” because development time really isn’t unusually high when the concepts and APIs are understood.

    All that said, it’s just a tool in the toolbox, and it makes perfect sense to go with tools that are more comfortable for the tasks at hand.

    Also, not sure if anyone mentioned yet, but the upcoming Drupal 8 will also be incorporating many core Symphony libraries.

    1. Mike, thanks for your thoughts. I sincerely appreciate you taking the time.

      To address the points you raised:
      1. A .info file = boilerplate. A database schema definition hook with need to specify to the detail of number of characters in a varchar field (if we don’t get into the discussion of control) = boilerplate. Defining themes to present you’re views in a custom way = boilerplate.

      2. What makes an MVC framework a framework that is good at MVC is its ability to encourage MVC-oriented development behavior. A not-deeply-experienced developer should not be expected to enforce the pattern if the framework and its documentation does not encourage it. And I have repeatedly read arguments about “but a great Drupal professional…. blah blah blah” in other contexts, when defending Drupal – but hey, Drupal isn’t meant to be hacked only by elitists, now is it?

      3. You’re comment is taken respectfully. But my argument is more that I consider myself fairly competent at Drupal, and I still struggle with teaching several concepts and touching deeper moving parts for some fairly simple behavior. I shouldn’t be expected to know how to hack the core for simple things, now should I?

      1. “Hack the core”… seriously, you just used that sentence in that context? http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-not-think-it-means-what-you-think-it-means

        I liked some of your article, some of it. I agree that Drupal makes a great CMS, I agree that writing your app from scratch makes it more agile for you (as long as you can remember what you did as it grows) I will say that Drupal can be used for “lighter” “apps” by providing those “apps” it’s content/data… as well as many many other cases.

        The right tool is the right tool only when used for a specific job and specific resources with the future of that job and future resources expectations taken into consideration…

  10. I think these are valid points, but I also think there is something to be said about the differences of working on one web site/application full time and working on 10 sites a year. There’s not always enough time to build everything from scratch in a project. I’m glad that I can lean on the huge Drupal community and contributed modules so that I can get projects completed for clients quickly. Hooking in and altering existing functionality saves a lot of time, especially knowing that the same code is being tested by the larger community.

    1. That is certainly true, Jon. But it is also true that one can use “contrib” apps in MVC frameworks in just a similar way. I used to fight endlessly with my developers to prove how the Drupal community’s work can be so easily re-used, but after having re-used apps in Django, I didn’t think Drupal had any edge after all. The only edge was the readiness for site administrators – there is nothing easier for a non-developer administrator than Drupal’s environment when it comes to installing new modules.

  11. The partnership with Symfony is brilliant for both projects. I follow Symfony on gitHub and frankly I don’t know of any project that is more active or alive. They are leaders in the PHP space.

    In the 30 years I have worked with IT, I have trained many devs and I have been trained in many new technologies. In all honesty, I can’t think of a single application that wasn’t confusing at the start.

    I agree that it was easier to understand when we built applications from scratch, years ago. But, the level of sophistication required for applications today makes it impossible to rebuild all functionality. Let alone in a way that we can be assured of any level of correctness.

    Today, learning how an application works, understanding how to add a little code here and there, is largely what a good application developer is called upon to do today. The better one understands the environment, the more quickly they can get the job done.

    I am eager to see the Drupal community, with an insane amount of knowledge about all kinds of technology will do with a frontend controller, plugins, and that HTTP Foundation beneath that CMS. It’s going to be good, I’m confident of that.

    I am curious, though, why the picture of you and Dries? In context, maybe not constructive? I don’t know. Sticks out to me.

    1. Thanks for the comment. My apologies for considering Symfony dying, Amy.

      All very sensible and good points there. They are not over-the-top and loud like my arguments, but very much the truth of how things work. I am also very confident in Drupal’s future.

      The photo was to emphasize my love for th Drupal community. And hopefully convey this to be constructive criticism. Possibly add a little personalized touch too. Thanks for pointing it out, anyways :)

  12. I have felt your pain of trying to work within the constraints of a cms. Realizing that on wordpress or joomla building the things I wanted to do was going to be super difficult. I chose Ruby and Rails instead of python and django. After a month I was absolutely sure that jumping ship was the right thing to do. What you get out of the box just isn’t worth the pain.

      1. i think the original post makes some excellent points, and is spot on it its critique of drupal, imo.

        when the only tool one has is a hammer, everything looks like a nail.

        these days, almost every website i develop or update is a dynamic content-driven site, with some amount of additional (sometimes fairly complex) functionality that i have to develop. drupal is awesome for this type of development. a large-scale business application would absolutely warrant a look at more fundamental building blocks/frameworks, depending on the business and technical requirements. prior to about 2 years ago, i used my own custom php framework for all web development i did. the reason for that was i had looked at all the major php frameworks, and decided they were all just ruby-on-rails wannabes. i had worked with rails for a year or so, and despite some fantastic concepts (which, sorry if this sounds like a self-back-pat, i had implemented in toolsets for distributed application development back in the early ’90s), i literally HATED the implementations, not to mention the dogma and condescension of the community.

        i am a bit of a dinosaur these days, having been doing software development for well over 25 years. i find that these days almost anyone can fancy themselves a developer and throw together something using any number of php frameworks/tools, or rails, or whatever. when i look at some of the (php) open source applications out there that are widely used, i am truly shocked at the poor quality of the technical design and code (i know i am not alone here). wordpress, oscommerce, zencart, squirrelmail, these are just some major examples. drupal does a bit better imo, as at least it looks like some forethought and technical design went into it. but seriously, these days the underlying assumption seems to be that blazing hardware and massive caches can cover up any poor/lack of design.

        and that is my primary complaint about drupal (and even moreso for all the rails-like frameworks). the desire to make the developer’s job easier has resulted in some design tradeoffs that imo reduce the overall efficiency, stability, and performance of the final product. as someone who had to focus on large-scale database design efficiency and performance for so many years, when i see that rendering a single html page requires 30-50 sql queries, i am appalled. sure, people just throw hardware and caching at it, but does that truly solve the problem in the long run?

        what we used to call model-driven development (models in this case being design models such as db models and object models, not mvc models) provided what i think is a great balance between solid technical design, excellent flexibility, and runtime performance. you design your models, then you generate very specific and optimized code for the specific context of that particular system or functionality. (caveat – i wrote a great many code generators in my day, and as a system architect and experienced developer in a wide range of languages, i understood how to generate optimized code for each toolset being used, from sql to c/c++). obviously the design allows for custom coding that can be plugged in in such a way as to not be impacted by re-generation of the models (many current frameworks have adopted this, hence “core” vs contrib or whatever). i thought rails had this concept down, but when i saw all the runtime activity behind the scenes … wow. having to query the system catalogs/data dictionary at runtime for virtually every operation in a high-volume system… holy shit!

        the one php framework that i really liked was kohana. well designed, efficiently coded, and nicely object oriented (as much as php allows anyway). true, kohana also wanted to have that rails-like auto object-relational mapping, but i was easily able to simply not use it. v2 of my custom framework was actually built on kohana. problem was i had to create too much common functionality myself – that is why i eventually adopted drupal for the majority of sites i do. the drupal learning curve is fairly steep, and i would have made some of the design decisions very differently. but the coverage of useful functionality right “out of the box” makes it a viable contender for all but the largest and most complex of applications, imo.

        to summarize my rant: i feel like current web development focuses far too much on making the developer’s job easier, at the expense of solid design and runtime performance/efficiency. the latter is somewhat offset by using high-end hardware, gobs of ram and cache cache cache. to me that is a band-aid. no amount of hardware and tweaking can substitute for good design, in the long run. an unfortunate side effect of making development easier, is that the quality of code overall is hugely degraded, because almost anyone can do it.

        like i said, i am a dinosaur. and i no longer have as much desire to keep up on all the new technologies and languages, so no doubt there are aspects of this discussion i am missing.

        this is a good discussion, thanks!

  13. Hi.

    As a certified requirements engineer, I believe your issue could have been avoided with proper Requirement Analysis. I have been using Drupal for 6 years, but Drupal has never been my only solutions, as I also plan for custom developments and also using other solutions as a basis. I can never say Drupal, or any other system, is a solution to every project. Only after a proper requirements analysis should we decide the solution that we want to use.

    1. Thanks for that, Muhammed. Just fyi, I have two degrees in Information Systems from one of the best universities in the world, and that is one of the most vital things taught. No level of requirements analysis per se can give you a sense of painful development experience that I have experienced. No requirement analysis tools give you a chance to ship an MVP to gauge adaptability to needs. And realistically, which start-up does that?

  14. Very interesting discussion.

    1. I can share the author’s feeling around reverse engineering – and I like the term. Because often with Drupal it feels like you need to search relatively deep to fully understand what to do in a specific case (especially when you do it the first time).

    2. The problem for me clearly comes from the following contradiction: Drupal is very easy to install and use even with little PHP knowledge (which helps grow its market share). But once you reach a certain point of customization, suddenly a lot of knowledge/research is needed to get little things completed. Hence the frustration.

    3. Final problem (but also strength, of course) is that there are so many different ways to do things in Drupal. Just compare: why does Drupal’s theming documentation have more than 100 sub pages and the one from WordPress is a single, well structured page?



    1. Thanks, Stefan.

      1. reverse development, not to be confused with reverse engineering. Very large difference.
      2. Great point!
      3. I think theming is an all-time disaster when it comes to CMSs in general. Needs to be addressed sooner rather than later.

  15. This is an interesting perspective and one that I’ve honestly not heard before. My own agency is a WordPress shop and we find ourselves doing much more customization than ever in the past. We have a client who is a Drupal shop who is developing new features and rolling out new site components every week and are incredibly happy with the platform. They have over 3 million pages on their site, it’s incredibly fast, and the CMS is providing all the functionality they need or the flexibility to develop it. The problem that I see with your objective criticisms are that you don’t balance the customization, development time and lack of training with the advantages of getting a CMS “out of the box”. Are you evaluating the time that you spent with the time that you saved? Developing a CMS from the ground up these days are just plain nuts. Every CMS provides content management, media management, search engine optimization, and other foundational principals that are missing from virtually every website we see that are home developed.

  16. I’ve been developing on Drupal for 7 years and what I tell you, whether to use Drupal or not depends on goals. For myself I understood the following:

    a) Use Drupal when you need to build a content driven WEBSITE for a client and when client wants to be able to move blocks, have access controls and stuff. Drupal gives you all this out of the box and tons of modules are to help you there.

    b) Use framework (Rails/Django) when you need to build an APP. Be it web app, facebook app or mobile app with web backend.

    So to sum up, use Drupal for WEBSITES and Rails/Django for APPS. Simple.

  17. Varun, you’ve said what some may not want to say, and it’s good to keep an open mind. I run a small Drupal shop myself, and Drupal is all we use. However, there are some projects where Drupal may not be the best solution. We usually provide honest feedback to RFP’s or simply decline those projects. But why decline? I’d like to consider some alternatives, such as Django/Python. Perhaps being too specialized can limit a development team’s potential. “Do it with Drupal” holds true to me still. And WordPress is still on my radar, although each of these systems and frameworks lacks something due to the fact that the same things are done over and over again, which is why I really liked reading this, about the “DRY Principle“: http://c2.com/cgi/wiki?DontRepeatYourself. Thank you

    1. Thanks for your thoughts.

      DRY is a beautiful concept, but an engineering nighmare when it comes to the way Drupal-like CMSs are architectured. There needs to be a reasonable discussion and assessment on where Drupal falls in that spectrum.

  18. Nice to see some constructive points about where this platform falls short for complex (enterprise) implementations. Microsites, campaign sites, social sites are much different than developing business applications for the web.

    I only use TYPO3 for many of the reasons you have stated above. No other opensource CMS can really compare. However, as Muhammad Aslam bin Ahmad Suhaimi stated one must consider the requirements and then determine which platform provides the best framework for the project.

  19. After reading your article, I agree with your assessment of Drupal almost to the letter. I’ve tried multiple times to get into the framework, but found that the further you want to get away from their basic configuration and more into custom functionality, the steeper the curve became. Hopefully version eight will change that.

    My reason for posting though, is I’m curious as to the reasons that you chose to go with Django as opposed to other web based solutions out there, such as other PHP frameworks/other Python frameworks/Rails/Perl/whatever?

    1. 1. Willingness to have a scalable backend in a language that can support it, thus not running dev environments for different languages which become hard to manage all over the place
      2. Low dev time and easy debugging. Replacing Java in many CS programs across the country as “language of instruction”
      3. Community
      4. Is certainly the easiest framework by far I have come across
      5. No unnecessary CRUD views generation. Much more sensible in C & U & D with it’s admin panel approach – just like Drupal
      6. Documentation and libraries (Google supporting a language is almost a good reason in itself)
      7. It’s cool

  20. I could not agree more with you. I went through the very same experience of programming with drupal for almost 2 years and it was a nightmare. The last straw was when I had to deal with groups. Taxonomy and groups are so much confusing that I could not continue with that. I hated it. My new reality: WordPress when a basic CMS is needed and Compound.js, Yii, Laravel or whatever MVC fits best for web apps.

    Very happy with this decision.

    In fact, during those dark months of Drupal, I had to make a prototype for a web app I then developed using Yii. Thanks God I took that decision otherwise I would be dying today to support all I had to do with that project.

    I left Drupal and despite this new comment in Hacker News (http://codedrop.com.au/blog/re-why-we-stopped-using-drupal-our-platform), I backup your position 100% based on my personal experience.


  21. Frustrated with Drupal Webmasters taking weeks and even months to respond to a 10 minute project ownership transfer. The problems with the system are more apparent than when I started including the amount of bugs, lack of maintainership, and general politeness in many cases.

    Looks like Django…. or Ruby on Rails…

    Bye Drupal,

  22. Django is great. Small learning curve compared to Drupal. It runs faster. No need for all these off the wall ways to test code. It’s simple comparatively. Switch from Drupal to Django and you won’t be sorry. It’s only been 2 weeks and I am 100 times happier. Thank you Drupal webmasters (sreynen) for being so unprofessional. I would have never made the switch without your bad behavior and I appreciate it more than you know.

    The bugs are few and the coding is new. Come see Django.

    Thomas Rendleman

  23. Just curious as the article suggests knowing PHP is not enough to be able to interact with Drupal. 2 years with Drupal and I’m tearing my hair out on a very frequent basis with hooks/process/preprocess (WTF?!), although I have little programming experience, I decided to learn Python instead of PHP, hence my interest in this article.

    So, when it is said thay Django is ‘easy to learn’, does that really mean it’s easy to learn (if you’re an expert at Python)?

    1. Hey Sam,

      I started learning Django after around 5 part-time days into learning Python. I still don’t feel like I learned a “new” language – it was that simple.


  24. You almost took my words “sweet spot where MVC frameworks and CMSs will converge”.

    I started with Zend Framework 5 years ago before I ventured into the world of CMSs and after learning Drupal which I am at the moment more full time devoted into. I always had a feeling if some how these frameworks could provide more than the code (not just scaffolding) but also some sort of widgets, bundles (symfony is great on bundles) etc. that a CMS like Drupal offers.

    I have never been more excited about Drupal 8 as it is using best practice that Symfony provides, then Drupal could be considered as an App Framework instead of a CMS. Something which Dried lamented about in DrupalCon Sydney 2013, why Drupal is not thought in the same vein as Rails for start-ups. Looking at Drupal 6 and 7 and on top of your comments, it is quite obvious why it has been all along.

  25. I am considering giving croogo CMS a go. Built on CakePHP MVC framework. It looks like a developers type of CMS. May be a better alternative to feature rich CMS’s like Drupal.

  26. Helping this company start, specially guiding what to use and why, I come across this same decisions constantly. One hing I have learned in the time working with different projects using Open Source is that we will always have this discussion, is not CMSs, it’s not PHP, MVC, etc.

    It is a matter of specialization or not. Do I want to specialize or do I want to know many tools and have different “weapons” for different projects. Well… there is no perfect answer; I have been in both sides I have vouched for specialization and vouched for “generalization” (quoted since I want it to mean be able to use any or many tools).

    Today my experiences showed me that specialization is better, if you know your tool you can do ANYTHING, not to say it is better or you need to forget about the rest. But if you know your tool you can fix everything.

    it is god practice to choose the right tool for the right project, of course, but when resources are short and you need to be able to do everything it is better to have a Swiss army knife than a fool tools shed with several specialized tools. That is, if you know your Swiss army knife better than any of those tools.

    For us,that is Drupal! Is it complex oh my God!!! yes! will it do most of the common tasks of a web shop? Sure!!! is there a module for that, most likely!!! are we learning to use it for anything they throw at us? yes! is the best solution? nah! sometimes overkill….

    But since we decided to specialize we decided to learn how to tackle most of the common tasks with it. And that works better than having the few resources available trying to learn two or three different tools so we can use what we need when we needed.

    In other words our decisions was to take the company to be a Drupal expert and not a general web Developer and tackle everything as a Drupal experts, we do not let this transfer to clients the best we can of course.

    We decided for Drupal for it kind of “In the middle” approach, it is a CMS with so much out of the box but at the same time it isn’t since it has a lot of framework too. This gives us the opportunity to focus learning on one tool and be experts on it instead of trying to gain expertise in a couple of them. Maybe in my head I compare it to Queues theory. one learning queue, even as steep, is better than three easy ones since time won’t triple but worst.

    That is our approach, and I feel this posts comes from something I learned as a Martial Arts trainer and instructor… lately we have been training (my head instructor and a couple of us) our young people to compete for the Olympics and that means learning different drills and new techniques and my head instructor has a say that applies perfect to this topic. Every time we practice a new drill he tells us to do a couple hundred reps on any drill, listen to any advice, try to apply it and then decide, if it fits your fighting style keep it, if not let it go. You should use only what fits you and you can use fast and effectively. And coming back to this, if Django goes better with the way you feel more comfy developing a project, your tool is Django. or Drupal…. but if that tool does not align with your mental map, it does not matter how good it is, you won’t be able to solve much with it.

    We love the concepts of Drupal, love the “monetarization” model of the project,love the handle on creating new modules (the collaborate before create new module, etc) and that makes it better for us… we tried a couple, and could not pass the “Why the heck would they do this” or “it does not make sense to me”.

    You are right in your post, but the question is not what is the best tool, the question for a “computer expert” (quoted cause it may mean so many things) should be “What is the best tool that really works for me”.

  27. Well, after pondering this article, I realized our shop is a Drupal shop. I had never really thought about it in those terms but there you have it.

    We abandoned our in-house CMS about 6 years ago and decided to learn Drupal inside and out. The upside is that we haven’t experienced the frustration that the author has and have yet to run into a project that can’t be accomplished in Drupal. We eat, sleep and sometimes dream in Drupal so maybe we’re not all that typical. We’ve been building websites since the mid-late 90’s and I really can’t remember all of the sites we’ve built in that time.

    Since we adopted Drupal we have developed, launched and mainatain about 50 Drupal websites. The majority are smallish sites but about a dozen of them are for large organizations and are complex sites integrated with a CRM back-end for memberships, events, ecommerce, etc… You would think that maintaining that number of sites would present a maintenance problem but it really hasn’t. We use a selection of vetted modules (+ a few of our own) and we use the Drush tool to update the sites. Typically updates last a few minutes. Upgrades (D6 -> D7) take a bunch longer. Hopefully the new MVC platform will help reduce that in the long run but that remains to be seen in the next few years.

    I personally am very excited about Drupal 8 and the integration of Symfony 2. This will help remove some of the cruft from module code. You’re still going to need to know how Drupal works because it is the foundation and does a lot of heavy lifting but using Drupal as a platform for developing on will be much better organized with the MVC and OOP direction that’s being promoted in D8.

    So I guess I’m glad you love Drupal and sorry to hear you’re giving it a rest for a while. Maybe you’ll come back when D8 arrives (and stabilizes). You aren’t going to loose anything from leaving Drupal and embracing other technologies or methods. Who knows, maybe you’ll come back and enter the Drupal world reinvigorated or maybe you’ll stick with Django and Python. Nothing wrong with that.


    1. Yeah, until you want to add a custom field in ubercart checkout. Something that would take me 3 mins anywhere else, takes an hour + in drupal. I guess I would dream about drupal and it would be on my mind all day, because i spent all day doing simple tasks! Drupal slows down the development process, makes things harder etc. I think the people having trouble understanding that lack real programming skills!

  28. A bit late to the party, but I got pointed to this article by a friend, only now; I made a similar decision http://berk.es/2012/10/01/farewell-drupal/ a while ago.

    No start-up can afford a high initial learning curve

    I’d like to go further: No start-up can afford a high learning curve. Which is important, because in all the eleven years of Developing with Drupal, each and every new project, site and implementation that got on my path proved a steap curve. You point our something similar; about having to re-learn the stack over and over again. That too, is worse, because it not just core and contribs that require re-learning after each release. Each combination of modules requires new learning.

    An recent example (as a Rails developer): Getting to show Campsites on a map, making them searchable by distance and whatnot. Quite ordinary Geo-stuff. In Drupal, that would involve learning and implementing several views-addons. Gmaps, module and learning how to combine all these. When you look at stackoverflow, or drupal.stackexchange, you find that a large portion of the questions is something like “I have FooBar module and Foozbaaz, how do I get them to FazBooz?”.
    As a rails-developer: I pull in some gems and develop all the geo-stuff the way I am already used: active-record, OOP, some views, some helpers and that is that. It is far more predictable and follows famous patterns.

    This is but one of many reasons to leave Drupal (and other CMSes) and do what I do best (and like most): develop. In a Development-Framework.

    Nice to read that others have the same issues as me. Even better to learn that you manage to word them a lot better then me :).

    1. Hi Ber:
      You’ve just used as example exactly a feature I had to deploy on a project I’ve worked on some time ago. Just bear in mind that when developing the functionality in a framework such as RoR, you would be doing exactly that: ‘web development’. While to implement the same functionality in Drupal, you should not have to write a single line of code. Provided that you are an experienced Drupal builder, it should take you a couple of hours of work. Can you learn Ruby + Ruby on Rails in two hours?
      ‘high initial learning curve’ : it’s a relative and subjective concept. It also depends on what your background is. You choose the tool which is more convenient based on your knowledge, the project at hands.
      At the moment my two web platforms of choice are Drupal 7 and Laravel 4. Often it takes me a lot of time to decide which one is best for the job at hand. Laravel can be learned in 2 or 3 days. Drupal takes considerably longer. Nevertheless, until I delve deep into a project architecture I cannot be sure which technology would be the most appropriate and faster to develop.

      1. While to implement the same functionality in Drupal, you should not have to write a single line of code.

        People often present this as if it is something good. It *can* be a benefit, sure. What is it, that makes “not having to write a single line of code” better?

        In no particular order, this is what I have heard:

        * It allows less experienced people to participate (also known as: I don’t know how to code, but I can still build a site).
        * It is faster.
        * Requires less effort.

        I agree with the first. But wether or not this is an actual benefit, depends mostly on the kind of project: yes, for your small e-commerce, or bootstrapping startup, that might suffice. But certainly not for a governmental site.

        The last two issues, are, as I have been trying to explain, simply untrue. Yes, there are situations in which pulling in a (well known) module by an experienced Drupal-developer is fast. But there are just as many, if not more, examples where this goes completely the opposite site: just have a look at nearly every question on Drupal Stackexchange. Difficulties and issues arising from combinations of modules, configuring modules in unique ways, and so on, are causing 90% if not more of the entire development-effort of just about every Drupalsite where people “don’t need to code”.

        You seem to acknoledge the same problem:
        Provided that you are an experienced Drupal builder, it should take you a couple of hours of work. Can you learn Ruby + Ruby on Rails in two hours?

        Provided that you are an experienced Rails developer, it should take you a couple of hours of work. Can you learn Drupal with most of its modules in two hours?

        You are comparing apples and pears. If, and when, your project requires development effort, a framework optimized for development is simply always the best. Whereas, when you have a simple, predictable and off-the-shelve site, using an off-the-shelve CMS with minor configuration is always the best. And inbetween is the grey area in which sometimes a custom-built tool will be the best, and in other cases, building on a CMS is the best.

  29. As a programmer I have university degree. And I want to warn another programmers about drupal.
    I have been working with Drupal for 4 last years.
    Working as site builder and programmer.
    And I want to warn new programmers about what is not said.
    Drupal is not for programmer’s use.
    It is for web masters’ use.
    You can think like this: “I will learn how to create the modules and I will be creating good web sites for money”.
    But it is not like this.
    The customers don’t want your custom code in their web sites. :( .
    They want site built only on base of drupal.org modules. It is an official ideology. They call it “the drupal way”.
    And this could be done only by advanced tuning of hundreds of modules.
    To understand how to do this you would need years and years. And this is nott even about programming. You will not be programming doing your drupal work.
    And so you will be turning to a weaker programmer.
    And when you would learn your knowledge then a new version appears and you would need to learn again.
    Now Drupal 8 is too complicated to waste your programming abilities on it.
    It has no sence.
    It is my experience.
    I wasted my programming time and skills for the trap with name drupal.
    Now I am leaving from Drupal.

    1. WOW!!! Your are just right, precise and concise.
      May be the word programmer fits on everybody who has commented this article, but I would call them System Integrators, which of course it is a great deal in that arena, but are far form being programers in the context of a pure language, name it PHP, Python, or whatever. Even if you know a framework from top to bottom that does not mean you know and understand the whys, why have to code this PHPO module this way and not another, why a database schema is this way and not another, and that is what system integrators try to avoid using frameworks and of course it is little what they can do secure and fucntional outside the framework. Ok, ok, copy this routine or this code from the framework and lets do this… ups, it does not works or does not fit, why? I have to learn more about the framework because it seems I did not understand it? NO, you need to know how really things work, like the Internet, the browsers in all their brands and versions, the sql server and all of its settings, multibytes and no multibytes functions, bla bla, a framework will never be on top of a language and and there is a reason why a language does not include the functionality of a framework.
      I see this discussion as which spreadsheet is better for programing? don’t use a spreadsheet, use a wordprocessor(non sense)

  30. how i explained the difference bt symfony and drupal to my boss:

    the diff bt symfony (where you’re given a framework sandbox full of sand) and drupal (where you’re given a sandbox replete w lots of pretty sandcastles) is that w symfony you have to know how to build sandcastles from the ground up. since, in order to do so, you have to know how everything works, you end up w a complete understanding of the system, which ultimately makes for a much more manipulable sandbox. w drupal, the second that you–a mere mortal–have to move or change the preexisting sandcastles that god built, you’re in for a world of pain.

  31. For traditional front-end content delivery, Drupal or WordPress are a safe bet, but for application development, there are now a lot of developers using EmberJS and AngularJS, etc to transfer view construction and even data modelling to the client side. The servers in these cases become more or less a CRUD and authentication processors, so it doesn’t really matter whether you are using Ruby, Python, PHP far less Drupal or whatever, so long as the server can receive and deliver data in JSON or XML and/or can work as a rest server. In the apps I’m building now 70% of application code (logic, modelling, view constructs) is client side. As the demand for mobile versions of HTML5 apps is increasing rapidly I see this as growing trend.

  32. I am reading your posts with great interests as I tossed and turned all of last night, trying to decide if I was coming back to Drupal after a stint with WordPress. Unlike you folks posting here, I did not earn a degree in CS. When I graduated, they didn’t have such degrees! :-) I have been working on a computer since before little microsoft icons appeared on the screen and annoyed me. I was among the first group of people who mastered hand-coding in a vanilla editor and was among the first people online when we called it the Wild West, ready for the first building. I’ve gone through all the stages of internet growth and now I’m at a wall, for the first time.

    I was “forced” into Drupal about 8 years ago when a university client demanded it and I foolishly thought I could do it. I nearly became a bald drunk. I began studying PHP in the evenings. I get it; I don’t write it; if I’m stuck I can spend hours/days but eventually figure it out. It took 14 months but finally the university site went up and I loved it’s feature-filled pages. I finally mastered the basic modules needed in a Drupal site, moved to an install of multi-site, and even, if you can believe this, dove into BOA install on Ningx a couple of years ago. Now that is hard (for a non-developer)

    I am not, though, a writer of code. I do not have a CS degree. I am not dumb, which I wish I actually was, as it would be easier to not think sometimes.

    That said, I have no idea right now which way to turn.

    WordPress drives me nuts after living inside the Drupal community. It’s great for the small client who wants a simple site — grab a theme, go, they like you. I didn’t even read the documentation, which stunned me. But WordPress is a different world. Anything you want that’s good, well, you are going to pay. It nickels and dimes you to death, imho. And to do customizations under the hood, well, that requires jquery, javascript, php knowledge at a higher level than I am at. So if you stick with the front end of development and don’t mind living in a boxed world, you can be happy.

    But I am trying to build a site that my one-person business will own. And every time I turn around in the WP theme to create what I want — I’m back having to look under the hood — or to buy something else. Right now, the WP theme I bought can’t be coddled into what I want (something I didn’t know until afterward) unless I get my hands dirty with code. Theme-installed custom shortcodes are a landmine to me. Change your theme and you lose ’em. And what these themes can’t do is ridiculous to me, given my Drupal past. I feel like I am in a box, screaming!

    With Drupal, I can do what I want with a site heavy with content that is both static and bloggy. I can create any which way. I rail against modules and fight them with them. But that’s different fight for me than wrestling with someone else’s code. I find myself within a strong community where user names become known and people collab.

    Drupal lets me build what I want, how I want it, where I want it, but with a lot of heavy effort and grunting. It’s a slow build and I need fast.

    WordPress lets me build what the theme creator wants me to build, in the manner they envisioned it — accompanied by constant purchases, it seems. It’s got a no-brains console and click and install updates of everything (wow..that’s not the Drupal way..what ease.) It’s a fast build but I sacrifice what I want.

    I’m not in a position to hire a developer. And my ego is in the way. I want to do this.

    But dang…which way to turn?

    How I wish someone would step and blend both worlds!

    Today is decision day as I have to move forward. It was a sleepless night. I have a yearning for Drupal but….

    1. You should look at


      for joomla.

      It’s like cck, views combined with direct access to the DB layer.

      I know your feeling, I’ve gone through it as well.

      Joomla bundles alot of the wordpress premium addon straight into core, or for free.

  33. I must say I started at a job as Drupal developer more then a year ago and it has been a rocky ride. I especially feel what you are saying about “reverse development”. While a lot of frameworks or projects has (more or less) adopted the same concepts or patterns, Drupal has it’s own (sometimes plain idiotic) ways. In comparison with my previous jobs it is sometimes a lot harder to get to a certain point.

    I sometimes have the feeling that I’m spending more time to get things done the “Drupal way” then the complexity of the problem itself, or that I would be already finished if I started from scratch or could use another framework. That being said for my personal projects I don’t use Drupal.

    This year I tried the difficult task of designing a SPA (Backbone) with Drupal as the backend as the requirement was “must use Drupal” and in the end I ended up (without hacking the core mind you) of disabling and moving a lot of stuff. It works (and not that bad to be honest) but it was sometimes a really nuisance.

    The “there is a module for that” attitude I sometimes have a lot of troubles with because there are a lot of low quality modules out there. It is sometimes difficult for somebody who is a bit a perfectionist.

    And I’m Belgian and as Dries Buytaert is Belgian it is adopted by a lot of firms here, it is not that I have a lot of choices. So I have hopes that Drupal 8 with the adoption (which is not dead, it is really a nice framework) to incorporate more industry practices.

    I’ve been to DrupalCon Prague and I really liked what I saw regarding D8.

  34. Interesting article.

    When I developed with Drupal I found the same problems you described with the database structure and steep learning-curve. It wasn’t financially viable for me to use it and I didn’t like the level of abstraction between the application and underlying database structure.

    For me, designing and tuning the database schema and related SQL statements is an integral part of application development. Having the freedom to write SQL statements in your application code means terse, readable code that can execute quickly and efficiently against the database server. You can also then take full advantage of the database server optimisation tools and features such as statement execution profiling, cache tuning and indexing strategies.

    Drupal (and may other frameworks besides) drive a big truck through these options by deliberately abstracting access to the physical database.

  35. Drupal gets 75% of a reasonably complex site up and running in no time at all; it’s remaining 25% that I’ve struggled with in order to match web development briefs.

    Used within its, and the developer’s technical ability, Drupal is excellent. Right tool for the right job, and all that.

  36. You are right on point. As i have used Drupal for years, i never use it in my personal projects, or projects i work on as a freelancer. But I haveto use it at work becuase we are required to use it for all client projects.

    Now this problem has many sides, and im sad that the only point the company i work for see as value for Drupal is the UI part, thats easy for the client. But the rest is exactly like you pit it, “reverse development”

    But the more serious problems i see with Drupal is the technical debt that it gives the developer. I see devs who have worked for years in Drupal, but have zero knowledge of PHP and design patterns as a whole, devs who has no knowledge how to do anything other than drupal hooks.

    This leads to a very narrow skillset, and it hard to loose the drupal way developing. Many modules are also of very poor quality, and usually theres no tests at all, the fact that Drupal encourages no testing is horrible. Actually, it is untestable in many parts.

    So, if you are as me and haveto work with Drupal, i highly encourage you to learn other programming styles on your free time, or try to convince your bosses (might be impossible) to concider something else as an platform besides Drupal.

    I have used some symfony components, and i really hope drupal 8 will be of better quality. But im not that hopefull that the core ideas will change too drastically. Last time i had a look at drupal 8 it had the same hook mentality, so the reverse development side seem to be left in the core.

  37. WordPress is for anyone. A three years child can install and fire it up. Drupal is focused for developers. But they are all good if you see your project is not going to get too complicated. I have dealt with many frameworks and I can tell it for sure. The starting time frame is very promising and that’s what kills all the businesses. They do not see the near future cost of development because of huge customization. For ex: you can make an initial version in 6 months let say 80% of the work. You will end up seeing spending next two years for 20% changes.
    Part of the reason is Drupal is extremely slow in development. Because of the architecture. We have worked with top Drupal developers around the world. Yet we have the slowest drupal site. When you deal with complex sites you can not win with these third party CMS. Worst part is dealing with problems. It makes hundreds of tables and joins. Never efficient strategy. Drupal team didn’t have any choice because there is no way you can make something that will fit everyone without going in this route. But when something is built for everyone also means it may not be for you. So you should see your projects future.

    Don’t take my word, just google it for other peoples thoughts. Drupal saves everything in DB. Bad bad idea. Everything is in array. another bad choice. That’s why most drupal site suffers suffocation and memory problems. I have worked with 15 large Drupal sites. For every single thing you have to do alter. Another worst nightmare is it goes through every function in every page load. I can’t believe why people still says it’s fast unless they are blind sided.

    Now Drupal team says it’s enterprise ready. I disagree. Never seen such a slow site. You can make your public site super fast because it all runs off memory and caching. But in development statge it’s slow like hell. If you plan to make a heavy database based site. Your just spending nearly 3 times more money on it in terms of cost. Now yes, all Drupal lover will be on favor. I love Drupal too. But I have also seen the both sides of it.

    Real fact, we have hired worlds top drupal developers to make a cutting edge drupal site. They did it in a year. It’s a complex site. Now for every single thing it’s taking them forever because everything gets in your way. Because you can’t do anything without following Drupal way. As I said, it’s very good and best choice for simple project. Never ideal choice for large enterprise. If you chose it, you will see what I mean in few years.

    Now what is the best way then? good question. If you have enough resources, go with just a well known easy MVC framework over Drupal. I don’t recommend WordPress either because it’s not MVC or OOP. To tell you the truth, building a site from scratch is not such a difficult thing either as long as you have good expert developers who knows how to architect.

    For those who has limited budget then it becomes a tough choice to pick the right path. Chosing wrong path may cost you fortune down the line.

  38. I also agree with some of the people here. Most drupal developers have very narrow skillset and they can not think outside of the hook system. Which makes them very weak in developing anything other than Drupal. In a way it’s just parallelizing developers. Besides Drupal 8 different than Drupal 7. So you have to learn a lot of new things again. spend a lot of time on learning. In my opinion, it’s for lazy developers who doesn’t want to do creative things. Drupal or WordPress is great. No doubt, but should not be considered for all applications. For larger on going applications, it does more harm than good. Only an experienced visionary developer can foresee the problems running into Drupal sites. I also developed several drupal sites. They are great but when client wants anything everything then Drupal is just a pure nightmare to go with. Those who blindly love drupal, I have no words for them.

  39. For those who love features module you have seen how nightmare it brings when you have a big site. It does have some great benefit. But why do you need that? How difficult to write the code? Why even let a tool generate the code and what are the chances it doesn’t do weird things? Which it happens when you have a bigger complex site.

    Good developer should never rely on any tools that generates automatic codes. Bad choice bad idea. Not only it can break your site it also does things you have no idea at all until you find out six months later.
    Besides, why you have to keep altering everything when you can directly alter the form or code.
    I like the database wrapper. But how big deal is that to write one of your own or grab one from off the shelf what is much easier to use.

    We have been struggling for last two weeks to figure out some weird queries it generated. Because everything is stored in the database we have hardly control over it. We are at a point we can’t roll back.
    Seriously, why you have to store everything in the database if you are a developer. That’s good for novice people who doesn’t know much about programming.

    We are at a point to pull our hairs for choosing Drupal at the first place.

  40. My boss just told us yesterday to scrap our current Drupal site we built for last two years. He says it’s taking us too much time for on going feature additions or fixes. Even though I feel bad throwing out all the work I did for last two years most of our team is kind of happy to do a fresh start from scratch. Fortunately we have a developer who is bright enough to do design from scratch. That’s why we are moving into that direction. Some says, why re-invent the wheel. We aren’t going to re-invent anything at all. Instead of using all Drupal we are just going to utilize all open source generic PHP tools libraries so we have the full freedom. Even though it might actually sounds a lot. But if you put all the pieces together it’s not really much work at all. Because you do not need all the features comes with Drupal or WordPress. It’s designed for everyone and nobody needs everything.
    We were so excited two years ago when we started this site on Drupal. But last one year our over all output turned into less than 50% because we just couldn’t do simple thing in simple ways. Drupal just stepping our foot every way to follow Drupal way.
    On the bright site, no site is permanent. People built site on Drupal 5,6. Those are worst than what you would do alone now a days. So things will always change. You just have to do something good with time/resources available. Most drupal developer don’t see the future changes. They all get very excited how easy it’s to start with it. That’s the main selling point.
    All though I’m hesitated to start fresh with scratch but most of my team member thinks it’s best for all in terms of future growth. I guess when you have resources available you can easily go with brand new strategy over Drupal. I probably would never do fresh start if I was doing all alone. But also agree that it was taking us significantly long time for silly changes to apply lately.

  41. Drupal needs a very steep learning curve. The time you would spend the benefit is far less than that. You don’t really need to be a drupal expert to develop a site. A lot of times it’s a hype but nothing.
    Drupal does not let you do your own data structure.
    It creates hundreds of tables and generates complicated SQL queries. If you get into trouble with your site, it turns into nightmares because of that.
    Everything runs off caching. Which is highly inefficient for development.
    Even though Drupal 8 is taken on OOP , most sites are still on Drupal 7 and it’s all procedure based. Really really bad choice in 2014. You should be doing at least OOP for everything.
    Drupal gets your way on everything.
    You don’t learn anything but Drupal and you don’t grow much outside unless you always want to do Drupal. Because you are going to spend lot of time on doing Drupal way for simple thing that you won’t have time to catch up with rest of the world.
    You may ask, so what’s the solution?
    If you are really doing a small site and not expecting to do lot of development down the line then go ahead with it. Otherwise you should always use some other MVC framework such as Zend, CakePHP or something that will save your time in URL rewriting, ACL, Templating etc. You can also build from scratch if you feel comfortable. You may also ask why reinvent? well there are thousands of benefits building from scratch.
    Yes there are benefits using Drupal. but it’s very slim compared to the work you will end up doing. My personal opinion is, I want to be in charge of my data structure. I don’t want any tool to make it’s own tables and keep joins and then I have hard time fixing any on going issues.
    Yes, you will say this… “oh how come some big companies using it then?”
    Sure, wouldn’t you always go for something you are good at it? it’s always whoever in charge to make decision. It has nothing to do with right or wrong. If you are a Ruby expert you won’t chose Drupal. Would you? and tomorrow if you get hired as a CTO of a company , you would probably aim for Ruby for everything. It’s how it always works.

  42. As someone who decided to initiate a startup prototype using Drupal I can relate to everything you say. Before I chose a method I had a quick look at Drupal’s existing contributed modules and thought it would make my life easy – everything came free and I could harness the brain power of others. Unfortunately, I have spent the equivalent time of doing it myself patching (sometimes huge) bugs and finding workarounds to missing features or clashes. I honestly find it hard to believe anyone has ever built an enterprise scale website using PostgreSQL based on the unresolved bugs I have encountered (overly long db index names among them).

    Drupal is fun and rewarding but it can take a lot of time doing it the Drupal 7 way. Even for a simple content-based website it also feels unethical building a website in Drupal for a budget operation (like a charity) – without an ongoing support agreement they will be shocked at the subsequent quotes for Drupal experts (at least in Australia, compared with WordPress devs). And the scarcity of documentation for the most popular contrib modules and their APIs) was almost hard to believe at first.

    For me the hardest part is abandoning Drupal just when one gets the hang of it.

  43. Having worked with both Drupal and Django, I feel encouraged to express my opinion: Drupal is a great CMS solution. Django is a great framework solution.
    Translated: if you need to build a kind of typical website with lot of articles, posts, pages, groups, comments and even simple e-commerce go with Drupal and just use views, panels, organic groups. If you need highly customised and original functionalities, go with Python-Django and your life becomes much easier, unless you already are a Drupal ninja.
    Thanks for sharing your interesting ideas.

  44. Agreed with Carter here. Drupal is fun and great for things out there to use without envisioning lot of work or maintenance down the line. And this is where it gets very tricky. Hardly anyone thinks that part which makes the very obvious choice to pick Drupal or WordPress based on the flavor. But if you have a complicated site and you want to maintain and keeping adding new things. You will need a Drupal ninja. Which can be far more expensive and time consuming. I have seen Drupal can very difficult to work with sometimes even with simple one line change. Drupal developers are extremely expensive to afford because it’s one of those framework takes a huge amount of time to catchup. Honestly, one can become in PHP OOP in far less time than Drupal 7 which is in my theory and old technology because it’s procedure based.
    At the it doesn’t really matter what platform you use. You can even make it on WordPress or some other platform people suggested here. All it matters whatever is best for you in terms of cost and timeline. Because more or less they all give the same output. Some are easy to start difficult to maintain and some are difficult to start and far easier to maintain. It’s a tough choice for those who don’t think the future outcomes.

  45. huh!! I thought I was the crazy one to dump Drupal. It was so exciting when we started with Drupal and it’s all cool features such as Views, Pathauto, Panelizer. Awesome!! Awesome!! Yay!!!
    As we started building components we realized, these are just doing a lot more damage than good. Because if you are a developer, you should never depend on any GUI query tool. You should have full control over the query and build your own query for complex data structure.
    Drupal will not run fine in commodity hardware. Even though they say it will. It’s it’s all cached. We dumped our two years effort and new building completely using few different open source components and modules. We basically assessed what we need and we might need. We realized we don’t need 100 million CMS features. If fact nobody does. We are now very happy and our development time frame increased three times faster than before.
    So guys, please give a second thought. I also agree with some people here. It’s great for sites don’t need lot of maintenance or on going development. We could have done the same site in 6 months where it took us 2 years. We did everything faster at the beginning like some people here. But then everything slowed down like hell. Specially features module. It’s such a beautiful thing at the same time nightmare. I would rather not even use it.
    Drupal is extremely slow. Whoever says it’s fast it’s just 100% lie. They are saying because drupal cache everything and that’s why it looks like its fast. But if you run on a commodity hardware and have a complex or many rows of data. You are screwed big time.

    1. When developmentseed decided to leave drupal, Alarm bells started ringing.

      One of the best module contributors leaving the platform says something about the platform.

      One obvious reason was because it was so slow without any custom tuning of sql queries. And since everything is stored in the DB, every page needed tuning. That’s reverse development.

  46. I loved views. Then when I had to alter the views. Oh god! it was taking weeks to figure out how to fix or change. These features are awesome if you can use “as is”. Changing? forget about it. You will need Drupal rockstar to make changes that views ui generates for you. Why bother then when changing becomes such a nightmare?
    It made me very lazy in query building and learning processes. I found out I was lacking and going behind in all other areas. I was occupied doing things Drupal way. It seemed Drupal jailed me doing everything Drupal way. Where rest of the world is moving towards OOP. And I’m battling with Drupal. Well, it’s our company foundation. Nothing I can do. I know Drupal very well. It’s just so much time consuming in general for complex view/module development. You get the easy part when you first build the site. Which is what everyone sees. No one thinks what’s coming towards them.

  47. I kind of agree now that I read some of yours opinions. I feel like I am not learning anything new but Drupal. And I can’t upgrade my site to D8 because it’s too complex. Not worth it.
    I regret choosing Drupal. Where we should focus on cutting edge OOP stuff and I am stuck at procedure bases D7 for years. Oh boy!!

  48. Worst part is development time. If you have a heavy site everything becomes slow as hell. If you turn off cache then it’s a pure time hogger. No way around. If you have cache enabled then you won’t see changes immediately. drush clear cache takes long for larger site. Tired of it. Regretting why even picked first place for site like this. I didn’t have any significant issue with my previous smaller sites. But this is kind of a heavy big site. So I do disagree if it’s ready for enterprise. The way I see they push you to use Acquia which is owned by Drupal team. They rely on heavy hardware vs high performance coding. You can always run slow crappy code on a high end machine with faster performance. That’s not really efficient programming. The ideal site should run faster on a commodity hardware.
    I am in Drupal world for 7 years. For this site I even hired professional drupal nerds to optimize. I got slight improvements. But nothing as close as I expected. Now I have a million dollar site with extremely slow performance which is highly dependent on powerful hardwares which is also very expensive.
    What a nightmare…

  49. Remember one thing, every piece of code is disposal. No matter how best you write. The way technology is evolving nothing is set for long term. You aren’t probably going to keep or use the same code you wrote 3 years ago. The end goal is to focus on output with efficiency vs being too paranoid about any framework. If you have done a site in Drupal 5 which is worst than what you can do alone now days. Things always changes. You should always focus on building site with efficient budget, time frame vs completely tied up with any framework. I do personally prefer Drupal. It’s a great framework. But like everyone says, not every framework is for everyone or every project. You always have to judge what is the best route. Just because something is new out there or a lot of people using it does not necessary mean it’s the best choice. If you have a small budget , smaller time frame site with no custom development then you might just use wordpress to save everyone money and time. So it’s all depends.

  50. I was a part of a company who had made the switch to Drupal from a Java based CMS, they all praised the simplicity of Drupal, and as time went by they hired more “Drupal developers” and made more sites. The quality of the sites is so poor that it makes my knees shake. The Drupal devs have zero knowledge of anything else but copypasting code from forums and SO.

    My time at the company made me decide never to work with a Drupal only company again, it was really that bad. And the choice has paid off, big time. Now i work with modern tech, and im surrounded by developers who really have the passion needed for delivering modern solutions that scale and are maintainable.

    So if you are in a similar position i was a couple of years back, and want to grow as a developer take some time to think about your future self.

  51. I loved your Article.

    I have worked for several years with Powerbuilder as the Front-End, pure Java with Apache as as the logic and Oracle as our Database for a big company in big internal projects, usually not web-based projects. We also had some Websites but using Java JSP’s and Servlets. I always found that it was so frustrating to do it he manual way.

    Then I had to leave the company and a friend of mine asked me to do a simple website which had to deal with different types of users searching different types of information and different types of roles of users to get in touch using that information. I thought that Drupal would be the best bet because you have Out of the box all this things that I needed … the first time I installed It I was like: WOoooooow, I just created a view the automatic way: What I just did would have me taken 2 or more days the “old way” because I had to do monually al these SQL Checks and Data Checks … but then the problems began and I could not do this join of data with that join of data, and getting the ID of this Content Type is not possible with that Type of Data, and so simple things began to be sooooooo complicated things.

    I dropped dev. for some month (This was a favor for a friend so no money involved), now I am giving a last chance to Drupal for my friends Website, but Drupal 8 in Alpha Stage (I kind hate now Drupal 7). In only 5 days I did more than in 4 month, maybe because I am more used to Drupal, or because I have the help of a book, I do not really know.

    If Drupal 8 gives me the opportunity to control my data in different tables, I will still give it a try (but I think they keep all kind of data in the same Node Table). …. but chances are that I will go to a framework liken django, but I still didn’t found my perfect solution to what I want.

  52. If you guys really think about it. If you are making a small site then always go with one of the Open Source one either WP or Drupal based on your expertise. But if you go for a big site then I suggest do it your own using the individual pieces. Building a core framework is really easier than most developer thinks. Building your application is tougher. Core application only handles very few basic components which can be found as open source. The benefit is you get full control over it and you can modify it based on your need. So you may lose a month here and there but over all a 9 months project can be done in 5 months. But in Drupal you see huge progress in first 2 months and you will do things in 9 months which can be done in 3 months. I have seen this example numerous times already. Again it’s only if you are doing a complex site with complex database architecture. Not only Drupal is really memory hogger and slow it is extremely inefficient too. But you won’t face these troubles unless you are in a bigger site. Drupal nerds will never disagree because they spend their life on it and they are ninja. So they will come up with a solution and it’s always an expensive one. Drupal developers are expensive too. So it’s always a choice you want to make. I have worked with many large sites and seen good and bad on everything.

    1. Agreed. Platforms like WordPress or Drupal are made for a certain kind of content. Blogs, articles, etc. The problem to me is that people think “CMS” means content management system for every kind of content, when I believe this is not true. If you think about it, almost every website has a primary purpose of content, but there are different models for saving the kind of content there is.

      If you like Drupal out of the box with some plugins then fine. But if you want to make something more than just a blog/magazine then you should consider starting with a good framework (like Laravel, which takes classes off of Syfony and other things).

      I don’t know the Drupal community’s thoughts are and Drupal’s philosophy since I only started to use it a year ago (and hated it), but it seems to want to be the swiss army knife for everything. WordPress stuck to the principal of publishing articles and I think it does that effectively and clearly.

  53. Wow… Going through the comments in this post I couldn’t help to give my positive insight about Drupal !

    Of course everything isn’t perfect in this CMS but it feels that the debate is more about comparing custom code to CMS technologies. Yes, custom code will always be faster and more precise, I don’t know anybody stating the opposite, but Drupal (as others CMS) does not only give code, it also consists of a community which contribute together in the same system. I love to have a bunch of modules at my disposition that I can download analyse, modify, share, etc. I feel very powerful with such a tool !

    Of course the same can be done without it, but each and everyone approach coding in his unique way, personnaly I feel more confortable as an architect that pick the proper tools and customize them to build a project than a developer coding from ground…

    In the end you need to know the tools that suites you, they can be good for some things and bad for others, but debating what is the best way to do the job is just up to the worker, and for that I really think the decision for the author to move away from Drupal is good !

    “How many guitar players do you need to change a light bulb? Everyone, because each will say that he would have done it better ;)”

  54. It’s true that people faces lot of problems when they develop with drupal.

    in my experience the reason is most of times they are trying to build their own architecture and flows in drupal architecture and flows . or in other words trying to play standard chess in Rhombic Chess. if you get a good concept what the real concepts are then you are done. if you what to be good in drupal you must have a drupal brain with a drupal heart.

  55. I think this post is a more a representation of the person posting, than of Drupal. There are many people who claim to be Drupal Experts, but have very little actual understanding of how the framework works (which goes to your first point), your other two points are created out of the first.

    High Development time in relation to what, and with what experience level? Also, with proper project planning and Scrum application this is resolved.

    Custom at a big cost? Again this goes back to your lack of experience and not the platform’s ability to be customized.

    Either way, a carpenter is only as good as his knowledge of the tools he uses. If you know Django better, then you should stick with it. There is no reason or logic that states every site should be Drupal, Django, or etc. Each project should be evaluated on a case by case basis and the best Software Solution should be selected.

  56. Thanks for making me feel better. Drupal is making me nuts.

    I usually use PHP MVC frameworks like Laravel to give projects life. I never worked with Drupal before my current project. With all due respect to the brilliant Drupal developers, I feel like it’s over-engineered. (I know it’s free) I’ve been on it for two weeks, and I am still warming up to the exhausting way the config menu is structured. Making a simple mod, the ‘old-fashioned’ way, to organized, commented, semantic code is much much quicker than stumbling through UI menus or Drupal’s list of modules.

    One last note on semantic code: Drupal, as any other code generator, spits out the longest, ugliest source cod; CSS classes everywhere; Dozens of css/js file includes; Bloat.

    However, I can see how it can be quicker when assembling complex websites, that’s why I’m still on it.. sigh.

    Getting the hang of Drupal is key. Reading their php template files is the way to go. They are well commented and can cue you on Drupal’s inner workings.

  57. I was perusing sites trying to decide how I want to interact with a mezzanine site, and your opinions of your drupal experience has only further reinforced my general dislike of frameworks, period. I understand their use and importance, and maybe it is because my focus is usually trying to push the boundries of equipment and systems into behaving in ways they werent designed, but to me a lot of junior and fresh out of school developers seem to be overly reliant on whichever framework they spent the most time on in school. Does anyone else have an opinion in that regard? I have interviewed 2 PHP developers recently for internships and neither one of them could in any practical way, code from the ground up and especially if a standard use library is available. I am wondering if i expected too much, if I got unlucky, or if they really arent learning much. Would it be considered outrageous to ask a fresh intern to succesfully code a set of functions that will take a paragraph, make it into a multidimensional array of paragraph => sentence => word => letter => value of 2 – 103 based on the letterand return a value at each dimension for its array. Were my expectations too high?

  58. True that. It’s truly a powerful tool. For starter will always feel nuts. But if your job is Drupal and no choice but to use it then it’s just lots of frustration at the beginning. As you learn more and more things will ease up and you will get the hang of it. But it is still a much longer learning curve for a total useless reason. You really no need to spend such a long time to learn something which can be done in much more simpler way. Drupal 7 is not OOP and D8 is not reliable enough to use. If you have to rewrite the entire code base for D7 to D8 then it’s just as good as writing your own cms. I know most would say …”wait … why rebuild the same wheel”. You aren’t going to rebuild the entire Drupal cms. No one needs the whole Drupal cms. Most people needs 10% of the Drupal cms and that’s much simpler and easier to build vs dealing with Drupal way for years. Most Drupal guys don’t see the long term loss,cost and time. Everyone sees how cool it is to quickly put together things. Yes, you can quickly put together things but as you start making more complex site it starts taking time exponentially higher and higher. Drupal makes developer lazy and weak in database. Because you no longer deal with database tables. Drupal’s database structure is horrible. I don’t blame them because it’s designed for dumb user. Not for hard core developers. A good developer would always want to be in control of database. With Drupal everything is a new table and it creates millions of tables with joins. Hence makes a complicated site for simple purpose. Which will force you to spend lot of money to have cutting edge hardwares to have a fast site. If you are blind sided and lazy to touch database then you will not see the benefit of custom cms. Custom cms can be 10 times faster and can be done 3 times faster with only one exception of initial build time. Most Drupal guys find it’s ready to use and deploy. But for long term build and continuos development, it can be the worst way to proceed. Don’t forget a site can be built on any framework or almost any language. The only difference is cost and time. Drupal is the expensive way to do the cheapest thing. Unfortunately most Drupal guys don’t realize that.

  59. We once had a Drupal site with a very complex data structure. It had nearly 300 tables. Which could be done in roughly 30 tables at most. Because everything is through separate table join. Very bad database structure. I still won’t forget how nightmare the “features” module. Why in the earth you would have to so many steps to export a simple thing? Because everything is stored in the database and it checks with physical code. It’s good for dummies. For a good backend developer it’s a nightmare. You are just wasting your time for silly things. It exports 5000 lines of arrays which is impossible to do peer review. You won’t have any idea whether it’s really doing right thing all along. All of these makes sense for an entry level developer or people without programing. If you are a programmer, why would you ever rely on this crappy code generator? If you use VIM/ Terminal then ask yourself why are you even considering using these GUI tools? Because you have no choice. It’s the Drupal way doing simple thing in complex way. You should be designing your own tables. Not rely on a table that has BLOB column for 2 digit characters. Drupal has the worst database table structure. There is no one can deny that. It’s not their fault because that’s the only way they can deliver something for everyone. Which makes is bad for high end sites. I have spend years on Drupal(because of money/job). I have never seen it could do any better than you could have done without it.

  60. Prior to Drupal I used to do lot of cool and exciting projects. After getting into Drupal, all I am doing is Drupal. I like challenging projects. Drupal is a great framework. But sad part is, it’s also very complicated way to do simple things. It is powerful at the cost of simplicity. You will find some stuff you can do easily but at the same it 90 other things you will be doing a lot more complicated ways. Then at some point you become Drupal nerd but nothing. Look at the queries that drupal generates. Ridiculous queries. I have no control over what query I’m running. Prior to Drupal I have worked with many frameworks and custom projects. It’s much easier to build what Drupal intended to do in much simpler way instead of using all these gui stuff. You really do not want to use gui tools for most development work. Some will say it’s saves time. Guess what, you are wrong or you never did other ways. You can say why am I saying negative things then? Well, I like Drupal and it’s a way to make good money because most people are just hyped. So why not? I’m just stating the fact you are paying more time and money for the simple stuff. So if you want to pay why would I take?

  61. Finding good drupal developers are like finding rare gems in grocery store. Because everyone claims they know Drupal but knowing deep drupal take at least few years of good hard core drupal experience. Most people just compares drupal like it’s wordpress. But it’s not. Drupal is not wordpress. Drupal is nearly 100 times more complex in all ways. So you can’t think you know enough drupal by reading few drupal books and watching some youtube videos. And a good drupal developer is also very expensive to afford. A site built on Drupal will always need good drupal expertise. So it’s path of on going high expense. You can build any site on any framework. Everything has it’s limit. Before deciding, first consider the expense and goal. You should avoid Drupal by all means if you are planning to build a high traffic site. I have developed few large site and it’s nearly 3 times more expensive in time/cost to develop one in Drupal vs any other framework on this planet. No doubt drupal is one of best cms framework. But do no underestimate it’s complexity. You have to do every single thing in Drupal way. If your developer is not expert enough he will be spending years on a simple site. I’m not kidding.

  62. I left robust and powerful Drupal for all of the above-explained reasons and don’t regret about that. Drupal is indeed a powerful CMS solution, but not for those who can’t take a full advantage of it. I made the choice in favor of WordPress and don’t regret at all. By the way, I managed to switch from Drupal to WordPress within my coffee break (found an online converter which performs migration with minimal human involvement). If anybody needs it – here’s the tool http://goo.gl/ifUJ7x.

  63. Certainly late to the game here, but fantastic post none the less, especially for sparking this much engagement.

    I am not a developer, so maybe my opinion means nothing I am an SEO, but I first became interested in drupal when I realized all of the free software available and the power of being able to quickly combine them. I stared with 6 as it was much more stable at that time, but 7 is very stable to me now… Creating a site on drupal takes very little time, although I will say the last 10% maybe the hardest, but thats usually because of back and forth from client tweaks.

    For someone like me it couldnt be better and I have not seen any good competitor, especially now that I have been using pantheon for drupal, which perhaps adds lots of hardware and caching like someone above said, but to me thats fine and in most cases better when you take the value from the free software…

    For instance when loading this page, it took very many seconds. Whereas I use ajax for all loading of my drupal pages and it just as fast as anything even with ajax turned off, including the initial page load. I know that this post was intended to say that drupal is not good for developers and has gotta be true when your talking about complicated business logic, but that should be assumed.

    Drupal should be for people like myself, and you hardcore developers concerned with structure and all that should be doing the structure yourself. I think that a lot of the drupal “hate” comes from the fact that us non developers can make a pretty damn good and comparable site, just as fast with barely any code. You guys should be sticking to the hardest projects, like financial software not what most sites out there are…relatively basic!

  64. I have 2 years experience with Ruby On Rails development (24/7) and very satisfied how it is easy to work, BUT also some simple request can be irritated and frustrated than to do same things in PHP. Because of that give up and back to PHP. Also need to say that 2 years in RoR world helps me to write better PHP code. About CMS need to say few things about Joomla (wait!). Joomla is ok – if you use your custom coding (write components, plugins and modules)- because for Joomla best thing is MVC pattern. Also no one talk about Process Wire, maybe currently the best CMS in the CMS world – only problem is that you need to spend few days to choose concept (admin concept, files/folder structure) – how to do something because there is almost unlimited options to do same things (most flexible CMS what I try after Drupal, WordPress, Joomla…). Remember Processwire.


  65. Varun, you have raised an absolutely valid issue, and I found this 2 year old blog post and the comments here very thought-provoking.

    Yes, Drupal is primarily built for publishers and there is a lot of complexity under the hood which is sometimes not well documented. So if you want to do custom things you are probably in for a rough time.

    I am beginning a new project which will need several custom features. This blog post prompted me to do some soul-searching about whether Drupal is the right choice. After some reflection, I do think it makes sense for me to go with Drupal for the following reasons –

    (1) There is a saying – “Jack of all trades, but Master of none”. If you want to be a Master of one tool, then, as a previous commenter mentioned, it should be a “Swiss Army Knife”, which you can use to do lots of things. Drupal, with its huge collection of contributed modules is the “Swiss Army Knife”. The caveat about being in for a rough time when you want to do anything out-of-the-way does apply. But if you put in the time and effort to become a “Ninja” then you can do the custom things and also have at your disposal a tool that gives you a wide variety of capabilities out-of-the-box.

    (2) If I wanted to build say a discussion forum with various special features, and if I had to start with a bare-bones framework, I would be quite lost. However, with Drupal, you can reverse-engineer the Advanced Forum module (and associated modules), and that gives you a strong base which you can build on or modify. The same point can apply to other custom features – the wide variety of contributed modules is an asset even if they may not meet your needs out-of-the-box.

    (3) Also, implementing the complex and useful Entity & Fields infrastructure, starting from scratch in a bare-bones framework, would be pretty much impossible. You do need the capabilities Drupal provides. Even in the case of Views: Yes, it may be easier to build your own SQL queries – but Views does make it easy to do things like making blocks, adding pagers, styling the tables etc.

    (4) Also, with the Symfony framework, Drupal is becoming architecturally clean and elegant.

    (5) Many people complain about Drupal’s performance. You can already to a lot with the PHP Opcache, the Memcache module, Varnish caching reverse-proxy, Edge-Side Includes, and the JS Module (which gives responses without going through full bootstrap). Maybe, in future versions of Drupal, the REST API may not require full bootstrap. Coming up on the horizon is the HipHop Virtual Machine (HHVM). Some people have already got Drupal to run on the HHVM. So things do seem to be moving in the right direction as far as performance is concerned.

    For all these reasons, it seems that there are good reasons to choose Drupal, even while acknowledging the valid concerns raised here.

  66. Just because it takes you extra long to do things with Drupal doesn’t warrant this post, there are plenty of amazing things you can do much faster it’s just choosing the right tool for the job

  67. I’m curious why you call Symfony a dying MVC framework. Symfony is observed to be growing rather than dying and it doesn’t say it’s based on the MVC pattern. MVC is a specific pattern. Do you mean MVC or separation or concerns? In either case, I’ve used Symfony or parts of it in ver non-MVC setups. http://uhchat.net/

  68. I am an expert in drupal, it’s easy for me so I do not feel very happy arrival of drupal 8 also know django and I think also good, yeah a lot easier.

  69. Just because it takes you extra long to do things with Drupal doesn’t warrant this post, there are plenty of amazing things you can do much faster it’s just choosing the right tool for the job. biking vietnam

  70. I had the exact same feeling about Drupal. PHP itself was not really bad, I’ve initally worked with a custom made MVC framework written in PHP and felt quite good but then when I started using Drupal I started to really dislike my job. Yes, doing custom thins can be a pain in the butt. I’ve struggled pretty much even to make a custom styling, not to mention that creating a form is horror from all point of views.

    After about 6 months I decided to change my job and switched to Java, I am very happy now. :)

    1. A lot of people had that same feeling of drupal including myself, I am of the philosophy of “keep things simple” and with my experience I can tell that a lot can be done witouth going through that suffering unless is required by a well paid job.
      I strongly recommend use simplier cms to do your proyects, that can save you a lot of time in the future.

  71. Can’t a site, that may grow rapidly, use both approaches? Build the search, display, login, form pages, etc without CMS, old school of you will. And the content pages, blogs, contact us, advertise, etc pages use a CMS? That way staff can manage them. I’m about to have such a site built, and thinking on this approach for a custom real estate site. I’m not crazy about the hard core pages being built in a CMS system.

    1. Valid point! Would love to see reference architectures that make the most of the CMS for parts its good at and write custom non-CMS functionality for things its not good at.

  72. For quite a while, for each new project I wrestled with the decision whether to employ Drupal or custom code. After my first successful Drupal deployment I became biased toward the CMS approach. But after completing a custom project using PHP and Laravel framework my bias shifted. Now for most new projects, I find that leveraging prior Laravel applications gets me to production faster than leveraging the vast Drupal platform. I certainly find advantages to forward development over “reverse development”.

  73. Drupal, in my opinion, is “software engineering” evolved – what Dries referred to as “Assembled Web” few years back.

    In the industrialized mechanical engineering world, rarely does any automaker start making a new car from freshly mined iron ore. Over the centuries, Mechanical Engineers have collaborated and evolved standards – about dimensions of nuts, bolts, sheets, etc. Making it possible to walk into a hardware store, purchase what you need and assemble it all together.

    Needless to say, any automobile can be made even more performant by bespoke design/manufacturing of every single nut/bolt or component that goes into the automobile. But today’s auto industry does not bother with the path of bespoke design of each single nut/bolt.
    It accepts a certain “overhead of industrialization” as a given hypothesis.

    Unfortunately, the world of “software engineering” is still nascent. Even today, building “custom bespoke web applications” usually involves a long two-year customer-paid project that starts by writing the “event log class” in Java for the n-th time in developer’s career. It is no different than starting with iron ore.

    In the relatively industrialized world of Drupal, the whole idea is – to create your desired Web app by assembling standard components available from the Drupal.org community’s free component store. You have over 25,000 such components to choose from. Yes- many of the components may have “unnecessary overhead” – but it hardly matters to the cheap LAMP server’s compute power.

    The Drupal community is evolving and not perfect. There are many idiosyncrasies in the world of Drupal. But the fact is – there is no other bigger open source community that offers similar huge component store that is ready for assembly.

    The underlying ethos of Drupal community’s “assemble your web application” approach is – build web apps by assembling community components – make minimum tweaks to the existing components. This requires the developer to have the right expertise, understanding of Drupal’s hook system and how to correctly tweak a community module’s behavior without changing its code. The instincts of from-the-scratch Php developer is to trace from “index.php” of Drupal and try to figure out the 200-odd database tables. Good Drupal developers are least bothered about the volume of underlying database tables – they follow the Drupal best practices.

    Post-assembly, a Web app built using Drupal can be made highly performant by using Opcache, Memcache, Varnish, etc. Drupal expertise is required here as well.

    A performant Web app built using Drupal maybe acceptable to some. For some others, it may not meet their needs.

    In my experience, for enterprise sites built using Drupal – over 98% of total code is community code and only 1~2% is custom coded.

    IMHO, building Web apps using Drupal certainly requires team to have previous Drupal experience and precise knowledge of the modules of Drupal community. Trial & error approach may be extremely time consuming as you found for yourself.

    In my opinion, Django and Drupal can not be compared. Django can be used to create a Drupal like CMS.

    Long story short – “it all depends on what you want” : total control on all aspects of web app or quick assembled web app.

    If you are looking for total control – then certainly Drupal is not a good choice. If you are looking for quickly assembling together a lot of web functionality (close to your MVP goals) without writing much custom code then Drupal maybe an option.

    I hope this helps someone wondering whether or not to use Drupal for their next project :)

  74. I always wondered why I always ended up slagging off every CMS I’ve ever used (even one’s I’ve developed from scratch). I only realised a few days after reading your article, and almost quitting Drupal 2 days ago.

    My conclusion: In essence ALL frameworks / CMS’s are crap, but also good!

    How well you perceive a certain framework / CMS will depend on:
    1. How well it fits what you are working on (if the plugins you need to use are available on that CMS / framework, and you don’t need to modify the framework much, you’ll be happy as Larry)
    2. How good the community is, and how you bond with that community (I initially approached Drupal in quite a critical manner, and didn’t get such a great response. So I tried to improve my approach by getting more involved and helping others… I now have a more positive attitude towards Drupal and people are helping me a lot more… koding karma perhaps).
    3. How well your brain and personality fit with the framework (If you build you’re own framework, it’s 100% obvious to you, so might seem amazing… but it probably isn’t. I find Drupal module development fits my brain a lot more than WordPress plugin development… but that isn’t because WordPress is probably any harder)
    4. How mature the framework is. Drupal 8 is what I started on a month ago… I’m guessing previous version weren’t as good
    5. Bloat versus streamline… I used Perch CMS recently, and it is extremely lightweight… Drupal is heavyweight. It’s important to pick the right framework for the job! If you pick a particle accelerator to crack a walnut, then don’t complain if it seems complicated to do! 😉

    I think this list could go on, but that’s my main input so far. I think Drupal is both amazing and crap depending how you use it, who you are, and how well it fits your project. I tried django and hated it. However if I’m being objective, I’ll admit it seemed lightweight and powerful and well designed… it just didn’t fit my way of doing things.

    Think of it like this, you can Google ‘whatever framework’ and either the terms ‘is crap’ or ‘is amazing’ and you’ll find articles giving both sides of all frameworks. This proves it’s a lot like music taste… some people will love The Beatles, and other people will think they are crap. OK bad example… but I hope some of what I said makes sense!

Leave a Reply

Your email address will not be published. Required fields are marked *