Drupal's Golden Handcuffs
mikecr.it
mikecr.it
- 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.
In Drupal 6, the only way to reproduce an environment was with a massive install profile for the project, and the average Drupal developer was entirely clueless to matters of testing and version control when compared to the average Django/Rails/CakePHP developer. This made for many painful projects and unhappy clients, usually beginning 6-8 weeks into the project when the issues of database drift became inevitable.
And like you said, everything lives in the database. So the chances that some production issue (or new issue only seen in dev) was caused by an errant user action in the Drupal UI was pretty high, and this made debugging a nightmare -- where is my issue really coming from?
I'd just about forgotten about my Drupal days of yore, and between the "click monkey" analogy and the "clear the cache" nostalgia, the author sure conjured up some bad memories!
Features and things like http://drupal.org/project/drush_make is what makes a lot of the drupal distributions (http://drupal.org/project/distributions) that keep popping up because sourced controlled, feature driven development is now possible in drupal.
Also the testing part has been improving, and although very few of the contrib modules have tests most of core has automatic testing in place for when you submit a patch as you can see in the issue queues (http://drupal.org/node/466576).
- How to deprecate a feature (I created http://drupal.org/node/1400346 to attempt to solve this, but admitedly, it's a very dangerous module) - Ever created a feature with tons of things in it? Hello, 5 minute load times for admin pages! - How do you merge two features together? How do you commit just one feature and not another (say, one you're still working on?)
The CMI initiative will hopefully take care of a lot of the messiness and bugs in Features.
I've merged features together and it was not as hard, at the end it is all code, you just need to be very careful, but at the same time you have git to revert if something goes wrong.
I don't understand the part about committing just one feature. You can commit just one =P.
I finished up a project earlier this year that has more than 300 modules active in a custom install profile, with 10MB of features modules stuck in there. We committed/contributed to a few fixes in core and Features to speed it up greatly. That's out in the wild on major sites and doing fine.
We didn't have any terrible admin screen issues, or indeed any terrible issues beyond occasional painful version control collisions.
Similar comments for Moodle, another popular PHP app. You cannot even change the url for your site without rewriting content in the database.
Thankfully the WP core devs seem to have been slowly cleaning stuff like this up over the last couple years. So even though this wart persists, I have hope it'll eventually get zapped.
On the other hand - if this problem could be solved - Drupal become holy grail, which should not exist! :)
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.
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.
The benefits of having a UI to manage core application behavior is lost on most clients. Most are terribly scared of editing a view, content type, or pretty much any other module specific configuration. I speak from the experience of someone whose developed about a dozen or so Drupal sites.
When we removed the fear of fucking up, they started learning.
I'm not sure whether I think that's insane, or whether I'm simply very jealous of your clients.
It also depends on the structure of the site itself.
But some are comfortable changing a title, sending new arguments into panes and stuff like that. Again, depending on structure. As long as the job can be boiled down to a simple point and click routine, they get comfortable doing it. They're not too scared of filters either.
Some are also comfortable setting up new panel variants. It's an extremely powerful editorial tool, when setting up sections with teasers. ("breaking news" sections based on terms for instance.)
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").
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.
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.
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.
Actually, I think what we should be asking is this: Do CMS databases and VCS really have to be two completely seperate universes? I would say no. There is room for a new type of CMS database design that includes all the functions of a VCS.
The code defines the default configuration.
If the user changes the config using the UI, the change gets written to the database. At the same time, a little telltale light (or something) tends to appear in the UI display, to alert the admin that something's been changed on the site, but not in the code.
Your developer can then come along and pull a report that lists any configuration that's been changed in the UI but not migrated to the code. Pressing a button spits out a code-based representation of that configuration. The developer finds the right file, pastes in the config change, checks into Git or SVN. Now the config is once again captured in code, and ready to be deployed in a consistent manner.
I'm not sure if the Drupal 8 team is using this pattern or something different. Still trying to catch up with this stuff.
drush up feature_name
git commit -a
drush fd feature_name
The UI is enabled on development environment, allowing for extremely quick experimentation (possibly by non-technical folk), but you still get (most) of the benefits of changes being in code.
ETA: It's not perfect, but it's on it's way to becoming the best of both worlds. Drupal 8 is making significant progress in that direction.
"Configuration lives in configuration tables" : the OP's point exactly. Configuration should live in a VCS
Bear in mind also that "configuration" van be so complex with Drupal it's often more along the lines of being "an application". A non-trivial view is hugely complicated and yet all its settings and code live in the database entirely, with no way to either back it up in a VCS or deploy it from a development environment to a live environment without manually copying the settings from one to the other.
That's not version control, that's an export function.
Drupal 8 is continuing to make this easier and more powerful, by (amongst other changes) making configuration live in the filesystem by default, turning the copy in the database into (one of several options for) a cache.
Drupal lets you get a ton of shit accomplished without making you understand a single line of code, have a reasonable Dev-Stage-Prod workflow, QA, even version control or backups, etc., but it's completely possible to do all of that. That means that it can scale from anywhere from something like a 16 year-old's shared-host fanfiction site to say Whitehouse.gov.
Of course that means that there will be tons of fuckups live-coding (or live-configuring) on production, or people that don't export and version things in environments when they should, and that people will construct fragile combinations of modules and configuration where a tiny bit of code would have sufficed, or write tons of fragile custom code with no tests or security review when there was already a module for that.
But allowing people to be fuckups doesn't force them to be, and they can be trained.
Scaling to Whitehouse.gov is not impressive at all. Like a 16 year-old's shared-host fanfiction site whitehouse.gov really is nothing more than a content site, albeit a very large one.
The problem is Drupal isn't content to simply be a CMS. It has to pretend to be a framework for developing web apps as well, and for that it's just plain terrible.
Drupal is only for when what it (or modules) can provide is a vast majority of the requirements of the project. Anything that couldn't be described as "nothing more than a content site" probably would not be a good fit.
The only thing it has to offer is when what you need is one of the myriad things it can be configured to be, because then you get a bunch of community eyes and tests on a bunch of code you didn't have to write.
Edit: Discussion on recent improvements to PHP's and its ecosystem (which are exciting progress in a direction I believe there is more room to go) http://news.ycombinator.com/item?id=4605715
What do the current offering of PHP frameworks lack that Python/Rails provide?
In the case of rails, beyond the easily copyable superficialities of the MVC pattern, simple ORM and HTTP helper methods, what you have underneath is the elegance of the ruby OO model.
The ruby OO model with its mixins, implicit metaclass (eigenclass), and dynamic nature (ie. class definitions are just executable code), and standard functional features like lambdas w/ closures are all designed into the language in a very elegant way and this basic model has been more or less stable for the nearly 20 years of ruby's existence.
This means ruby code has a more consistent style and set of powerful idioms over time. Obviously there's a lot more shit ruby code getting written these days then there used to be, and modern PHP has a ton of power that can be leveraged very elegantly. However if you look at the corpi of popular open source ruby code vs popular open source PHP code over the years, you find a much higher bar of quality in the ruby code. Some of the attraction to the average rubyist is aesthetic, but that's not the whole story.
Every major PHP framework uses both namespacing and closures.
> The ruby OO model with its mixins, implicit metaclass (eigenclass), and dynamic nature (ie. class definitions are just executable code), and standard functional features like lambdas w/ closures are all designed into the language in a very elegant way and this basic model has been more or less stable for the nearly 20 years of ruby's existence.
What you're describing here is the difference in the language itself. The PHP OO model is more traditional and Java-like, but that doesn't implicitly make it worse or behind the times.
> However if you look at the corpi of popular open source ruby code vs popular open source PHP code over the years, you find a much higher bar of quality in the ruby code.
I can't speak for the Ruby side, but on the PHP side you couldn't be more wrong. The open source efforts in PHP in the last 5 years have been nothing short of excellent. The open source PHP community has completely adopted the full range of PHP features, unit testing (TDD and BDD), and coding standards (https://github.com/php-fig/fig-standards/tree/master/accepte...). This is nothing new and it's been like this for a while.
No True Scotsman argument.
> The PHP OO model is more traditional and Java-like, but that doesn't implicitly make it worse or behind the times.
I don't care for fashion, so "behind the times" is neither here nor there, however a Java like OO model is definitely worse on most axes except foot-shooting and style-uniformity for large teams. If I want strong typing I want a system that leverages its power such as Haskell, not something like Java where compilation errors are mostly trivial things and I still end up with null pointers all over the place which is exactly the same as the most common type of error in more powerful dynamic languages. Beyond that, saying PHP OO is like Java is doing PHP a huge service because Java started out as OO with quite a strong vision. It may not have been perfect, and it's certainly developed its warts over time, but the seed of conceptual integrity in Java's OO is an order of magnitude more robust than PHP's.
> I can't speak for the Ruby side, but on the PHP side you couldn't be more wrong.
I was specifically making a comparison between PHP and Ruby. Making a one-side claim is a nonsensical response.
Kind of, but not really. The two major framework players in the PHP space right now are Zend Framework 2 and Symfony 2. This isn't really a "No True Scotsman" argument because both are headed up by reputable development shops (Sensio and Zend). Both use namespaces.
> I don't care for fashion, so "behind the times" is neither here nor there, however a Java like OO model is definitely worse on most axes except foot-shooting and style-uniformity for large teams. If I want strong typing I want a system that leverages its power such as Haskell, not something like Java where compilation errors are mostly trivial things and I still end up with null pointers all over the place which is exactly the same as the most common type of error in more powerful dynamic languages. Beyond that, saying PHP OO is like Java is doing PHP a huge service because Java started out as OO with quite a strong vision. It may not have been perfect, and it's certainly developed its warts over time, but the seed of conceptual integrity in Java's OO is an order of magnitude more robust than PHP's.
Err, what? I'm not sure if I'm misunderstanding you here -- because PHP didn't have OO designs early on somehow that makes it's OO model less robust then Java's? I'm not going to bother arguing that point, but it certainly doesn't make me a less efficient developer. PHP's OO model is more than adequate for most web applications. I'm also not following the null pointer issue. Proper unit testing should vet null value issues out whether you're using a dynamic language or not. PHP has the (arguable) advantage of not completely shutting down when this mistake occurs.
> I was specifically making a comparison between PHP and Ruby. Making a one-side claim is a nonsensical response.
Not anymore of a one-sided claim than your own. You haven't done a lot of research into what's going on in the "popular open source PHP code" if you think your opinion is two-sided -- I'd strongly challenge you to point out what popular modern open source PHP code is inferior to popular modern open source ruby code.
The prejudices I have against Drupal are the result of my experience of it starting as far back as version 4. I don't believe they are unfounded.
I'm currently investing moving our sites (a network with 1M+ visits/and 12M+ pageviews) from Drupal 6 to Rails.
We have a large amount of custom code (I've written 20+ modules for this platform), and yet we've gotten to a point where we really want Drupal (and PHP) out of our lives, because it isn't worth the headaches anymore.
When I first started out I actually wasn't using CCK or Views 2, I was creating new node types with a custom module, and if I were to go back to Drupal now I would be sorely tempted to do this again. Views was a bit too fragile and the queries it generated were horrific, and I think if you can code and know PHP and MySQL well they really give you very little value, or possibly even work out slower overall.
This does not say much about Drupal being good in absolute terms. It only tells us the obvious point that Drupal is a lot better then your old application.
What you state would have been just as trough had you developed in Rails, Django, and maybe even in PHPnuke. What you don't state, is why Drupal was the better fit compared to modern alternatives. Is it?
I don't agree with your suspicion that big shops are hacking core and building custom CMSs upon Drupal in a vain effort to try and gain source control features. Rather... I'm aware of big shops sticking to Drupal bets practices and using Features, Strongarm, Plumber and other modules to get configuration into code and keep it source controlled.
If Drupal deployment were the nightmare you s=describe, then the phenomenal adoption of Drupal that we see today would make no sense. Why would the Georgia Tech Authority decide to move SIXTY-FIVE sites off of a Oracle, Java, Vignette solution and onto Drupal? Well.. It is isn't because they like nightmares during deployment.
Drupal is growing up. The issues that plagued us 5 years ago when I got involved are being solved with varying degrees of success and effort. We're not where we want to be but the market is eating us up. We are bullish about our future and know that out continued improvement will only serve to better our position as the leader that we are in the web space.
Doug Vann [Drupal Trainer, Consultant, Developer] http://dougvann.com
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.
If you install a module for every piece of functionality soon you'll end up with a huge codebase and the hell the author is describing.
That said, I wholeheartedly agree.
Did Drupal dev for 2 years, and my biggest takeaway was: Don't go around installing custom modules for one dinky feature. Wrap it up in your own custom module.
Less dependency hell to deal with, and not only that, you'll have a much easier time debugging code you wrote yourself.
I don't think it's fair to look down on people who use Drupal as it's meant to be used.
The nitty gritty is that we use it in an environment where we basically have 2 teams. One that builds custom code/modules that can be installed and enabled in Drupal to add additional functionality and another that actually deploys sites.
The team that deploys sites is savvy, but are not hardcore developers. The thing I've come to over all these years is that Drupal's pluggability still makes it the most powerful tool for what most people use it for -- deploying websites.
I have often surveyed the landscape and thought, "why not just build this in another tool like Rails or Django" and I always come back to it in much the same way the author of this article does -- while those are much more beautiful development frameworks, they just don't have the mojo that Drupal does.
This is likely best illustrated by example. This may or may not be based on a true story ;) Let's say I develop a custom application to interact with my company's backend database products which, let's say, are for events management. Now I pass that custom application off to the site builders who will actually customize that application for each of our hundreds of clients.
(1) The client wants a Google map of all their events
(2) The client wants the Events displayed on a calendar
(3) The client wants Events to filter by Event type
(4) The client wants a tag cloud or something else totally unrelated to the Events system
Built in Rails (Total additional developer time to add these features: 400+ hours)
(1) Damn, back to the drawing board, we need 100 more hours of dev time to develop a custom component to convert the locations into actual location data (lat/long) and display it on a map. We need to interact with the Google Maps API and write the code that will communicate with them via an API key and handle everything.
(2) Damn, back to the drawing board, we need 250 more hours of dev time to build a calendar and ensure we get the layout correct, handle a bunch of special cases (what if there are too many events to display on a single day, some months have 4 rows of weeks, some have 5, etc.)
(3) Developer has to add a form element to take that event type and modify a query to enact that filtering and load the results on a new page. Not a ton of dev time, but dev time nonetheless.
(4) Cross fingers that there is a Ruby Gem for this. Otherwise damn, custom development.
Built in Drupal (Total additional developer time to add these features: 0 hours)
(1) We never heard back from the site builders because they installed the Drupal modules Views, GMap, Location, and were able to create the map themselves from our custom Event data and clicking on the right buttons
(2) Again, the developers never heard back from the site builders because they installed the Drupal modules Views, Calendar and were able to show those events on a calendar.
(3) No developer time because the site builder went into the Views settings and added an Exposed Filter
(4) Site builders install the cloud tag module or the random feature X module, custom developer time rarely needed.
Now let's scale it up, instead of 1 client you have 500 and each want slightly different things. One wants to filter by Event type, one wants to filter reverse chronologically by date. One wants a calendar with a month view, one wants a week view. One has a ton of events and wants a day view. With Drupal, these are all just settings on existing, already built modules. With Rails/Django/Node.js/etc. these all require more dev time. Now of course things could be designed intelligently and parameterized to limit some of the DRY, but there is still dev time required to implement all these different permutations or up front complicated system design to create an architecture that can be configured as richly as a Drupal module developed over years by a community.
I work in Drupal professionally, but play in Rails, Django, Node.js, even Meteor every chance I get because they're so fun and beautiful but at the end of the day I still think Drupal is the right tool for our job in spite of its long list of flaws including its base language, the always horrifying PHP. But it freaking works.
tl;dr This article rang more true than I could have imagined it would. Thanks mcrittenden!
"Built in Rails (Total additional developer time to add these features: 400 hours)
(1) Damn, back to the drawing board, we need 100 more hours of dev time to develop a custom component ...
(2) Damn, back to the drawing board, we need 250 more hours of dev time to build a calendar and ensure we get the layout correct...
(3) Developer has to add a form element to take that event type...
Built in Drupal (Total additional developer time to add these features: 0 hours)"
The thing about a programming language that allows for meta-programming is how easy it makes it to stitch together the code you need from components. Ruby is very good in this regard, and also any Lisp would be good in this regard, and my new favorite is Clojure, which is exceedingly excellent in this regard.
I had worked with Rails in 2006, then taken a break from it, then came back to it. I just worked on a very big Rails project in 2011. One thing that surprised me was how little code I had to write. All of the functionality that we needed was in a gem, and we only had to write a few lines of code to customize the operation of each gem. Need to integrate events with a map? There is a gem for that. Need to add slugs to all articles and have them become the id that appears in the URL? There is for a gem for that. I would write maybe 10 or 20 lines of code for each gem, telling it how to interact with our application.
To be productive at Rails, you have to know what gems are out there. You need to keep up with the gems, because they really are central to the productivity boost you can get from Rails. There is a gem for almost any bit of functionality you need, you only have to know which gems are good. If you find yourself writing large amounts of custom code in Rails, then either you are truly tackling a novel problem that no one has ever dealt with before, or you are simply unaware of the gem that you should be using.
Your comments comparing Rails and Drupal surprises me. I feel like you are writing without realizing how Rails development is done.
This made me smile:
:%s/Rails/Drupal/g
:%s/gem/module/g
"To be productive at Drupal, you have to know what modules are out there. You need to keep up with the modules, because they really are central to the productivity boost you can get from Drupal. There is a module for almost any bit of functionality you need, you only have to know which modules are good. If you find yourself writing large amounts of custom code in Drupal, then either you are truly tackling a novel problem that no one has ever dealt with before, or you are simply unaware of the module that you should be using."
First, no offense taken.
Next, I do have a fair amount of experience developing in Rails (it's my go-to hobby framework and I MUCH prefer developing in it to Drupal as I thought I imparted in my original comment) and yes, there are gems that get you most of the way there with some of the tasks I described, but our site builders (read: non-developers) are unfamiliar with the command line, could not generally install gems without intervention from developers and, if necessary, could not extend them without developer intervention. That is what I'm trying to describe.
With Drupal, people who interact only with a web browser can install rich components from a library of modules developed by others with integration with the Content Types (basically the equivalent of Rails Models in Drupal) with zero development.
Looking back at my original comment, arguably my time estimates for development were exaggerated to some extent and could be shortened with the use of gems, but the fact remains there is, at current, no way for users, through only a web browser, to enable that kind of rich functionality in Rails. That was the point I was trying to get across.
You don't have to write much code but you still have to write code. This makes it a non-starter for a particular class of user.
> If you find yourself writing large amounts of custom
> code in Rails, then either you are truly tackling a
> novel problem that no one has ever dealt with before,
> or you are simply unaware of the gem that you should
> be using.
The language that has the libraries I need is always the one I end up using.
1. The client wants a google map of all their content 2. The client wants the content displayed elsewhere too 3. The client wants to filter the content by type 4. The client wants a tag cloud 5. The client gets what they want quickly by using drupal and is happy. ... 99. The client wants to change the google maps module to act slightly differently, but this turns out to be very difficult, and their developer takes days to make very simple changes. 100. The client is complaining that their website is slow because it loads over 200 drupal modules, but they need them all. 101. Some code is the db, and some on disk, which makes it very difficult to trace execution. 102. The client can no longer update their drupal as half of their modules are no longer maintained, and they're at the mercy of the module developers to do so, this causes problems using new modules which expect a newer drupal. 103. New developers can't get up to speed because the code-base is so convoluted and the database contains over 200 tables with a byzantine structure caused by drupal's over-abstraction of content types - the client runs through a series of several drupal developers and bleeds money with no significant changes to their site and lots of bugs left unfixed. ... 200. The client gives up and starts again with a site rewrite using another framework, and curses the day they were introduced to drupal.
The up-front development cost may sometimes be lower with drupal (though for many sites I would dispute that, most frameworks make it a matter of minutes or at most hours work to add a tag cloud for example, or add a map, with the advantage that you don't have to use a module to do it), but unless you are very careful and stick with one developer, the huge technical debt you're taking on by using it doesn't justify that. The fact that the developers ever thought it was a good idea to store code and views in the db is a huge red flag, and is a huge temptation to some developers and/or clients to produce a huge complicated, unmaintainable mess. Even if you try to control this it doesn't ledn itself easily to separation of concerns.
I'm sure it's quite possible to produce clean websites with drupal and keep them under control long term, but it's not the pattern of the sites I've seen, and I don't think it really gives you so much more in the longer term over developing in simpler frameworks which don't try to prescribe as closely how the content is structured.
Both parts of that process are equally valuable.
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.
http://nodeone.se/sv/learning-library
or drupalize.me:
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.
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.
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.
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.
"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.
I say "almost top end" because I am not including places like Google, where the top engineers make a lot more. I think my numbers are accurate for the vast majority of corporate jobs in NYC right now -- I get contacted by a ton of recruiters so I have a decent sense of the current situation. But I realize there is a small elite of tech companies who hire the highest elite of programmers, and the salaries there are probably above what I am seeing.
Although I don't know many successful developers who explicitly sell themselves as "[Framework] Developers". More often than not, when shooting for a higher rate, it seems to sell better as someone who provides a full solution, which May include specific frameworks if necessary.
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?
IE - customers you don't really want to be stuck with in the first place.
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.
http://www.acquia.com/customers
Just one subset, of course. Doesn't include customers of other major vendors.
Drupal is fairly big here in Scandinavia, and it's my distinct impression that it's the same story all over Europe. It has a strong footing within online media that seems to grow every day.
I suspect that if I moved to another country, or even abroad, I wouldn't have much difficulty finding a different (high paying) job related to Drupal.
Also, if you're US based and like great community oriented dev houses: www.acquia.com, www.lullabot.com or www.palantir.net.
Of course, they also want superb design and UX so things usually end up going over budget as we have to hack the hell out of Drupal to match the level of UX desired. Every single Drupal project I've worked on I've wished I could be using a real framework and code from scratch instead.
Unfortunately I don't see the perception of digital agency project managers changing much. They still think they can get the best of both worlds.
Sounds like more developers who need to dramatically raise their rates. I'm in NYC and I charge more than double that for iOS development. I sit next to a good freelance PHP guy charging $85-95 / hr who is slammed with work, ironically mostly for Wordpress. He should be charging more, but he's getting there :)
And the top Rails devs in NYC are definitely charging way more than that; I know guys doing $150 / hr and up.
As Drupal matures and become even more complex beast I expect my rate become even higher in next 1-3 years.
So, yes - Drupal is paid well now, but no - not basic clicking around and basic theming.
The big name Drupal shops in DC are constantly hiring and are shelling out something like double the average PHP developer salary for experienced Drupal developers. More if you're good enough to contribute to the core project.
I'm telecommuting for one of these shops and making over double the local average wage for PHP devs. If I wanted to make more cash in this area I'd have to either take a management position or start coding .net
For reasons that are mysterious to me .net developers in my area are making (on average) 30-50k+ more a year than developers at a similar point in their career, but coding in different languages.
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.
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:
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.
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.
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. :)
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.
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.
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.
If everyone blows a little more energy back into the Drupal project, it'll suck a lot less ;)
That's also why Drupal has huge amounts of contributed modules and developers. Lots of people who do just that. Drupal is the Linux of the CMSs.
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.
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.
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.
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.
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.
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.
Except that ... you know ... people have heard of Drupal.
Needless to say, a month and a half into the project we dumped Drupal.
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 RAD-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.
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.
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.
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.
But I have had my fair share of "WTF?" and "Damn it, Drupal!" moments. That much is true.
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.
I think it might be the price you pay for using a "framework". 80% = really easy, the remaining 20% is a git.
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
Or maybe Word with macros.