Convert views settings to config

Tagging. At a glance it looks good.

Since system_settings_form() is used for those, wouldn't it make sense to wait for #1324618: Implement automated config saving for simple settings forms to get done first? Then use the API that gets defined there?

I'm happy to simply not use system_settings_form anyway. The convenience isn't worth the opacity, I've found.

Yeah, I agree with #6.
We can just kill system_settings_form() and then commit what's here.

+++ b/drush/views.drush.incundefined
@@ -234,19 +234,22 @@ function views_revert_view($view) {
+    ->set('views_ui_always_live_preview', TRUE)

Shouldn't this be FALSE?

This needs an hook_update_N to migrate the settings, no?

Oh I guess I just didn't run it.

+++ b/config/views.settings.ymlundefined
@@ -0,0 +1,23 @@
+views_display_extenders: []

I think that should be views_display_extenders: { }. It was erroring out, so I ran config('views.settings')->set('views_display_extenders', array())->save(); manually from devel and that's what it produced.

With the exception of the extra newline at the end of views.settings.yml, this works great. Remove that before committing, please.

Looks like this is ready to go. It is missing the YAML file again though.

Just tested this, works great! looks good to go to me.

This broke a lot of stuff :)
This kinda patches need a "grep review" before committing ;)

New version small fix and fixed a test

+++ b/lib/Drupal/views/Tests/UiSettingsTest.phpundefined
@@ -0,0 +1,144 @@
+    // Configure to not always show the master display.
+    // If you have a view without a page or block the master display should be
+    // still shown.
+    $view['page[create]'] = FALSE;
+    $this->drupalPost('admin/structure/views/add', $view, t('Continue & edit'));
+
+    $this->assertLink(t('Master'));

This doesn't make sens at all :D. You're saying you're goin to set the "show always master diplsay" option. But you don't do that.

This still fails but for the correct reasons ;)

That assertLink stuff doesn't work. In the verbose output I can see the link appear and dissapear but it always sthinks there isn't a master link... Stupid assertions...

Another problem, the upgrade path stuff is changed in core you *need* to define the entire mapping array.

Should the views ui settings be separate from views? Since they are two modules.

If the variables are only used by the views UI. Than yes :).
But we need to place the UI module first in a seperate folder.

IMO no, they should not be separated.

merlin any reason not to seperate? Besides personal preference.

The UI is a separate module only for the convenience of being able to globally disable the UI. Separating the settings is simply a hassle; the code is barely separate (most of the UI code is in includes/admin.inc for example).

Just a fix for one of the test that fails in the last patch.

The patch applied fine, and I could run the test, and everything looked greenish:

96 passes, 0 fails, 0 exceptions, and 36 debug messages

This is the ViewsAnalyze test.

Here it is the Glossary test.

Don't we want the tests in #37 and #39 in the same patch?

Actually, those patches belongs more to the "convert to PSR-0" issue than this about the config.

Is there an issue for it? If so, shouldn't they be on there? :)

#1637532: [META] Convert existing tests to PSR-0

Missed one (my least favorite setting!)
There are no other calls to config() in that function, hence the direct call.

Looks good