
Drupal's Golden Handcuffs - mcrittenden
http://mikecr.it/ramblings/drupals-golden-handcuffs
======
tedsuo
I would add this to the complaints:

\- NOT AMENABLE TO SOURCE CONTROL

Half the code lives in the database, configuration is all mixed up with
content, and there's no reliable programmatic way to extract it. It makes
doing deployment a nightmare.

And the worst part? Drupal developers by and large have such a narrow range of
experience that they don't even know what they are missing. They have no idea
what good coding standards look like, a lot of them don't even have a
development/production separation: they just hack away on the live site with
no source control or backup. And no one writes tests, or sees why they would
be useful.

Some of the big professional drupal shops appear to have basically written
their own cms on top of drupal, with a bunch of terrible hacks to try to make
source control kind of work, and just use the drupal name basically as a
marketing technique.

So glad I don't have to deal with any of that insanity any more.

~~~
knieveltech
I work for a company that provides site implementation, custom feature coding
and ongoing support for ~30 enterprise websites and all of them have this in
common: 100% of the source code for each site is in revision control (SVN or
Git, depending on client preferences).

If you want to complain about Drupal be my guest. The ground's very fertile,
but what you've posted here is FUD.

Code in the database? No, just no. While it is technically possible to stuff
code into the database community best practices (not to mention common sense)
strongly advise against this practice. What you are describing is the system
handing you enough rope to hang yourself, not it's default behavior.

Configuration lives in configuration tables.

Content lives in content tables.

"they just hack away on the live site with no source control or backup"

It would be a mistake to take the fumblings of a few scrub freelancers or
interns and extrapolate that as being the norm for all (or even most) Drupal
developers.

For all core modules and all quality* contrib modules there are $N_load()
functions to extract these (reliably) from the database.

* With ~8000 contributed modules to choose from, quality varies wildly. While unfortunate, it's to be expected when you've got that many chefs in the kitchen.

~~~
apendleton
This is quibbling over semantics. Drupal's custom content types, custom
fields, and Views all allow developers to express complex logic that would, in
any other development environment, be expressed as code and committed to
version control -- creating a new content type in Drupal and adding fields to
it is exactly analogous to creating a new model in Django. You can call it
"configuration" if that makes it easier to justify its being in a table, but
it doesn't change the fact that Drupal developers spend lots of time building
shit that can't go in a VCS, can't be easily tested, can't be branched/merged,
and can't be easily deployed without a convoluted export/import dance. Just
because there isn't literal code in the database, it doesn't mean there's a
clean logic/content separation.

~~~
knieveltech
"Drupal's custom content types, custom fields, and Views all allow developers
to express complex logic that would, in any other development environment, be
expressed as code and committed to version control"

And that, in a nutshell, describes why Drupal's adoption rate is as high as it
is compared to development frameworks developers actually enjoy working with.
No fucking code. Non-developers can actually get results with the system
without having to resort to the kind of miserable hoop jumping we developers
subject ourselves to in an attempt to make sure nobody else on the team fucks
something up.

View got changed? Log in and change it back. Absolutely, positively MUST have
an ongoing log of changes to your view/content type/custom field? All of these
are exportable to code and can either be imported raw or live in modules.

I suspect you've worked with exportables at some point so I simply mention
this for any spectators that aren't aware there are a number of strategies for
getting your configuration into code (and thus revision control) if that's
your thing.

Also, for the uninitiated, apendleton makes an excellent point about deploying
config changes from dev/staging to production. It sucks, plain and simple.

~~~
apendleton
Being able to export and commit isn't really good enough; keeping a work log
is only a relatively small part of the capacity for version control systems to
expedite development. Many projects have development workflows where new
features are developed in branches, and only merged when they're ready to be
deployed.

