Provide a Field Collection UUID module to support UUID/Deploy

Thanks! It worked for me. This together with https://drupal.org/node/1670740#comment-7647431 allowed me to export and reimport nodes with field_collections using node export.

I needed to use this in a server with php 5.2 and it turns out that anonymous functions are only supported in php since 5.3. Here's an updated patch that replaces the array map in line 44 of field_collection_uuid.module with a foreach loop.

This is great so far, but there are some issues. Here is an updated patch to address some of them.

- General cleanup to address coding standards issues.
- Remove the __uuid_universalized property on hook_entity_uuid_load(). It doesn't appear to do anything.
- Remove the constructor from UUIDFieldCollectionItemEntity. Its just calling the parent constructor, so there isn't really a need for it.
- Remove $this->revision = TRUE from UUIDFieldCollectionItemEntity::save(). It was forcing every save (when the hostEntity is absent) to create a new revision which should not be necessary. And without it field collection items with revisions appear to deploy correctly anyway (in my very simple testing anyway). Revision support should be tested more thoroughly by someone who actually uses revisions.

Also there are some PHP notices in the log after deploying field collections with this patch. The following sound similar to #1774914: Notice: Undefined property: CommerceOption::$option_id in drupal_write_record() includes/common.inc.. It isn't clear why these are happening. It looks like property_exists() is returning TRUE for properties that don't exist. This doesn't happen in a normal field collection save, so it should be investigated more:
- Notice: Undefined property: UUIDFieldCollectionItemEntity::$item_id in drupal_write_record() (line 7049 of /includes/common.inc).
- Notice: Undefined property: UUIDFieldCollectionItemEntity::$revision_id in drupal_write_record() (line 7049 of /includes/common.inc).

And these appear to be due to this issue #1780646: entity_access() fails to check node type specific create access, so probably not relevant to this patch.
- Notice: Undefined property: stdClass::$nid in entity_metadata_no_hook_node_access()
- Notice: Undefined property: stdClass::$vid in entity_metadata_no_hook_node_access()
- Notice: Trying to get property of non-object in entity_metadata_no_hook_node_access()
- Notice: Undefined property: stdClass::$nid in node_access()

I would also suggest that it would be a good idea to move the field collection services code from UUID into this submodule as well. This seems like a much more appropriate place for it.

The patch in #3 appears to not work properly with the deployment of subsequent changes (revisions) to field collection items. I haven't dug into why yet, but my guess is it's the change in field_collection_field_uuid_presave()

*edit*
Just noting that the original patch works as expected.

Thanks for testing that jrbeeman. It is almost certainly the $this->revision = TRUE from UUIDFieldCollectionItemEntity::save() in the original patch that allows revisions to function correctly on subsequent changes. But that seems like an inappropriate, hacky solution. It essentially just forces every save to be a new revision regardless of whether or not it is actually necessary to have a new revision.

So the patch needs work, but it needs a better solution than the one used in the original patch.

I'm not especially familiar with the details of the revision system, particularly as it relates to field collections, so I will need to do some research before I can offer any sort of informed opinion on the right way to handle this.

My current (probably naive) understanding is that field collection revisions get their own uuid, so that when we deploy an update for a field collection with a new revision, the receiving instance of Drupal should be able to see that the uuid of the revision on the field collection entity is different from the uuid of the current revision and therefore it should create a new revision with that new uuid. It doesn't seem like it should require jumping through a bunch of hoops. I would expect most (or all) of that to just work via the normal machinations of the UUID and field collection modules, but as it does not, I suspect my understanding is currently flawed. If anyone has any insights into that it would be very helpful.

Thanks for the great work here. The patch applied cleanly for me, but using Deploy module I'm still getting errors that the field collection can't be saved without a Host Entity.

That issue was originally addressed in https://drupal.org/node/1817956 , which spawned this ticket and improved approach... so I expected it wouldn't be a problem here. Is there another patch I need to apply to get correct dependency handling?

When i try to install this patch and enable field_collection_uuid i get an error because field_collection_entity_uuid_load() is already declared in the uuid module.

How should field collection uuid be handled - with this patch or with the uuid module?

EDIT

Nevermind i just noticed the related issue on the site there.

(Sorry, got the wrong issue id.)

