Allow single config files to be imported and exported (Resolve regression from Views in Drupal 7)

Just did a little bit of manual testing:

• 4 Tabs for all export/import and single export and import is a bit weird
• I exported a view and imported the same one ... and no validation got triggered ... this is kind of a regression to d7
  There it was possible to give another name ... so maybe we have to provide such a entity ID import textfield?
• Most of the time actually the UUID will clash (it did not as glossary did not had a UUID by default)
• There is no link in link in the actual views UI to export/import but yeah this could be a followup

1. +++ b/core/modules/config/config.module
   @@ -87,6 +87,20 @@ function config_menu() {
   +  );
   

   Do we really still need to add old style tabs?

2. +++ b/core/modules/config/lib/Drupal/config/Form/ConfigSingleImportForm.php
   @@ -0,0 +1,167 @@
   +    // For a config entity, create a new entity and save it.
   +    else {
   +      $entity = $this->entityManager
   +        ->getStorageController($form_state['values']['config_type'])
   +        ->create($form_state['values']['import']);
   +      $entity->save();
   +
   +      drupal_set_message($this->t('The @entity_type %label was imported.', array('@entity_type' => $entity->entityType(), '%label' => $entity->label())));
   +    }
   

   As written I guess it would make sense to be able to specify the ID of the new config entity.

3. +++ b/core/modules/config/lib/Drupal/config/Tests/ConfigSingleImportExportTest.php
   @@ -0,0 +1,96 @@
   +  public function testImport() {
   ...
   +  public function testExport() {
   

   Just in general I think it is odd to never ask the entity manager whether the stuff was really created.

I don't think so. This very nicely shows that encode / decode is doesnt even belong to the config storage interface. It needs to be moved to a staging (or whatever we call it) interface and then filestorage can implement that and be happy about it. If you switch the active store to a redis / mongodb / heck mysql w/ php serialize store what do you expect from encode ? Nothing normal. Conversely, the staging storage shouldn't be a service but should be hardwired to the YAML FileStorage we have pretty much the same as modules are phptemplate wired in D7 and for the same reasons.

Edit: we can hardwire it into a method in ConfigFactory or something.

Not looked at the code, but here's a UI review. This patch makes me very happy!!! :D

I'd put export first, then import, personally. That's the logical progression people will do.
I'd also put full ahead of single, since most of the time that's what people should be doing.

Let's alphabetize this list. It's bound to get even longer when contrib modules are added, so finding things will be an issue otherwise.

Can the "what's happening here?" message be moved to the white area, rather than the title, so it doesn't get cut off?
Also, can we kill the import/export tabs from here? That's strange.

Not sure if this is true for other things, but for Blocks anyway, we need some kind of disambiguation between the two "System help" blocks. "System help (Bartik)" vs. "System help (Seven)" for example.

Since "Configuration type" on import dictates which API functions are called, it's important that it's set correctly. How about set it to nothing by default and make it required, so people are forced to make a choice?

+++ b/core/modules/config/lib/Drupal/config/Form/ConfigSingleImportForm.php
@@ -0,0 +1,243 @@
+  protected $configExists = FALSE;

The variable name is a bit odd. I think $config would be a bit better. A value set to FALSE is pretty clear all the time.

I'm going to be looking at this one today and testing it thoroughly

Let's start with a reroll

(I got distracted a lot today.) This looks great to me. I have tested most of the scenarios I can imagine and have not encountered any errors.

I was thinking about adding an export button for the single file export (admin/config/development/configuration/single/export), but I'm wondering if that was left off intentionally because the export file can be altered?

This one needs a reroll after the local task conversion - started looking into it but got confused and completely distracted.

Would love to test this with fields and instances .. :)

Did some tests with fields. Importing gave some problems

The Field(Instance)StorageController::loadByProperties() assume some extra keys - since we were the ones always calling them, those were always ok. (edited)

Importing something illegal gives a nasty error

Made changes to the field storage controllers and added a try/catch to the import of a config entity to catch the exception and show a more friendly message.

It now comes back to import screen. Since we're in the submit, I wasn't sure how to preserve the data; rebuild gave me back the confirm form.

This is ready to go. Applies cleanly. Code looks good. Tested exporting/importing image styles, text formats, and more.

This will definitely benefit from some scary "Are you sure you want to import this config and risk totally breaking your site?" warnings to be provided in #1831798: Update hook_help() for config manager module .

Sat down with Tim at BADCamp to test this sucker. Overall this both looks and works kick-ass! :) Since this is fixing a regression, it seems to belong as at least a major.

I found a few things while testing:

1) (minor) The options were alphabetized on import, but not on export. Tim fixed that in his latest re-roll.

2) (major/critical) I did something where I copied node.field_tags, and fiddled with it to make it user.field_tags instead, but hit a couple of errors on the way (duplicate UUID, duplicate machine name), but the error I ended up with was that the user_field_tags table already existed. :\ This means that you can currently get into a situation where an entity->save() half-finishes, which needs to be fixed. However, that has nothing to do with this issue, it was merely exposed by it. Will file a follow-up for it.

3) There were some minor UX-ish things, like for example on import you've now lost the name of the file that you had in the export screen, but after talking with Tim, there wasn't really a great way to solve this. Embedding the filename in the YAML output, for example, would make it so that these weren't easily portable. We also discussed the order of the tabs, because this patch makes *single* import/export the second tab after Synchronize. Between Jess, Alex Pott, and Matthew Tift, we couldn't come to consensus on what the order should be, so we decided to just leave it, since it's super easy to change later once we have more user feedback.

So, with that, I'm officially out of things to complain about. :) Sooooo...

Committed and pushed to 8.x. WOOHOO!!

added the hook help