Suppose, in a Drupal project, you had two such features being developed
simultaneously, and each added different new fields to a given content type,
with corresponding changes to views and authorship workflows. Assuming it were
even practical for each developer on a Drupal project to have their own
development instance of the database powering a site (which it totally isn't),
it's true that each developer could export their own version of the given
content types, views, etc., and commit them to version control. The exported
blobs are pretty much opaque to many Drupal developers (or non-developers, as
you say), though, and may not be expressed sufficiently sanely that Git could
figure out what changes actually took places. When these features were ready
to be merged, would the merge work? Who knows? What if there were merge
conflicts? Would developers be able to resolve them? Worse, what if Git's
notion of the correct merge strategy didn't actually produce a semantically
correct result? All of these operations take place on generated code that
nobody wrote and nobody reads, which is scary enough that the whole process
wouldn't be trustworthy.

Exportables are yet another in a long series of efforts in the Drupal
community to attempt to address a deficit they have with respect to most other
web stacks, and again they've done it in a way that doesn't really deliver the
benefits of the feature as it exists elsewhere (see also Drupal's "database
abstraction layer" or its supposed "object-oriented design").

~~~
knieveltech
"Being able to export and commit isn't really good enough; keeping a work log
is only a relatively small part of the capacity for version control systems to
expedite development. Many projects have development workflows where new
features are developed in branches, and only merged when they're ready to be
deployed."

Features, exportables, Strongarm (et al) are all compatible with the workflow
you're describing. Our development workflow is heavily dependent upon
branching. All new feature development takes place in branches that are later
merged into dev, with stable "snapshots" taken from dev whenever we do a
release. Pretty standard stuff, and we use features and installation profiles
heavily in our implementation work.

"Suppose, in a Drupal project, you had two such features being developed
simultaneously, and each added different new fields to a given content type,
with corresponding changes to views and authorship workflows."

What you're describing isn't a credible workflow, it's a mess. Field
declarations for a single content type strewn across multiple features? Why?
Designing a content type and exporting it to code shouldn't take more than 30
minutes for even the most complex content types. If additional features are
required they can be added to the feature but separation of concerns typically
dictates that that code goes into a separate module. Cleaner that way.

"ssuming it were even practical for each developer on a Drupal project to have
their own development instance of the database powering a site (which it
totally isn't)"

All of our developers maintain local mirrors of the dev environments for all
of the clients they work with. This includes snapshots of the dev database.
Also, how is maintaining a local copy of a database either impractical or in
any way a Drupal-specific problem? Any project that includes a datastore is
going to have similar issues.

"The exported blobs are pretty much opaque to many Drupal developers (or non-
developers, as you say), though, and may not be expressed sufficiently sanely
that Git could figure out what changes actually took places. When these
features were ready to be merged, would the merge work? Who knows? What if
there were merge conflicts? Would developers be able to resolve them? Worse,
what if Git's notion of the correct merge strategy didn't actually produce a
semantically correct result?"

Merge conflicts happen with any workflow. Merge uncertainty is an issue with
revision control, regardless of what platform you're developing in. As far as
manual merges goes, I submit that any developer should be capable of manually
merging simple array declarations (because that's all exportables are).

"All of these operations take place on generated code that nobody wrote and
nobody reads, which is scary enough that the whole process wouldn't be
trustworthy."

I think our definitions of both "code" and "trustworthy" differ greatly.
Exportables aren't huge blocks of opaque logic. They're simple associative
arrays. I have no problem trusting code that generates array declarations and
has been tested by the core project devs, security team, module maintainers,
and several thousand developers on tens of thousands of websites. Your mileage
may vary.

"Exportables are yet another in a long series of efforts in the Drupal
community to attempt to address a deficit they have with respect to most other
web stacks, and again they've done it in a way that doesn't really deliver the
benefits of the feature as it exists elsewhere"

100% accurate, you'll get no argument from me here.

"database abstraction layer"

My kneejerk reaction when this was first announced: DBTNG is a fucking
travesty foisted onto the community by Acquia as part of a corporate play for
the "enterprise" market. After a year of screwing around with it: It still a
pain in the ass but with all of the bullshit going on with the MySQL project
courtesy of Oracle, this might turn out to be very very useful.

"object-oriented design"

Who claimed Drupal was object oriented? Seriously, I'd like to know so I can
spill my drink on them if I ever run into them at a DrupalCon afterparty.

~~~
apendleton
"Field declarations for a single content type strewn across multiple features?
Why?"

Sorry for the confusion; I meant lower-case "features," as in, new pieces of
functionality that both affect the same kind of data, not "Features" in Drupal
terms. I don't think it would be especially unusual for multiple feature
branches to affect the same content type in different ways.

"Who claimed Drupal was object oriented? Seriously, I'd like to know so I can
spill my drink on them if I ever run into them at a DrupalCon afterparty."

Admittedly I've been away from the Drupal community for awhile, but I attended
a DrupalCon several years ago in which the argument was made in multiple talks
that Drupal's design followed the object-oriented philosophy despite not
taking advantage of PHP-native object-oriented mechanisms. This (old) article
seems to espouse these sentiments roughly as I remember them:
<http://drupal.org/node/547518> and I remember finding them to be pretty
ridiculous at the time. Perhaps community sentiments have changed since then.

~~~
knieveltech
Thanks for clarifying. At time of writing the only two data types that are
routinely and consistently cast as objects in Drupal's codebase are users and
nodes. The comical thing is neither have methods assigned and can just as
easily be cast as associative arrays (like everything else).

Outside of core, contrib has gotten quite object oriented over the last few
years as Views, Panels, Simpletest, Ctools (etc) are all heavily object-
oriented and the popularity of these modules has driven a lot of other contrib
module development that in turn is required to take an object-oriented
approach to interact smoothly with these modules.

Still, attempting to claim Drupal is in any way object oriented is like hot
gluing a handful of feathers to a basketball and calling it a chicken.

------
exratione
If you're using Drupal the way the author describes here - building in the
interface rather than writing code - then yes, you're pretty much doomed.
You're producing a very fragile thing that is very hard to maintain and adjust
later on, and heaven help you if you actually want to do something in a
different way than the modules you're working with allow out of the box.

Drupal development is very divided between (a) the small number of people who
can treat it as a framework and write solid custom code while still making
good reuse of core and contributed modules to speed development versus (b) the
much larger number of people who treat it as a sophisticated CMS with plugins,
and typically use Views and template overrides to produce a fragile solution.

On the money side of things - yes, if you're in group (a), then you can charge
a bunch of money. Drupal development is very lucrative. If you're in group
(b), then no. That's just an average wage.

~~~
jtreminio
What would you recommend an experienced developer coming into Drupal do to
land in group A?

~~~
knieveltech
Group A is guarded by a learning curve like the Swiss Alps. The only way to
get past that is to get as much exposure as possible. There are already some
excellent suggestions here so I won't rehash those, some other things you
might consider:

Idle in #drupal and #drupal-support. Whenever an interesting question gets
asked, go figure it out if you don't know the answer already.

Try tackling a few issues in the novice queues for D8. Not only will you get
the kind of low-level exposure to how core really works that so many "Drupal
developers" lack, you'll also get some nice bragging rights when your name's
listed with the rest of the contributors.

The next time you encounter a limitation with a module you're using, in
addition to hook_$N_alter()'ing the fuck out of it, try writing a patch that
cleanly extends the module to do what you want. Open an issue in the module's
issue queue and submit your patch. Code review can be tough to take but stick
with your issue until your patch is either accepted or the module maintainer
closes the issue (won't fix, whatever).

Try landing a gig with Acquia or some other big Drupal shop. You'll get to
work with (and learn from) some of the top talent in the community and you'll
get the kind of exposure you can't get experimenting in your spare time.

If you're serious about going pro with Drupal development drop me a line. I
may be able to help and would be happy to introduce you to others in the
community.

------
peterjmag
Moving away from Drupal was one of my biggest steps forward as a web
developer.

I worked with Drupal full time for a little over two years. I spent much of
that time clicking around in config screens, and when I did have to get my
hands dirty with some custom code, I usually felt like I was just stumbling
around in the shadow of the behemoth that is Drupal's API. I thought, "Surely
this isn't what web development's supposed to be."

Turns out I was right. On recommendation from a developer friend, I started
experimenting with a bit Rails, tried a couple of "proper" PHP frameworks, and
then discovered Python and its excellent web development ecosystem. That's
when it really started to click for me—all these pieces that Drupal had so
kindly obscured from me started falling in to place. Rather than trying to
push around a monolith, I learned how to keep things lightweight and use only
the pieces I needed. And importantly, I was actually writing _code_. Sweet,
readable, maintainable, version-controllable code. None of this "serialize a
hugely long options page and dump it all in the DB" stuff. (On a side note,
learning git was another big catalyst for my move away from Drupal. D6 always
felt like a pain to track in a VCS, especially when I was collaborating with
another developer—though the situation may be improving.)

I should point out: I think a big part of my frustration was the fact that
many of the sites I was building didn't need something as big as Drupal. I've
since found WordPress to be a better fit for most of the "easy" stuff, or even
static HTML/CSS if it makes sense for the project. When I'm building something
more complex, well, there rarely seems to be any reason for me to use Drupal
anymore.

~~~
lotyrin
I've been doing Drupal full time for the past four years and I'll agree 100%.
People that try to build applications in Drupal are running a fool's errand.
It's got a ton of code and another ton of assumptions, but that's the thing;
when those assumptions are what you need and that's code you don't have to
write, magic happens.

I'd say, 90% of the time, if you're using Drupal and you're in a code editor
instead of the admin UI, you're making a mistake, either because there's an
easier way to do what you're doing, or because you shouldn't be using Drupal.
The real trick is knowing which.

------
rybosome
Developing a large web application in Drupal from October 2011 to May 2012
was, by far, the most stressful period of my professional life. The most
difficult part is that the vast majority of learning materials for Drupal are
aimed at non-developers. So much literature is dedicated to impressing people
who otherwise couldn't create a website with things like, "LOOK! You can
implement access control, put a smiley face next to all comments, AND have a
YouTube video feed!" that finding documentation on actual code is extremely
challenging.

Another aspect of the project that was difficult was that the client had very
specific needs. In almost every piece of functionality they requested, there
was some wrinkle that made using an off-the-shelf module impossible. This
meant having to code against the behemoth Drupal API. After about 3 months of
work, I created an OO-wrapper module around Nodes called Doodal
(<https://github.com/rybosome/doodal>) that makes it possible to code in an
MVC-like way. This made the rest of the project somewhat easier, minus the
parts that involved interfacing with native Drupal. Drupal was created at a
time when PHP didn't have object oriented features. Their solution to the
problem of needing OO-like behavior but not having it was to emulate it, which
is an abstraction that quickly falls apart. For instance, the shortest line of
PHP you could possibly write to simply print out an optional "first name"
value from a node representing a person is...

array_key_exists('und', $person->first_name) ?
$person->first_name['und'][0]['safe_value'] : '';

While I was wrapping up this project, a friend of mine pointed me to an
opening his company had for a Drupal dev, paying about 1.8x what I was making
at the time. I declined without even thinking about it, and have not regretted
it for a second.

~~~
chx
First, it's LANGUAGE_NONE not 'und'. Second, while I could go on how you
should use field_get_items instead, it's very very likely you are missing some
concepts here an you want a formatter, a whole display mode etc. You very
rarely need that level of plumbing.

~~~
rybosome
The constant LANGUAGE_NONE represents the value 'und'. Yes, using the value
directly rather than the constant is bad practice, and certainly is not
idiomatic in any language; I'll concede that point to you.

Regarding the use of field_get_items, check the documentation on the return
value: "An array of field items keyed by delta if available, FALSE otherwise."
Per my requirement of getting a single, OPTIONAL field value, field_get_items
might return false, which means we are still looking at something like this
overly verbose code:

($first_name = field_get_items('node', $person, 'first_name')) ?
array_shift($first_name) : '';

Lastly, "you want a formatter, a whole display mode, etc. You very rarely need
that level of plumbing". One of the requirements for this project was that
each page represented by a person node would have a very specific layout. This
meant that I couldn't rely on Drupal's default layout (even with formatters
there was too much baked-in HTML that was unacceptable), and had to create a
node--person.tpl.php file, i.e. a custom template.

~~~
chx
I still say this: If your node.tpl.php contains field_get_items or equivalent,
you are doing it wrong, on a very fundamental level. If the formatters provide
too much HTML, write your own, write a proper field.tpl.php etc.

~~~
Falkon1313
So in order to "print $person->first_name;", you must first create formatters,
display modes, and templates? Point goes to the one who's saying that it's
overly complicated. Drupal makes it easy to do difficult things, but
infuriatingly difficult to do simple things.

------
lkrubner
I am puzzled by this:

"Good Drupal developers are making a lot of money right now, much more than
I'm seeing for Django or Rails or Node devs in general."

I am curious where this is? This is not true in New York City, where I am.
Developers who are good with a given PHP framework (Drupal, Symfony, etc) will
make something like $60 to $70 an hour. The top Rails devs will make at least
the same amount, and usually a little more than that.

~~~
dasil003
This doesn't make sense to me either, though I haven't touched Drupal for at
least 6 years.

In my experience, Drupal is ideal for cheap clients who want a zillion
features but don't have the budget. You can deliver more functionality in
Drupal than anything else, that is absolutely true.

For high-end clients who are willing to pay for impeccable UX and solid
problem-solving, I can rarely recommend Drupal because it starts with a raft
of assumptions that tend to lead to subtle compromises in the UX but would
require an inordinate amount of effort to fix.

I ditched Drupal for Rails specifically because I hate being in the position
where I have to explain why a seemingly simple change would require far more
work than logically makes sense (to be fair, this is an occupational hazard of
programming, but with Drupal it happens to an obscene degree). Going to Rails
felt like targetting a higher class of client.

Meanwhile Rails developers seem like some of the most sought after programmers
today. Where is this elite Drupal employment world that the OA speaks of?

~~~
w4y2
It appears you don't really understand the Drupal theming layer.

~~~
dasil003
You created a new account just to post this ignorant snark?

My Drupal knowledge is well out of date, but the indisputable fact that the
Drupal architecture like all software architecture imposes assumptions, many
many more assumptions than a low-level framework like Rails (which tries to
keep its assumptions as broadly applicable to all HTTP usage as possible).
These assumptions imply tradeoffs. If you think there are no tradeoffs you
need to step back and realize that Drupal has corrupted your mind and the
limits of your web development ability will be constrained by whatever ideas
Drupal core is able to harvest and integrate from the wider world of web
development.

------
graeme
I don't have this problem, currently. But I've previously used boring,
lucrative work to bootstrap my way into more interesting work. Here are the
steps:

1\. Identify what you would rather do

2\. Keep doing boring work, but part time

3\. Reduce expenses

4\. Use money from boring work to subsidize skill development in interesting
area

5\. Switch to interesting area

Obviously, this only works in fields where you can get away with ~4 per day
spent on your main work.

------
at-fates-hands
Okay here's my Drupal story. It starts out with me at a Drupal conference.
First question I ask is this, "Is Drupal a framework or a CMS?" To which the
guy running it said cheerfully, "Both!"

After building my personal site with Drupal, I realized the one thing which
drove me nuts was the vast number of modules I wanted to use either had shitty
documentation or none at all.

It was basically, "Install this and it works!" Which made me spend even more
time either having figure out how this thing worked, or attempting to write my
own.

To me, this is not a developer friendly framework. When I talk to my friends
who are developers and they flat out tell you there's a STEEP learning curve
with Drupal, they're not kidding.

I can honestly say I built a dealer locator from scratch faster than I did
trying to figure out how do it in Drupal. Just an example of the stuff I'm
talking about:

<http://drupal.org/node/38401>

------
mcantelon
Developing via a GUI is good for rapid prototyping or CMS applications, but I
prefer traditional coding for web applications. It's easy to change something
in a GUI and not notice it. You can't "grep" a GUI to find the screen you need
to access to change something (as you may need to click through several
screens to get to where you want to go). Version control becomes more
complicated as well: when development is defined by data in a database it's
more complicated to have a staging/production setup than with straight-up code
in version control. Plus text is expressive: there's a reason humanity moved
to the written word from pictographs.

Performance can also be an issue as well in Drupal, depending on your use-
case. Stuff based on layer upon layer of abstraction uses more memory and can
be slow. "Just add Varnish" works for some use-cases, but not others.

Upgrading can be painful as well. Because third-party modules are dependent on
Drupal core, when you upgrade Drupal core you also have to upgrade all your
modules at the same time. For a complex site this can take awhile. If a module
isn't upgraded you either have to do that work yourself, drop it as a
dependency, or wait to see if the module gets updated. With less monolithic
systems you can deal with upgrading components individually which can make the
process more manageable.

~~~
jackbravo
you can use the features module in drupal and have the best of both worlds.
You click to get a prototype quickly, then you export the functionality to a
module with drupal and keep track of changes with git.

------
justinph
Drupal 8 is basically trying to get to where django/rails/symfony were several
years ago, and based on the glacial development pace of the last version, by
the time it is complete, they'll still be several years behind the feature set
of contemporary frameworks.

In my experience, Drupal is a pristine example of the way modern software
should not be made. With one or two notable exceptions, there is a distinct
lack of computer science type knowledge in the drupal world. The result is
kludgey, over-complicated, and inefficient code.

Drupal's "success" is only because it's community consists of people who don't
know any better. The author himself points this out by making laborious points
about how much money there is to be made propagating bad, wasteful practices.

~~~
knieveltech
"It's "success" is only because it's community consists of people who don't
know any better."

That is both untrue and dishonest. Drupal's success is directly attributable
to all of the following:

1\. a very large, growing, and passionate pool of contributing developers and
designers.

2\. aggressive community involvement a la issue queues, forums, IRC, local
user's groups and 30+ regional camps and conferences in North America alone.

3\. Did you read the part where the op wrote about the ridiculous amount of
shit you can get done without opening a text editor? Office staff with minimal
technical background can be trained to implement/manage most of it.

4\. It. Just. Works. On commodity hosting no less. Or on expensive enterprise
hosting. With little or no assing around with server configuration. There are
hosts that have push-button site installation.

In short, Drupal is popular for all of the same reasons that PHP still hasn't
gone away after almost a decade of developers whinging that it sucks.

Is it fun to code for? Nope, not even a little bit. By the time you've written
your fourth or fifth custom module 99% of it is the same tired slog through
boilerplate code and hook_$N_alter() groveling. Dull, dull, dull shit. And yet
I suspect Drupal and Wordpress (which is arguably even worse to deal with) are
running way more websites than django, rails, and symphony put together. Look
on the bright side, at least it wasn't written in Perl. :)

~~~
justinph
1\. Growing by what measure? When I was at Drupalcon 2012 there was a large
amount of discussion about how the community wasn't growing and was the same
people every year. And I seriously don't mean to be a dick, but passion
doesn't equal technical competence. You don't have to be a gifted programmer
to understand quality, and understand that Drupal lacks it.

2\. There are user groups, I've been to them. They're mostly full of people
who have basic problems and a few exasperated and grizzly veterans who offer
arcane solutions to non-arcane problems "use last night's dev version of the
module, sure it's ok to put php in the database... And the community of
drupal.org might exist, but if you can sort it out from the convoluted UX mess
that is drupal.org, good luck.

3\. Is that supposed to be a feature? In theory, you can get ridiculous
amounts of things done if you happen to know the arcane way to combine 30
different checkboxes and twelve different modules. How is this by any
objective measure better than writing code? Code is expressive, documentable,
concise. Checkboxes and UI interactions are not.

4\. This is hardly a unique feature. The same can be said about wordpress,
rails, django, etc (at least if you use webfaction)

I don't think you can argue under any objective measure that wordpress is more
difficult to deal with than drupal. It has many of the same issues as drupal
(feature management), but the ease of theming and documentation are lightyears
ahead. It's also quite a bit more limited.

~~~
knieveltech
1\. Site adoption rates, especially in the enterprise space. You're absolutely
right, the developer community isn't growing, and I think the blame for that
lies squarely with the core codebase's deathmarch towards becoming Sharepoint.
There was a point in time (circa D5, early D6) when coding with Drupal was
still kinda fun. Core architecture didn't get in the way as much.

2\. There are user groups, I've organized two of them. They are frequently
full of people who have basic problems and a few exasperated and grizzly
veterans who offer arcane solutions to non-arcane problems. Best outcomes
typically occur when one or more local dev shops get involved with the group
and use community support as a way to build their brand. Anecdotally this
describes most tech user groups.

3\. Yes, this is a feature. It's objectively better because you are not
writing code. In addition to the obvious benefits (no fucking code) this puts
the task at hand (at least theoretically) within the reach of non-technical or
semi-technical individuals.

4\. I dislike Drupal's internals for diverse and varied reasons I will not go
into here. I dislike Wordpress's internals for many of the same reasons, and
Wordpress is substantially more limited in it's capabilities than Drupal. Same
general set of problems, many fewer features.

Also, I agree Drupal's documentation sucks hard. Unfortunately there's nothing
to be done about it. It would take close to 10,000 man-hours to write shitty,
blatantly misinformed documentation for the current body of contributed
modules, assuming you budgeted 30 minutes to examine the module and 30 minutes
to write about it.

------
tombb
If you're an engineer/coder building sites by clicking buttons all day, you're
in the wrong job. That's not Drupal's fault though. Drupal is a CMS - a
powerful one, but not a framework..

At my work we've got a team of "web designers" building websites using Drupal.
It allows them to build most of the stuff that clients want for their
website/intranet, without writing code. For the more business-logic heavy
applications that need to scale and continuously require new features there's
a separate team of Django developers.

This approach seems to work fairly well: designers get to build pretty
advanced stuff they normally wouldn't be able to without some programming
help, developers don't get the boring CRUD/shopping cart stuff.

------
stevepurkiss
Interesting article, perhaps if a few of those "I'm bored"s were changed to
"I'm helping make Drupal suck less by writing some documentation" or "I'm
learning cool new stuff cos Drupal does the generic boring stuff for me" the
author would have a more fulfilling life.

If everyone blows a little more energy back into the Drupal project, it'll
suck a lot less ;)

~~~
mcrittenden
It depends on your work environment. If your boss asks for 40 billable hours a
week and you have a family to keep you busy in off hours then there's not much
time for writing docs or contributing modules.

~~~
jackbravo
Is the same problem that every person working with free software projects
faces. Can I contribute more if I'm not being paid to do it?

In the long run you can expect those extra hours contributing to the project
to really pay off, because you gain a deeper understanding of where things go,
because you meet people that can help you, because people see your
contributions and you make connections and a lot of other goodies.

------
richforrester
I'm a Sydney-based UX person with a background in UI and front-end coding, and
I happen to find programming (I dabble in php) extremely satisfying. Drupal,
to me, is definitely a means to get things done.

Here's my "day in Drupal":

\- Amazed \- Amazed \- Bored \- WTF? \- Lunch

\- Amazed \- Puzzled \- Amazed \- FUCK YOU DRUPAL! \- Amazed

Yes, setting up content types and views can be annoying, but really, sometimes
you get a view done in under 15 minutes. Including styling. Stuff like that
never ceases to amaze me, and really makes Drupal worthwhile.

I could never code a cms ground-up, and the likes of cakePHP and whatnot just
seem a wee bit too far down the rabit-hole (for now).

Drupal is an "easy" alternative.

------
patrickdavey
I have just left my Drupal job for a Rails job, pretty much for the reasons
listed here... I'm certainly going to be making _more_ money doing it too.

I reckon 40 hours a week (or whatever you work) is far too many to be doing
something that leaves you bored or frustrated for a reasonable percentage of
the time.

------
languagehacker
Based on my two minutes of salary research I can say that someone with the
title "Drupal Developer" make substantially less than someone with a title
"Django Developer" (about $10k in SF), and (again, in SF terms), substantially
less than the average software engineer without a framework in their title.
From what I've seen on job posts over the last couple of years, including the
framework in the title is something relatively endemic to Drupal, so I'm
assuming that they don't get lumped into "Software Engineer" too often.

So let's take compensation out of the discussion.

Now let's just list the actual problems with Drupal.

It seems like there are as many drawbacks are there are off-the-shelf features
when you're making Drupal the core of your own product. It also seems to make
a lot of assumptions about your application following a very specific CRM
architecture.

I'd personally prefer to spend the effort on building out the CRM components
myself using a more modular framework so I have more control over the
architecture, the version control history, etc.

It sort of seems like Drupal tries really hard to set itself apart from
WordPress. In reality, it seems the major PHP CRMs all fall into this very
narrow point of view on what the responsibilities are of the implementing
developer. This minimization of implementation detail promotes a very limited
perspective on how a PHP web application works. So now your product's
architecture is hobbled by the philosophies of the core library as well as
those most apt to develop on it.

------
freshhawk
And now we have all the silly arguments comparing web frameworks and CMS's.

The CMS people will compare installing modules to writing code from scratch
instead of installing a library and writing a bit of glue code. If they don't
make that mistake they will probably underestimate how much more flexible,
better written and better tested that library will be compared to the CMS
module and overestimate how hard it is to glue in a general purpose library.

The web framework people will underestimate just how fast it is to install a
module into a completely integrated system and underestimate the time they
would have spent integrating the library and writing the glue code. They'll
also overestimate how often a client needs a piece of functionality that's in
any way interesting instead of just a new skin on the same old thing.

The answer is "The progression goes: CMS -> Web Framework -> Http related
libraries"

The question can be any of the following:

"What web related stuff has the worst code quality? what has the best?"

"How will the tools I use change as I get more experience in web development"

"What tools will I use for the most boring web dev work? What about the most
interesting?"

"What tool skillsets in web development will earn me the most money"

"What tool skillsets have the least amount of jobs? what about the most?"

"What tools web dev tools will make me want to punch my monitor the most? and
the least?"

Feel free to come up with your own.

------
Finbarr
Couldn't agree more. Having built a range of Drupal sites on a freelance
basis, I can confirm that you can do crazy amounts of work with just a few
clicks of the mouse. The moment you realize you need to customize, however, is
a dreadful one.

------
vph
Years ago, I wrote and published a couple of Drupal modules, which are still
being used from time to time. But I moved away from Drupal. With Drupal, you
don't learn about building web apps; what you learn is "tweaking" a complex
system. You can be building very complex apps nicely, but at the same have no
clue about what is underneath.

------
hawtshot
Drupal definitely allows you to get 95% of the most common features done very
quickly with contributed modules but the assessment that it shatters if you
try to bend it too far is very accurate.

Also, the RESTful API is not fun to work with, mainly because the
documentation for it is really lacking. It gives you all the information that
you need to do CRUD on standard fields but if you throw date or file fields
into the mix, you'll be tearing your hair out. It's also quite clunky and
tedious to parse responses from since it responds with entire nodes which can
include unnecessary RDF info or multiple languages along with field values
nested 3+ levels deep in arrays.

------
jacques_chester
This all sounds like my $dayjob with Oracle Application Express.

Except that ... you know ... people have _heard_ of Drupal.

------
Zelphyr
I just spent over a month on a project where we started to use Drupal and I
can't see a single thing that is good about it. Poorly written core code.
Poorly written modules. Abysmal UI. The only thing I can possibly think that
Drupal has going for it is a great community and, as this article mentions,
the ability to make a lot of money for little work.

Needless to say, a month and a half into the project we dumped Drupal.

------
berkes
I think author is switching _cause and effect_ :

Move a few paragraphs around and the problem becomes clear. It is right in his
article!

> Drupal just isn't a great system to code for.

And _then_

> No debugging your custom code

Proper, well architectured custom code is not hard to debug. At least not
anywhere near as hard as debugging Drupalcode. Due to, yup "Drupal just isn't
a great system to code for."

> No digging through the docs trying to find the API function you need for an
> odd task

"Drupal just isn't a great system to code for."

> A discoverable UI--click around until you find what you're looking for,
> rather than digging through code

Hmm. there is a pattern here: "Drupal just isn't a great system to code for."

> A team of thousands of users and contributors testing the code in ways you
> never would have imagined and fixing the bugs

Klicking Monkeys testing stuff? Where are the unit-tests? CI? They are there,
somewhere in Drupal, but in reality unusable, because, yup "Drupal just isn't
a great system to code for."

> A much much smaller risk of security breaches due to that team

Well, to an extend. But the most security comes from your arcitecture. And 90%
of the Drupal-security-anouncements can be tracked back to, yup "Drupal just
isn't a great system to code for.".

> Holy crap, so much faster

Yes. Faster then coding. But that is only true for Drupal, because, "Drupal
just isn't a great system to code for.". It certainly is not faster then your
average _R_ AD-framework for many, many sites. There may be some cases where
Drupal is faster, but only when you don't have to write a line of code, nor
need to debug and find why Module Foo and Bar don't work together, because..
well. See above.

------
room271
I wrote a blog on this problem for Drupal a while ago - but with a particular
focus on the fact that Drupal has a 'talent problem' precisely because of what
the article says (Drupal is not fun for developers and, moreover, fails to
promote learning). You can read it here:
<http://room271.net/2012/05/24/developers-and-drupal.html>

I worked on Drupal for ~1 year and wrote very little custom code.

The caveat is that core developers working at one of the top Drupal shops do
get to write interesting code, but they are the exception rather than the
norm.

ps. still a big fan of Drupal, just don't want it to be my day-to-day work.

------
cyberswat
The beauty of open source is that we have the ability to learn from the
experiences of others. Many of the challenges expressed in these conversations
are being met head on by the Drupal community. I disagree with many sentiments
of the OP but also practice integrating different technologies, when
appropriate, to get a job done ... The feedback in this thread is invaluable
and highly appreciated.

There are technical solutions in the form of modules and organizational
workflow solutions that can be used to solve most of the issues I see
mentioned here. There are also a lot of false or mis-informed assertions.
Thanks for the insight.

------
saltcod
I left Drupal for WordPress because:

1\. When it breaks, it shatters—as you said 2\. WordPress's UI is so much
better for clients, in my experience 3\. Theming in Drupal was a nightmare —
div.class > div.class > div.class

It's such a shame about Drupal. It's so capable, flexible and powerful, but
the ui is a tough sell. You can build almost anything with it, but when it
comes time to theme and eventually time to hand it off to the client, that's
where things got hairy for me.

------
jack-r-abbit
uh... I have never had a day when I said "I'm Bored" like that. What you
describe as all the Productivity stuff that can be done with zero coding isn't
really all that Drupal _developers_ do. At least not where I work. We are
writing custom code/modules on a daily basis... not just "every now and then".
But I guess it comes down to the type of site you're building.

But I have had my fair share of "WTF?" and "Damn it, Drupal!" moments. That
much is true.

------
Falkon1313
1) Drupal's great if you can accept something close to what you want - that
has most (but not all) of what you want, plus some stuff that you didn't need.
But if you're dealing with perfectionists who want things precisely their way,
then you'll spend a lot of time and add a lot of complexity overriding,
suppressing, and customizing things and gluing clusters of modules together.
Sometimes more than if you'd just built what you needed from scratch.

2) Initial standup can be very quick and easy, especially if you can do it
with mostly out-of-the-box stuff (see 1). But over the long-term maintenance
and development can be extremely difficult.

3) If you're stuck using designs from designers who aren't skilled with
Drupal, theming is likely to be inordinately difficult. Drupal provides a
great amount of useful tools and utilities to designers, but if the designer
doesn't use them then you basically have to rip them all out and/or override
them all and the theme can grow monstrous.

