7 ms·
Why we stopped using Drupal for our platform
- gee_totes 14y ago> Drupal has partnered with the Symfony (a dying PHP MVC framework) Is Symfony dying? With Symfony 2, I thought it's components are becoming more and more popular.
- eropple 14y agoIt's not, and Symfony2, along with Laravel (which also uses Symfony2 components), is probably the only reason I would consider new PHP development these days.
- Kiro 14y agoWhat's so good about it? Looks like any other MVC framework to me.
- blowski 14y agoIt takes advantage of PHP 5.3 (anonymous callback functions, namespacing, etc) whereas a lot of the other PHP frameworks feel like PHP 4+. You can swap in components like Redis easily. Setting it to use mock versions of web-based APIs in the development environment. And the code just feels nice to work with.
- newbie12 14y agoAlso has a nice Dependency Injection pattern, and the Twig template system is wonderful.
- eropple 14y agoYes, that's sort of the point. It looks like the MVC frameworks you'll see in Python and Ruby, with allowances for and enhancements where they make sense with PHP as a language. I would call Symfony2 "PHP for adults".
- mars 14y agoyou might wanna check out http://www.yeager.cm http://www.yeager.cm if you are searching for a slick and easy to extend php (5.3) cms. disclaimer: i'm one of the devs/founders.
- tunesmith 14y agoMaybe it was phrased that way because Symfony 1.x is dying, since Symfony 2.x is not backwards compatible.
- tomcorrigan 14y agoBut Drupal is using symfony2 components, so it doesn't make sense either way.
- level09 14y agoI don't think symfony is dying, however, bridging the two systems might produce a mess. but we better wait and see.
- newbie12 14y agoSymfony2 is excellent and is growing in terms of usage, conferences, and so on. The framework actually borrows best practices from Django, Ruby, and Java. The false description of Symfony2 as "dying" makes me wonder how much the original author actually understands the landscape.
- 2pointsomone 14y agoTook the "dying" part back. Apologies!
- relaxatorium 14y agoUsing Drupal as an app platform is a definitely trying to solve the problem with the wrong tool. My experience with this kind of thing is that these tools are flexible enough that people can stretch them beyond their intended purposes, but it's usually rougher than just finding the appropriate tool. Specifically designed blogging engines become general purpose CMSes when people stretch and tweak them enough, and likewise people stretch CMSes into crude app frameworks, but you generally wind up fighting the tool about as much as building with it.
- rajeevk 14y agoI guess, every CMS has same problem. Either you build from scratch or use one of the CMS. For quickly setting up a web site Drupal/Wordpress is good option. There are plenty of cases, you would not want to write from scratch. For example, I am running my website on Drupal(http://www.avabodh.com http://www.avabodh.com) without writing any code. I do not have time to write code for my website. My requirements are very simple. It will be waste of time if write CMS from scratch for my purpose. I dont think there exists a good replacement of Drupal today.
- nnq 14y ago> I dont think there exists a good replacement of Drupal today How about WordPress + plugins + some custom code in a little plugin? (much less work than for Drupal and you can implement what you want by ignoring 90% of WP's functionality and "ugly" code base - that is not poetry, btw, for those who get the joke :) ) You can even use a lightweight MVC framework of your choice inside your plugin if you figure out how to stitch things together and avoid some undocumented pitfalls...
- elchief 14y agoI switched to Wordpress when I realized that Drupal's Link Field Module (a plugin to add a hyperlink field to an entity) was 1100 lines of code. http://drupal.org/project/link http://drupal.org/project/link
- level09 14y agoare these 1100 lines of code executed everytime you render a link field ?
- vog 14y agoAlthough this might be a performance issue as well, I think the real problem is that some unlucky people had to write those 1100 lines of code in the first place.
- level09 14y agosize of code != performance problem in most cases, plus drupal give you an extremely lightweight api method "url() or l()" to render links, its up to you to choose .
- ceejayoz 14y agoIf you take a look at the code, most of that's dealing with the backend UI, comments, and stuff broken into multiple lines for readability. Bashing based on LOC is as moronic as the old practice of LOC as a performance metric.
- lorin_pa 14y agoHi, This a great example of a broader issue. The statement "I switched to Wordpress when I realized that Drupal's Link Field Module (a plugin to add a hyperlink field to an entity) was 1100 lines of code." contains no logical context. Most Drupal developers are not programmers. For example, a Drupal developer may be graphic's designer. Drupal allows end users to define ad-hock data types. That's what "Drupal's Link Field Module" is (a part of). Ad-hock data types are an option, not a requirement. If an end user wants to define an ad-hock data type with a "link", they install and configure "field modules". That's a limitation of being an "end user" (as opposed to being an application programmer). A application programmer would look at Drupal's source code and see there is succinct API method to create a link. So the broader issue is, you have folks with little to no programming experience making application programming decisions :) It's just as likely, the poster's project did not require ad-hock data types. Without any type of requirements analysis, the project fails. Drupal's popularity (at least among CMS's) is due to it's set of logical features. It's not the technical implementation of the features :) The downfall of most Drupal projects is due to poor resource choices. You hire a graphic's designer to implement an inventory system, you are going to get the same results no matter what CMS, frame work, programming language etc :) Sorry, didn't mean to pick on anyone. Without an elaboration, you speculate based on you experience :) That's my experience with Drupal development :) Lots of talented folks asked to do the wrong job :)
- neya 14y agoHere's my experience on this one: Actually, it's about using the wrong tool for the wrong purpose. I tried building a custom CMS with both Drupal AND Wordpress, just like the author and I realized how horrible it is build something custom out of an existing CMS. I wanted to build a Metro-like interface for a shopping cart application with some extra functionality, just using Wordpress. Should be easy and was easy, until I discovered some horrible stuff within the code. You would think that Wordpress being so popular, would be top-notch as a development platform too. It was for the most part, but there were some trivial issues that made me develop a sense of hatred for developing for it. No, I'm not talking about themes, I'm talking about building off something different using Wordpress as a base platform. For example, on Wordpress, for pagination on posts, the GET variable is 'page' and for pages it is 'paged'. There is absolutely zero documentation on this and no reason as to why they have different (inconsistency) names for the same functionality. This is just one example. There were lots of other annoying bugs that pushed me too far. For example, sometimes, updating Wordpress would break a lot of plugins and leave you stranded. Does this mean Wordpress is bad? No certainly not. It's the best blogging platform out there. But, if you want something custom, just build it yourself. That's why I said 'fuck it' and moved on with rails. I get what I want, nothing more, nothing less. If I want an authentication system, there's Devise, if I want something else, there's always a gem for that, let alone writing my own code for the functionality I want isn't a big deal either. In short, if you are building your start-up based off on an existing CMS, you're doing it wrong. Unless you are focused only on developing themes and frameworks for these platforms, or if you just want to run a Media company like Techcrunch or Mashable, just don't go with it.
- hayksaakian 14y agoYeah, the only really good situation where you'd want a CMS rather than building something yourself is if the technology is not the product.
- Rustan 14y agoExactly. Most businesses built around Drupal as a technolgy are consultancies.
- 14y ago
- ishener 14y agoFor me, drupal is still saving lots of time in development. If you (or your client) thinks he knows EXACTLY what he wants, than do it from scratch and expect to invest much more time (money). But I have come across enough clients that were pragmatic, and were able to understand that changing built-in feature X to make it a little different is not that crucial. They were able to live with the limitations imposed by built-in systems because they knew it saves a lot of money, and ultimately - these things are not the things that determine if a project succeeds or fails! In the real world of limited time and money, drupal is indispensable.
- ahyes 14y agoDrupal is great if you have a 10gigabit link between your web & database servers.
- level09 14y agoYes Drupal is not for creating custom apps, but it is not really that bad, for specific systems (ex: where you have anonymous traffic) or publishing systems, Drupal really excels. the huge amount of queries (200+) executed on each request can be easily cached and scaled using a bunch of layers (APC,static files, varnish) and it scales very well. on the other hand, if you try to build the CMS features you get (out of the box) in other framework like Django or rails, it will take you really a longer period of time.
- donw 14y agoI can speak from some experience here, as a few years ago I led a team in moving a client's custom-built application off of Drupal. You could probably set up a blog and a storefront easily within a day, and then hand that off to a non-technical client with a very limited budget. Outside of that use case, you're better off using something else, for several reasons: Configuration is entirely stored in the database, which means setting up multiple environments for testing changes is effectively impossible. You also have no real way to use source control to track changes in your configuration. The Drupal database schema is surprisingly hard to extract data out of, which means transitioning to another CMS, or to a custom-written app, is also very difficult. Bugs are nasty, many, and often undocumented. In our case, we got bitten by a nasty bug regarding null fields when exporting XML -- it simply kept the last non-null value. Which was pretty problematic when that altered the nature of purchased items for thousands of customers (that was fun to fix). This also makes transitioning data very difficult. Drupal module behavior is highly non-deterministic; you can add hooks in to, say, modify SQL queries before they get to the database, with no logging or other indication that this is happening. Debugging interactions between modules is very unpleasant. There is no backwards compatibility between releases, which makes upgrading incredibly painful, especially if you depend on custom modules.
- fungi 14y ago> Configuration is entirely stored in the database that is generally what the features module is used for http://drupal.org/project/features http://drupal.org/project/features > which makes upgrading incredibly painful yup, this is a real problem with small community sites that drupal is other wiser awesome for. the work involved can be rather arduous (and impossible if you are using a module that lacks an upgrade path). that said, the drupal community is huge and in my 8+ years of building and running sites i have always been able to work out an upgrade solution, finding the time to implement it is the bigger problem.
- ddellacosta 14y agoI was a Drupal developer for a year or so. That was at the end of my stint as a PHP developer, and presaged the end of my use of PHP as a language, and my introduction to the larger world of software engineering. Thinking about it now, I'm really not sure what Drupal is good for. All in all it is a pain-in-the-ass to work with. Having switched to Rails after that (and please don't get me wrong, I'm not trying to insist that Rails is the be-all-end-all, but for the sake of comparison...), I know now that the same amount of development time in Rails can yield far greater results, despite the fact that you can essentially build functionality through a GUI in Drupal--a GUI which is as incomprehensible as the codebase is. This is something the author of this piece acknowledges when he talks about trying to customize Drupal. This has to do with two things, I feel. One is that, fundamentally, Ruby is a more expressive language than PHP, and you can accomplish a lot more with less code. I say this not to start a language war but simply because I think it is true--the same way I feel that Lisp is more expressive than Ruby by a significant factor. The second, and much more significant reason, is that Drupal doesn't have any sort of sane architecture to let you safely plug in modular code. You are essentially hot-loading code into arbitrary points within the system. Frankly, it suffers from the same problem a lot of PHP apps do (and more Ruby and Python apps than many of us would care to admit) which is that it's people re-inventing the wheel from the ground up, all over again, poorly. The fact that they are now talking to the Symfony guys about putting some of those ideas in place suggest to me that someone on the Drupal team finally realized MVC exists. I have this vision of someone in the PHP community at some point randomly picking up the Gang of Four book and being like "holy shit, check this out people...they had a solution to some similar problems 20 years ago..." I'm joking a bit...but after years and years doing web development, I only finally realized the whole world of software engineering that was out there, and how out of the loop I truly was (and still am). Many developers exist in a little bubble consisting only of their language or worse, their platform. The Javascript folks, Rubyists and Pythonistas (fill in your favorite language/platform here I suppose) can all suffer from this. Point being, any of us who consider ourselves "software engineers" should be constantly reviewing our own skill set, and while we should certainly be refining our skills in our particular language(s) and toolsets of choice, we should also be constantly reviewing other languages and ways of thinking about architecting software for guidance, inspiration, and to combat our own tendencies towards small-mindedness. We should be refining our knowledge of algorithms and comp sci fundamentals if we are lacking (as many web developers are, especially self-taught ones). After all, "those who don't know history are destined to repeat it." This is just as true--if not moreso--in software engineering as it is in any other discipline or domain.
- bobsy 14y agoThere are lots of Drupal developers around. Why not hire one instead of training people from scratch? If your job involves something new like Drupal then you get on and learn it, there are plenty of resources around. Perhaps novice Drupal developers are the problem. Note, I do not like working with Drupal but I have seen some really impressive things done with it. The author says Symfony is dying. The opposite is true. Symphony2 and it's components are becoming more popular and are being used in other frameworks like Laravel. If you are following php into 5.4 at the very least you will know about symfony. You will probably be using some components of it.
- blindhippo 14y agoTrouble with hiring "drupal developers" is that they are more then likely NOT developers. They are people with no engineering training who learned how to configure drupal sites and plug some hacked solutions into less then optimal places in the code. People with proper development pedigree tend to sneer at the Drupal platform, and with good reason. This makes hiring incredibly difficult.
- 2pointsomone 14y agoTook the "dying" part back. Apologies!
- thejosh 14y agoI have been developing PHP applications commercially since the start of 2008, using Symfony1 then Symfony2. My current job is using Drupal 7 for the past year or so, and I have found it to be the biggest clusterfuck I have ever dealt with. Very steep learning curve, horrible admin interface (currently designing a new one for our clients), horrible bootstrap time. There are a few saving graces for Drupal 7 such as Drush that make developing a bit easier... but I see Drupal 7 as a CMF as a horrible decision for almost any webapp/intranet app/anything.
- rorrr 14y agoI've been developing PHP for many years, and the best frameworks are always the lightweight ones. Good Drupal developers, who actually understand the framework, are rare. If you can hire one, finding a second one of the same level is like winning a lottery. When I worked on a fairly large Drupal website our Drupal devs would disagree on how to develop some pretty straightforward things. It's a huge clusterfuck of a framework.
- blindhippo 14y agoAs a "good drupal developer" (I hope!) I can back this statement up big time. My company has 2 developers who know Drupal fairly well but we need to scale up to 4-6 developers at our skill level. They simply do not exist. We get loads of useless "site builders" applying or your prototypical PHP Developer (seperation of layers? why?). Very, very hard to find competent people who are willing to work with Drupal. If you're just starting out and are shopping for a development platform, stay away from Drupal. You'll take more time to develop your MVP, but in the long run you'll save a huge amount of time and money.
- level09 14y agoI have been developing web systems since 2000, I believe I have made at least $150k out of developing Drupal websites, most my clients are small to mid-size companies who only use a few pages and have a few hundred visits/day. hence, I think it is a pretty good system.
- nnq 14y agoDupal's advantage (imho), or the advantage of being exposed to it is that everything, Rails, Django, Pylons etc. seems "easy" and like a breath of fresh air compared to it, even if you are learning another language, like Ruby or Python, at the same time with learning the framework! ...really, the only other piece of software that I've worked with and has this extraordinary "quality" was Magento (I know, they are at different extremes of "nightmare", and I hope I'm not offending anyone with the comparison)!
- edtechdev 14y agoIn cases where I've seen sites switch from Drupal to a custom-built ruby solution, the end result had less features (or were missing crucial features and user interface details that are trivial to enable in drupal), and they had more problems and bugs (and I would guess, have more security issues). Also, some of the reasons I saw posted for switching are not true, at least not anymore. For example, there are tools that allow for version control and collaborative development on drupal sites now. examples: p2pu, mozilla drumbeat, cloudworks http://cloudworks.ac.uk/ http://cloudworks.ac.uk/ which were all originally drupal sites On cloudworks, it forgets that I'm logged in everytime now. And it can't link together and display connected posts and people as easily as you can in Drupal, it can't email you updates and activity you've subscribed to, the site isn't mobile friendly (and think how easy it is to convert a site to be mobile friendly now in drupal & wordpress), the links are ugly and not seo or user friendly, etc. The site went down several times last month.
- abhaga 14y agoOne of the biggest problems in building something on top of Drupal is the 2 year cycle of major releases with no backward compatibility. That means you will need to port all your custom code every 2 years. Combine that with the fact that many crucial modules are actually not part of the core distribution and are often not ported for months/years. Some less popular ones are even abandoned with new alternatives coming up. We went through that process of upgrading from D5 to D6 but simply gave up at the D6 - D7 transition.
- analog 14y agoIn my experience the work involved in porting your site to the next version is equivalent to the work involved in just rebuilding from scratch. And this is something you have to do every 2 years if you want to be able to use any of the latest developments in web technology. It's the big dirty secret of working with a monolithic stack imo.
- rcirka 14y agoDrupal has it purposes, however I wouldn't use it for anything custom. I have a friend that runs a small web site business (mom & pop shop). He makes most of the sites in drupal, his primary customers are very small businesses. In this case drupal is perfect for him, he can have a site up and running in an afternoon with an amazing amount of features. Of course, when he ever calls me to do any custom modification, I cring.
- edwardunknown 14y agoI always end up going back to Drupal. Sure you need to be an astro physicist to be able to get Views and Panels to work with a jQuery version from this century but where else can you build a fully functional social network with Solr based indexing and tagging in two hours? Rails? I think not. It took the Diaspora guys a year to build something that could have been done in weeks in Drupal with pre existing modules that can be turned on and off with a checkbox. I admit she is treacherous as the sea and I swear off her regularly, but she's still my go-too gal when I have a dumb idea for a multi user site that I want to get working before lunch.
- virtualwhys 14y agoWordpress front end provides the CMS and Bling; proxy custom requests (crud, shopcart, etc.) to framework of your choice on the back end -- powerful combo. A friend of mine has made a killing on Drupal development over the years. When asked to help out on a couple of projects digging into underlying code to solve some square peg/round hole problems that he could not manage at the GUI level -- after one small project, I declined further requests; it was truly painful. PHP itself is of course a nightmare language (spent 6 years slogging through that mud) compared to Ruby, Python, Scala, etc., and Drupal's function-based hook system brings no joy, more drudgery really. Saying that, it seems that in addition to drush> there's an implicit drudge> that takes affect when working under the hood in Drupal...
- vladady 14y agoWhat solutions do you recommend? I tried Symfony2. Performance wise it's slower than Drupal. What do you recommend using for medium/large apps in PHP? Do you think you can be more productive in another language? For example do you think you can be more productive in Django?
- orangethirty 14y agoStrange. Symfony2 should definitely be faster than Drupal. Were you running a lot of SQL statements between requests? In terms of recommending a framework, it really depends on what feature set you want. Do you need a very minimal set of features, or do you want it to be very featured? Django is great for building CMS. If you have the option, try it out.
- blindhippo 14y agoThe author missed a critical reason to stay away from Drupal. Testing. It's basically impossible to do proper unit testing in Drupal. A unit test is a core requirement to doing test driven development and to do it properly that test needs to be run quickly and efficiently. There is no way to do that in Drupal as their testing framework requires a minimum of 1 minute per test. As a developer working with drupal, I feel completely trapped by this atrocious platform. I worry that the longer I work with it, the more at risk my career becomes - not a pleasant feeling.
- 2pointsomone 14y agoTrue, that. There is actually a number of things I left out for the purposes of brevity, but thanks for pointing it out.
- nolanguage 14y agoAs a Drupal dev of several years, my team recently started working on a rebuild of our sites (magazines/blogs) in a custom node.js framework. I appreciate certain notions embedded in Drupal, still: abstracting away technical requirements, flexible data models (content types), huge number of pre-existing modules that cover a tremendous range of cases. Still I found the modules mostly served as guides to create our own custom solutions, and less as plug-in-play options. I was really able to build some good functionality, abstract enough for the core elements to be shared between 6 websites, with superficial theme-level changes for each. That said, anything awesomely written performed so abysmally that the great work really felt like it was a waste in the end. In that sense, Drupal strikes me as a true dead-end. The basic heart of the app, and elements of the philosophy make a beast that is bad for anybody with skill who wants to feel good about what they've done. Other criticisms would be the excessive integration of administrative-type functionality with end-user functionality; an almost incomprehensible (Fields) system for building custom data extensions; and the big one for so many here, the tight-coupling of the database with the code everywhere, which is part of what makes it so slow and a nightmare to develop with. As to job security; I suppose I have that, and I often get offers to work on Drupal projects beside my main employment, but I find the work so lacking in joy that I need to charge punitive hourly rates. For a certain type of project I'd definitely choose Drupal over Wordpress. Still, I wish there was some middle-ground. A more performant CMS, ready-to-go for small-to-medium size vanity or content projects, that doesn't make the insane compromises Drupal does to be "user-friendly" (read: code-averse).
- lsmith77 14y agothis is exactly the kind of scenario we aee trying to address with the Symfony2 CMF: cmf.symfony.com
- nonamegiven 14y agoWhat is it about the site (varunarora.com) that causes the text to shimmer in a visually painful way when scrolling? [FF on Lubuntu]
- 2pointsomone 14y agoThat's weird. Themed on FF on Ubuntu. I will look into it and try to fix it. Thanks!
- bsenftner 14y agoI saw this over-engineering coming in the transition from Drupal 6 to Drupal 7, and as such I held my company on Drupal 6. Drupal 6 is a significantly slimmed down environment, which can be used like a scaffold to build custom apps. There is not a hell of a lot there, so the complexity is minimized. But it's still not testable, and still pretty opaque for debugging purposes. I'm moving off Drupal, to the "Doh" framework that hosts other frameworks, and you define the interface you want to the "other" frameworks, forcing the logic pattern you want to use upon frameworks that may not support it.