This is the closest, workable approach I've found so far if you're looking to deploy field collections through services. The patch in the referenced thread above (#2309103) suggests a patch which removes all contrib support from uuid (including services support, but doesn't put it back anywhere). Essentially there doesn't seem to be a complete, working solution for deploying field collections via services yet.

That said, the patch in comment #3 works if you apply the attached patch for uuid which removes the conflicting implementation for field_collection only. This is not a long-term solution, but just a workaround to make this patch work in the meantime. This is also why I didn't post it in the uuid thread - it is not of use to anyone but those intending to use the patch in comment #3.

Hopefully this helps someone who needs a stopgap solution for deploying field collections via services while the approach in #2309103 gets fully fleshed out and adopted by all contrib modules currently supported by uuid.

If you don't need to deploy via services and you're doing a fetch-only deployment plan, the patches in the other thread work.

patch 3 seems to work well on mysql and postgres

however in mssql using the latest sqlsrv drivers we're getting this error:

PDOException: SQLSTATE[22018]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Conversion failed when converting the varchar value '97a7296d-ed89-4437-b4f2-032d82f53469' to data type int.: SELECT revision.[revision_id] AS [revision_id], revision.[vuuid] AS [vuuid], base.[item_id] AS [item_id], base.[field_name] AS [field_name], base.[archived] AS [archived], base.[uuid] AS [uuid], cross_default_revision.cross_sqlsrv AS default_revision FROM field_collection_item base INNER JOIN field_collection_item_revision revision ON revision.revision_id = base.revision_id CROSS APPLY (SELECT CASE WHEN base.revision_id = revision.revision_id THEN 1 ELSE 0 END cross_sqlsrv) cross_default_revision WHERE ( ([base].[item_id] IN (:db_condition_placeholder_0, :db_condition_placeholder_1)) ); Array ( [:db_condition_placeholder_0] => 7 [:db_condition_placeholder_1] => 97a7296d-ed89-4437-b4f2-032d82f53469 ) in EntityAPIController->query() (line 187 of profiles\wetkit\modules\contrib\entity\includes\entity.controller.inc).

we're working on a solution at this moment.

I spend a lot of time between this issue and the related one and couldn't get field_collections to properly deploy with services. Eventually I got it working with a combination of patches and thought I would document them here. One thing I should mention is I had to resort to parts of the patch in #2 because the patch in #3 wouldn't deploy and was either getting error messages about the revision_id or when removed the UUIDFieldCollectionItemEntity file errors such as: "Unable to create a field collection item without a given host entity". I kept some of the improvements from the patch in #3 but kept the revision logic + UUIDFieldCollectionItemEntity from #2. Aside from that I am using the following:

projects[field_collection][version] = 1.0-beta10
projects[field_collection][subdir] = contrib
projects[field_collection][patch][1344672] = http://drupal.org/files/issues/1344672-489.patch
projects[field_collection][patch][2599248] = http://drupal.org/files/issues/field-collection-2599248-2.patch

projects[uuid][version] = 1.0-beta1
projects[uuid][subdir] = contrib
projects[uuid][patch][2074621] = http://drupal.org/files/uuid_services_field_collection_revisions.patch
projects[uuid][patch][2121031] = http://drupal.org/files/issues/uuid-empty_file-2121031-1.patch

As well as deploy 2.0-alpha3 and services 3.12 with a few additional patches. I have created two patches that apply to field_collection. An updated patch for field_collection_uuid related to what was mentioned above and a new patch which creates a field_collection_uuid_services module that has to be enabled on the destination site so resources under services can be configured for field collection. This is due to the field collection services integration being removed from the uuid module.

Everything then seemed to work as supposed to.

Marking as needs review so someone can look at @sylus' patches above.

Sylus patches are working for us.
RTBC+1

+1 for RTBC

So for this to work it requires UUID to be patched with a special case to handle field collections.

If I understand correctly, the problem happens when an access check happens on a field collection item that has been created but not assigned to a host entity yet. Is there a reason we can't / shouldn't support this?

@sylus' 2 patches here solve my current issue - deploy of nodes with field collections working great now. glad to have found this in a pinch.

@sylus' 2 patches in #18 worked for me in conjunction with the Deploy module ... like a charm. RTBC?

There's an issue in the queue of the new UUID Extras module which is related to this: #1817956-42: Field collection support. TL;DR: Field Collection itself is not really affected, but UUID and UUID Extras needs patching. Some extra work might be needed for the revision-related part.

Just noting here. When using this module, we encountered a problem when cloning / translating nodes with field collections.
The field collections get the same UUID as the ones they're coming from. This causes issues on deployment where the target site get's different field collection assigned.

As a quick solution now, i added the uuid and vuuid reset in field_collection_field_insert, but this should probably be done better in field_collection_field_uuid_presave.

/**
 * Implements hook_field_insert().
 */
function field_collection_field_insert($host_entity_type, $host_entity, $field, $instance, $langcode, &$items) {
  foreach ($items as &$item) {
    if ($entity = field_collection_field_get_entity($item)) {
      if (!empty($host_entity->is_new) && empty($entity->is_new)) {
        // If the host entity is new but we have a field_collection that is not
        // new, it means that its host is being cloned. Thus we need to clone
        // the field collection entity as well.
        $new_entity = clone $entity;
        $new_entity->item_id = NULL;
        $new_entity->revision_id = NULL;
        $new_entity->is_new = TRUE;
        // ADD THOSE TWO LINES ;-)
        $new_entity->uuid = NULL;
        $new_entity->vuuid = NULL;
        $entity = $new_entity;
      }
      if (!empty($entity->is_new)) {
        $entity->setHostEntity($host_entity_type, $host_entity, field_collection_entity_language($host_entity_type, $host_entity), FALSE);
      }
      $entity->save(TRUE);
      $item = array(
        'value' => $entity->item_id,
        'revision_id' => $entity->revision_id,
      );
    }
  }
}