4) The ability for a 'non-technical' user to do so much through the admin
interface is a great strength. But the fact that there is so much there in the
admin interface (scattered around by the different modules) means that non-
technical users often can't (or won't) use it without a thorough understanding
of Drupal and the modules. It's too complicated. So you'll need to add time to
strip out, simplify, and rework the admin interface. Even then, you may still
end up with programmers being tasked with content edits.

5) The database for config+content really is a big issue that majorly affects
long-term maintenance and continuing development/deployment on a live site.
'Features' and exportables are not a good enough fix. They're better than
nothing, but don't rely too heavily on them. They break down in a lot of
cases. D8 promises to be better on that issue...we'll see.

6) Performance really is a problem. For any moderately complex and trafficked
site, you have to set up proxies and elaborate caching and etc. etc. just to
get "okay, I suppose that's acceptable enough" performance. It can be done,
but it's a major headache. That's a tradeoff for the flexibility and
modularity.

I've built scores of sites in Drupal over the years, and it's a great tool,
but it's far from perfect. It's all about tradeoffs, and often the greatest
strengths are also the greatest weaknesses. You just have to decide whether it
fits what you need. If you can live with the drawbacks, then it's good. If
not, then you'll need something else which will have it's own different set of
drawbacks.

------
gadders
I think this applies to a lot of platforms, tbh. It even reminds me of when I
was a #embarrassed cough# Lotus Notes developer 12 years or so ago.

