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.

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

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").

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

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

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.

Yeah, those non-developer's you're talking about? Most of them have no idea how to change a view, because changing a view is pretty much just as complicated as coding a SQL query. If you understand how to modify a view, you probably can write an SQL query.

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.

Our clients know it pretty well - it's all about education. The button's called "revert" for a reason, and it's placed pretty prominently on the page.

When we removed the fear of fucking up, they started learning.

Genuinely curious: your clients hack around with Views on their on production site?

I'm not sure whether I think that's insane, or whether I'm simply very jealous of your clients.

Not all clients. Clients are different of course! Should something break it would be immediately obvious, and not all are prepared for that (obviously!).

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

Not that I know much about Drupal, but isn't it inevitable that stuff that can be changed via the UI (sometimes even per user) has to live in the database? This is simply a consequence of blurring the lines between developers and users, which is exactly the point of CMSs.

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.

Drupal's Features module tends to use this pattern:

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.

I do this all the time:

  drush up feature_name
  git commit -a

this gives you a nice diff of the config in production v's code.

  drush fd feature_name

sometimes i really need to make a fix in production (or its so trivial the overhead of a release would be just silly), make the change on production, then grab fresh db dump, stick it on dev box and run "drush up". today i did this to remove a link from a field in a view.

woops... "drush up" should be "drush fu"

On a site that is version controlled and has a QA workflow for changes, you simply disable the UI for changing those things on production, and the only way to influence them is by committing the changes exported as code and deploying.

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.

Typical Drupal FUD.

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

Views, specifically, have been exportable into version-controlled code since Drupal 5, and the ability to do so is a prominent feature in Views v3 for Drupal 7. Indeed, the Feature module, which spearheaded the current effort to make every Drupal configuration setting expressible in version-controlled, script-deployable code, is based on a pattern invented by Views years ago.

Exporting views to code has been shaky at best. And worse: once it's exported to code, there is no way to only import the bits that have changed. You must recreate the whole thing anew.

That's not version control, that's an export function.

All of the configuration for my Drupal sites DOES live in a VCS (it just doesn't have to, and many people don't bother).

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.