I've prepared a patch, which integrates Field Collection module with UUID.

My only concern was regarding placement of new code into uuid.core.inc, as the module is not actually a part of the core, but since some other contrib modules are already there, that shouldn't be a big deal. Or at least, you as module maintainer can always put them in additional include if you decide that it's time to separate the code.

Comments

neochief’s picture

In addition to this patch, #1429596: Field Collection fields support also requires to be committed so that integration start working.

dixon_’s picture

Looks interesting. I think it could be a good first step to place it inside uuid.core.inc. I don't see any real problems with that. If we implement them on behalf of that module (using their namespace) it will be simple to move it over to the Field Collections module later on.

One thing though, can you explain more about what this is:

+      // Convert entities to array to avoid having them in JSON returned from standard implementation of $entity->export().
+      if (is_object($entity) && method_exists($entity, 'export')) {
+        $entity = get_object_vars($entity);
+      }

I guess it's from Entity module's own export functionality. But why do we need it here, actually?

neochief’s picture

If you'll use standart export to JSON like this:

      $export = '  $entities[\'' . check_plain($plan->name) . '\'][] = entity_import(\''. $entity_type ."', '";
        $export .= addcslashes(entity_export($entity_type, $entity, '  '), '\\\'');
        $export .= "');";
        $code[] = $export;

entity_import() will try to save entities to database right away without using entity_uuid_save() which causes critical errors. So, the most obvious way was to get rid of standard export and render it as array.

vladsavitsky’s picture

Thank you. I need Fields Collection support!

neochief’s picture

Status: Needs review » Closed (fixed)

Commited!