I think it might be the price you pay for using a "framework". 80% = really
easy, the remaining 20% is a git.

------
nearly
the article refers to being bored. any drupal dev who is bored because they
are talented and unchallenged should be contributing to core development. the
OPs d.o profile shows contribution but not focused on a particular core
initiative. the employer could be giving time over for that. contribution is
satisfying and challenging. and much needed!!

------
WiseWeasel
I'm using Drupal as a back-end, and doing the fun stuff in the front-end on
the client. No boring days here.

------
patrickocoffeyo
Drupal is fine to code for, as long as you know what you are doing.
#codemonkeylaughsatalltheclickmonkeys

------
dougvann
...note... After Mike published the "Golden Handcuffs" post he publicly stated
that he did not intend it to be so negative. [yah... I've been there. I start
typing and my passion pours out and all the sudden I'm fire up like crazy] So
I hope my criticism of this article is pointed in the right direction. ...
here goes....

I can not begin to state how much I disagree with the conclusion of this post
by @mcrittenden . I believe he feels the way he feels. I believe he has
experienced what he says he experienced. But the conclusion is not a typical
one. Most of us who are making tremendous earnings in Drupal are NOT bored,
unchallenged and lamenting the lack of fun and elegance of coding. We are
excited, challenged, evolving, stretched ppl who are having a blast with what
we believe to be the BEST community associated with the BEST software out
there. [yah... we're pretty biased but THAT is the enthusiasm you run into on
a large scale]

I am not saying that he's lying. I believe he is telling the truth when he
says he's bored and unchallenged and despises the lack of elegance. I liken
that to some one who really misses their horse after trading it in for a
Model-T. I get it. We did just find for a very very long long time with the
horse. Horses are still used today and not just for entertainment but for very
real and practical reasons. There's simply NO WAY that some one is going to
have a relationship with a car in any similar manner that they did with their
horse. I fully respect @mcrittenden and his position here. When ever some one
goes on a rant about what they don't like about Drupal [and OH how often this
happens!] I find that many of the points are valid and I can not write them
off and dismiss them out of hand. Such is the case here. I will say this....
Drupal is a career and a discipline and a community. I encounter some of the
same challenges that @mcrittenden does. I don't have the same reaction. I get
better and better at this and I have many friends who I can reach out to.
Whereas shops have a lot of BRAIN POWER in-house, we independents stick
together and hit each other up with those WTF moments. Between all the
DrupalCamp, DrupalCons, local UserGroups, Internet Relay Chat, Skype, Email...
I'm very connected to the community and I get answers to my questions when
ever I need them. If I know an area of development is going to be extra
challenging.. I will factor in some room to pay my friends who know things I
do not. Yah... We get freebys from each other ALL THE TIME but I really love
it when I tell some one I have a couple hundred bucks to spend on them to
teach me something or to architect a solution. I've even spent thousands like
this before. I knew the client had needs and I connected them with another
shop to handle a very specific piece of the puzzle. It worked well for all
concerned. And by the way... this was FUN and Challenging and the solution was
very Elegant.

