Drupal and configuration, a non developer point of view

When I look at the current state of configuration storage in Drupal, I cannot stop myself of saying, what’s this monster?

I’m not a developer, so bear with me if my explanations are not 100% correct. This is the point of view of someone moderately comfortable with drupal concepts, with an artistic background.

What we have now

Drupal has always been storing configuration (views, variables, content types definitions, website timezone, whatever) in a database.

Then somebody discovered that it was hard to sync between a development and production server, the workflow was painful.

Also, reading tons of configuration information's from the DB was a performance hit (where the data could be already parsed and cached in memory)

Then the features module was born. As I see it, it allows to store configuration in text files (php?) and allow to sync this to the database. those settings can be overridden in the DB by the user, but in this case you loose connection to the original configuration (for example, a preconfigured view).

The result : DB <> files : impedance mismatch.

What a mess. Somebody had to say it.

So, the question is, why was the configuration put in the DB in the first place? It was probably a good idea in the beginning, but now we see how painful it is. I don’t want to repeat what has been already said multiple times, much better than by me.

I tried to think about it, and wanted to give a concrete, even if incomplete, proposal on how I would try to solve this (with the "I'm not a developer" disclaimer).

(sort-of) proposal

/sites/all/config -> stores all the default configuration for all sites (for example, views that could be used by multiple sites)

/sites/usersite/config -> stores all the configuration for a specific website + overridden defaults from sites/all

/sites/all/module/views/config -> provide default views from the views module (can be samples, views needed by core, whatever)

Then merge all those settings in a single big array. Do it in the right order, first sites/default/config, then sites/all/config then sites/usersite/config . Just like the theming system does it.

Want to revert to the default view provided by the view module? Simply delete your custom view configuration. Want to keep your custom view config but only for one website? Move it into the config directory of this particular website.

When you will update your installation, the views module may provide a new default view. It will be used directly by the sites that didn’t overwrite it, without anything more to do.

You can put all this in version control. You can move files around to choose the inheritance order of your config files, to share config with a coworker, between websites in a multisite setup. Between dev, staging and production.

I hope this could help a bit. I know this is being discussed, but when I read the discussion on which file format to use for configuration store, I fear that the big picture may be lost somehow.

This long proposal to ask you one thing : Keep it simple. Don’t add 3 more layers to an existing complex subsystem in Drupal 8. Please ;-)