
Why we stopped using Drupal for our platform - 2pointsomone
http://blog.varunarora.com/2013/why-we-stopped-using-drupal-for-our-platform/
======
neya
Here'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
Yeah, 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
Exactly. Most businesses built around Drupal as a technolgy are consultancies.

------
relaxatorium
Using 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.

------
thejosh
I 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.

~~~
level09
I 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.

~~~
hilko
This is an honest question: if it's mostly a bunch of pages, wouldn't setting
up a baseline Ruby on Rails (or similar) site, or using a Ruby on Rails CMS
(Locomotive, etc.) be more cost-effective and faster? At worst, you spend a
day setting up the basic system that you can then just copy for every new
project.

I've long used Drupal, building sites ranging from full-blown content
providers to the kinds of sites you speak of, but I still find that setting
things up, even when 'copying', and clicking around the interface, and so on,
take more time than just copying a base rails app and changing some lines of
config and code, or branching an existing project at a point where it has
most/all the features I need.

I might still use Drupal, and I've invested considerable amount of time in
understanding it, so I'd really like to know the best reasons why I still
would.

~~~
thejosh
Thing is that most clients want PHP because it runs on everything. They can
take their entire site, package up the code + database and move it pretty much
anywhere.

~~~
level09
that is actually one good point, I find deploying PHP systems a lot easier
than python ones (ex Django)

no need to write any services/complex deployment scripts, just push the files
and your website is updated ..

~~~
thejosh
We host client websites, however sometimes a client may want to take their
website and go elsewhere, so it's easier for them to not worry about where
their site can run as pretty much any admin can get PHP working.

Sure I would love to expand work into other languages, but for the short term
it's PHP (symfony2/drupal) for us. :-(

------
ishener
For 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.

------
gee_totes
> 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
It'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
What's so good about it? Looks like any other MVC framework to me.

~~~
blowski
It 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
Also has a nice Dependency Injection pattern, and the Twig template system is
wonderful.

------
abhaga
One 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
In 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.

------
edtechdev
In 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/> 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.

------
bobsy
There 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
Trouble 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.

------
level09
Yes 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
I 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
> Configuration is entirely stored in the database

that is generally what the features module is used for
<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.

~~~
hilko
Last I used it, there was still too much that the Features module didn't
'cover', making it less useful and sometimes even counter-productive for me.
Has this improved greatly in the past year?

~~~
mfer
Configuration management can be a real issue. For Drupal 8 there is the
Configuration Management Initiative meant to solve just this problem. It will
be there in Drupal 8.

Features has some very rough edges. It's a bolt on after the fact solution.
Through it Drupal developers learned about the rough edges, what people want
here, and so forth. What comes in Drupal 8 is meant to be a proper solution at
the core from experience.

~~~
hilko
Yeah, I read about that. Could definitely influence my choice of framework/CMS
down the line!

------
nnq
Dupal'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)!

------
nolanguage
As 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).

------
virtualwhys
Wordpress 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...

------
bsenftner
I 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.

------
rajeevk
I 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>) 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
> 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...

------
blindhippo
The 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
True, that. There is actually a number of things I left out for the purposes
of brevity, but thanks for pointing it out.

------
ddellacosta
I 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.

~~~
mylittlepony
These stupid generalizations about PHP devs have to end some day, right?
Symfony2 (as example) is a piece of software that is probably light years away
from anything you have done in software engineering. And its community is way
better both in knowledge and openness than the Rails one (I've been a Rails
dev too, and have my own rants to make, but I don't go around saying Ruby devs
are all noobs) IMO. Yet here you are, making generalizations based on having
written code in plain php, working in a piece of software that I don't even
know when it was created, but I guess it was here before we even started
programming.

And for the sweet downvotes, I'll just drop this here:

Tell me more about how you read the GoF book, and applied the patterns in a
language that does not even have interfaces or type-hinting. What a joke. On a
recent article, another "Ruby expert" (who writes and sells programming books)
was shocked by the fact that you can reuse code with inheritance. You should
read it.

~~~
strlen
_> Tell me more about how you read the GoF book, and applied the patterns in a
language that does not even have interfaces or type-hinting._

<tongue in cheek>

If you're interested in examples of GoF patterns implemented in a language
without typehints or interfaces, I highly suggest getting ... the GoF book --
it has examples in Smalltalk!

</tongue in cheek>

------
rcirka
Drupal 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.

------
vladady
What 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
Strange. 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.

------
elchief
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.

<http://drupal.org/project/link>

~~~
level09
are these 1100 lines of code executed everytime you render a link field ?

~~~
vog
Although 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
size 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 .

------
nonamegiven
What is it about the site (varunarora.com) that causes the text to shimmer in
a visually painful way when scrolling? [FF on Lubuntu]

~~~
2pointsomone
That's weird. Themed on FF on Ubuntu. I will look into it and try to fix it.
Thanks!

------
lsmith77
this is exactly the kind of scenario we aee trying to address with the
Symfony2 CMF: cmf.symfony.com

------
edwardunknown
I 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.

