Entity Import/Export UI

Looks good. However, what's the purpose of having export without an "import" page? I guess we should only add all at once, as the UI is already used by modules. Probably we should do it like views in d7, provide another action link for creating new entities by import.

+            '#rows' => count(explode("\n", $export)),

Let's set this to a fixed, but high value.

+      @eval('$import = ' . $form_state['values']['import'] . ';');

This won't work generically, e.g. Rules implements an export using JSON. I guess the entity API misses an entity_import() function + a respective entity controller method.

hm, also eval() is problematic as we need to implement a new "eval php" permission for that. Perhaps we should just stick to the json export by default? The entity API has already an API function to print beautified JSON.

An option like views has in 7.x would be nice too. "checkbox: Allow overwriting existing configurations" or such.

Results of discussion: We really need something like entity_import($entity_type, $export_code) - which takes the export and returns an entity as expected by the default hook. For security, we go with JSON by default.

related: #978832: enable modules to apply configuration (exportable entities)

+          '#description' => t('If checked, any existing %entity with the same ID will be replaced by the import.', array('%entity' => $this->entityInfo['label'])),

Let's use "identifier" instead of ID.

+            '#description' => t('Copy these data and paste them into the import page, to import.'),

These or this data is the question.. ;)

+            form_set_error('import', t('Import of %entity %label failed, a %entity with the same machine name already exists. Check the overwrite option to replace it.', $vars));

I think it should be @entity, as it makes not much sense to me to mark entity as a placeholder. For the label though it does. It is already that way in the existing code though, so this should be probably another issue.

The logic in operationFormValidate()looks a bit complex to me, perhaps it can be simplified? Not sure.

reset(entity_load($this->entityType, array($id)));
This will produce warnings or notices on some platforms as reset() takes the argument by reference.

-    return "entity_create('$this->entityType', " . entity_var_export($vars, $prefix) . ")";
+    return entity_var_json_export($vars, $prefix);
+  }

Previously the return was valid PHP but that changed now. We need to document what entity_export() is supposed to return.

+    // Menu item for importing an entity.
+    $items[$this->path . '/import'] = array(
+      'title callback' => 'entity_ui_import_title',
...

We may only add this menu item if the entity is exportable.

Looks good, I gave it a test with profile2.

When export the default profile + importing it with overwrite enabled I got:

Error message
Notice: Undefined property: ProfileType::$id in EntityDefaultUIController->applyOperation() (line 398 of /var/www/drupal-7/sites/all/modules/entity/entity/entity.ui.inc).

Then I got the message:
>Imported Profile type Profile.
-> but profile type should start lower case there - that applies to any sentence where it is not in the beginning. I wonder though how that is supposed to work for translations?

>entity_ui_import_title()
This seems to somehow duplicate entity_ui_get_page_title() ?

>applyOperation() + others
It's getting increasingly confusing which operation is handled by what, in particular with import+export being sometimes handled by the same functions, but in sometimes not (applyOperation). I guess we should document that better.

great! Committed it, thanks!

See #981786: UI: bad casing of translation replacements for the text follow-ups.