create a way to back out of unintentional / unsupported active config changes [#1821306]

in the review comments by webchick over in #1697256-73: Create a UI for importing new configuration, it became clear that we need a way to handle cases where site builders may overwrite the active config directory with changes without going through the import step.

currently, we have no good way to warn or back out of this process. lets figure that out here.

Comment	File	Size	Author
#2	1821306-2-config-snapshot.patch	2.21 KB	Anonymous (not verified)
#2

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Anonymous (not verified) CreditAttribution: Anonymous commented 24 October 2012 at 00:25

so it turns out if we want to make a hash of config files for backup, then we should prolly pass them through config() when we install / import them. else we need to make the storage controller smart, which is prolly Not The Right Way.

i just hacked up a quick PoC patch, and noticed that we're missing a whole bunch of snapshots, because when we install, we just operate directly with the storage controllers.

why do we do that again, rather than use config('foo')->save() ? i can't remember.

Comment #2

Anonymous (not verified) CreditAttribution: Anonymous commented 24 October 2012 at 01:06

Status:

Active

» Needs review

File	Size
1821306-2-config-snapshot.patch	2.21 KB

so here's a PoC that creates snapshots. note that i had to change the way we do config sync stuff to use config->save() etc.

Comment #3

24 October 2012 at 02:57

Status:

Needs review

» Needs work

The last submitted patch, 1821306-2-config-snapshot.patch, failed testing.

Comment #4

damiankloip CreditAttribution: damiankloip commented 25 October 2012 at 08:08

Issue tags:

+VDC

Tagging, as this could be what we were thinking of trying to do for views/config anyway.

Comment #5

Anonymous (not verified) CreditAttribution: Anonymous commented 3 November 2012 at 22:56

not working on this anymore, please don't wait for me.

Comment #6

sun

German

Karlsruhe

CreditAttribution: sun commented 3 November 2012 at 22:58

Priority:

Major

» Normal

Meanwhile, I think we should simply revert the default storage for active config back to the database (or any other k/v storage).

Allow informed developers to override that default and use files instead, but don't make it the default.

Comment #7

moshe weitzman CreditAttribution: moshe weitzman commented 16 November 2012 at 18:32

I like that Active uses filesystem. This is most transparent and learnable to people. It also lets them use diff, git, and other filesystem tools. IMO, the fact that some folks are uninformed or reckless does not justify "hiding" this data in k/v or DB.