CONCLUSION: I DEFINITELY run into issues with Drupal from time to time. Just
like sharepoint and vignette and ez-publish and auto-mechanics and horse-
handlers do. My reaction is a little different. I have made the choice long
long ago that DRUPAL is my vehicle. I don't want to use Joomla like I used to.
I don't want to use Sharepoint like I started to and was studying in 2007. I
chose Drupal. Now that I have made that choice I am enjoying great money and
great challenges and an even greater community. Our system has its quarks;
some are minor and some not so minor. Regardless, this is the path I'm on. We,
the community, are continuing to improve "this area" and "that area" and yes
I'll even agree that some areas are getting a little worse with each release.
This is no secret and I'm part of two different teams that are assessing the
situation and proposing action and then encouraging and seeking funds for that
re-action. We're seriously on a roll here with this stuff.

@mcrittenden I get it, man. This stuff [called Drupal] can ROYALY piss a guy,
or gal, off at times. But what you describe as boredom and click monkeys is a
drastically inaccurate description of what I, or anyone I know, do for a
living. I do know of many HOBBYIST Drupalers who just want to point and click
and they are using Drupal as an overgrown geo-cities but I know that's not who
you're talking about here.

I really appreciate the article! This global conversation is sparking other
conversations that are enacting change! So.. THNX!

Doug Vann [Drupal Trainer, Consultant, Developer] <http://dougvann.com>

------
patrickocoffeyo
if you can't code a CMS, don't claim to be a professional at using them.

~~~
mcrittenden
Can you expand on this? How is this comment relevant to the article?

~~~
reeses
If that were the case, there would be no market for CMS. Everyone who wanted
one would hack one up in Excel.

Or maybe Word with macros.

~~~
patrickocoffeyo
Not really, a CMS is good because you don't have to build the same thing
multiple times. However, if you plan on using a CMS as a tool to create solid,
scalable, efficient applications, you will need to understand how to use the
CMS properly. Many times that means understand what the CMS is doing behind
the scenes. Any good programmer should be able to code a project like Drupal,
granted that would take time, but they should be able to do it without
sweating too much. I get extremely tired of the noobs and click-monkeys taking
of the drupal community. If you can't write your own decent CMS because you
don't know how, you should find another job, and leave application development
to people who can do it properly and give clients a product that is worth the
money they payed.

~~~
reeses
You're confusing Drupal with a CMS. It's much more, and less.

~~~
patrickocoffeyo
I'm not confusing it with a CMS at all, it is a CMS. You can use it more as a
framework, but as a framework it really kind of sucks when compared to Code
Igniter or zend, or even Yii.

