Doesn't clone properly

#1233256: Integrate node_clone with field_collection module is producing some great code, but ultimately field collection should support node_clone module by implementing hook_clone_node_alter in the same fashion the webform module does.

I need this right now so I will see about posting a patch here shortly.

This is a patch that pulls together the other work done to make this happen. It implements hook_clone_node_alter and creates a helper function for cloning field collections.

Worked great for me! Will be pushing this patch to production on Monday after preliminary tests this weekend, will let you know if we run into anything unexpected, but so far it's working perfectly!

Just some coding style and optimization, the code looks good overall.

+++ b/field_collection.moduleundefined
@@ -1400,3 +1400,54 @@ function field_collection_devel_generate($object, $field, $instance, $bundle) {
+  $field_info_instances = field_info_instances();
+  $field_names = element_children($field_info_instances['field_collection_item'][$fc_field]);

Instead, I think this could be just array_keys(field_info_instances('field_collection_item', $fc_field));

+++ b/field_collection.moduleundefined
@@ -1400,3 +1400,54 @@ function field_collection_devel_generate($object, $field, $instance, $bundle) {
+      foreach($node->$field_name as $language => $values){

Missing space after foreach

+++ b/field_collection.moduleundefined
@@ -1400,3 +1400,54 @@ function field_collection_devel_generate($object, $field, $instance, $bundle) {
+function field_collection_clone_items($entity_type, &$entity, $fc_field, $language = LANGUAGE_NONE){

I think that $field_name should be used here instead of $fc_field.

+++ b/field_collection.moduleundefined
@@ -1400,3 +1400,54 @@ function field_collection_devel_generate($object, $field, $instance, $bundle) {
+  $old_fc_items = $entity_wrapper->{$fc_field}->value();

I'd like to avoid using fc as an abbreviation, I think it can be $old_item and $new_item

+++ b/field_collection.moduleundefined
@@ -1400,3 +1400,54 @@ function field_collection_devel_generate($object, $field, $instance, $bundle) {
+    $new_fc_item = entity_create('field_collection_item', array('field_name' => $fc_field));
+    $new_fc_item->setHostEntity($entity_type, $entity);
+    $new_fc_item_wrapper = entity_metadata_wrapper('field_collection_item', $new_fc_item);

These three lines could probably be moved outside the foreach, and cloned each time through.

+++ b/field_collection.moduleundefined
@@ -1400,3 +1400,54 @@ function field_collection_devel_generate($object, $field, $instance, $bundle) {
+          field_collection_clone_items('field_collection_item',$new_fc_item, $field_name, $language);

Missing space after the comma.

+++ b/field_collection.moduleundefined
@@ -1400,3 +1400,54 @@ function field_collection_devel_generate($object, $field, $instance, $bundle) {
+  $field_info_instances = field_info_instances();
+  $field_names = element_children($field_info_instances['field_collection_item'][$fc_field]);

Instead, I think this could be just array_keys(field_info_instances('field_collection_item', $fc_field));

Great, thanks Tim. I will roll a new patch tomorrow.

The patch doesn't work for 100% when they are required fields in the field collection. The node is cloned but there is an error that field X is required. Thanks for the patch anyway since the most important part "cloning" is working fine!!!

I tried your patch, but didn't worked in my case. Somehow the form gets no fields after the line field_collection.php:1067

drupal_process_form($form['#form_id'], $nForm, $form_state);

My scenario:
We have a field collection with 3 values filled in, we clone the node (it works), and we want to leave only 2 values from the 3, so we delete one of them (nothing happens + "Uncaught Syntax error, unrecognized expression: # " JS error

What I tracked down, the form has no more fields after you run the "drupal_process_form".
I am not sure if it's field_collection or node_clone that I should work on...

Thanks,
Gabriel

Looks like Field collection is not loading the necessary node.inc files. See attached patch.

BTW: This also includes the above patch. You can only consider my changes to the function field_collection_remove_js()

I don't know if there is any better way of doing this.
Gabriel

#3 worked for my purpose.

how is this going further? I suggest a commit asap!

I just tinkered with some code based on the suggestions in #1233256: Integrate node_clone with field_collection module---and I found that the saving of the fc items is problematic (in fact, the fc-items get not saved, but the host entity still gets populated with IDs---presumably the IDs that would have resulted if db transaction were not rolled back) if the new host entity is not yet saved---and actually, the way setHostEntity() works (now) makes saving the fc-item unnecessary: Removing the call to save() makes everything work.

Posting here since the patches are builton the code from #1233256: Integrate node_clone with field_collection module and include the offending call to the EntityMetadataWrapper->save().

(That is to say, if you want to make the patch work for unsaved host entities, remove that call to save().)

@liquidcms I accept your beers :-). Will meet you at the next camp/con

@sven.lauer I am having a bit of trouble interpreting what you are saying. I think its either "OMG THIS ISN'T ACTUALLY WORKING!!!" or "It works but not for unsaved host entities"?

As for getting it commited, I think a new patch needs to be rolled with the review from #5 that I never got around to doing

Are you still planning to commit this patch (it it works)?

Thanks!

After trying the #3 patch (against version 7.x-1.0-beta4), I think there is still an annoying issue.

When I clone a node, it is copied twice, so I get :

• Original node
• My cloned node (to which I modified fields)
• Clone of Original node (which contains original node values)

The third one has its own field collection values (its own records in the database), but should not have been created.

EDIT : It seems there is a node that is created right after clicking the clone link, although I've set the clone module method to "prepopulate". And when saving the node edit form, a new node is created again.

I think the field_collection_clone_items() function from #3 patch should not be saving anything if the node_clone module method is set to "prepopulate".
It should only prepopulate the passed entity.

But I can't figure out how to fix it since I'm not comfortable enough with Entity API/Field collection.

Maybe putting a condition around the entity save function should be enough :

    if ($context['method'] == 'save-edit') {
      $new_fc_item_wrapper->save();      
    }

Then the $context variable should be passed from field_collection_clone_node_alter() function to field_collection_clone_items() function.

#9: Issue 1304214.diff queued for re-testing.

Patch works fine, but with the same issue as in 16 [ 2 new nodes are created]
Switching to the 'Save as a new node then edit ' method avoided the problem.

Adjusted #3 for the current 7.x-1.x, also applies to 7.x-1.0-beta4. I put some coding style changes in but did not optimize as #4 advised.

FYI: To get information about nodes which are sharing Field Collections you may use the following SQL-Queries:

First get all Field Collections:

select concat('field_data_', fci.field_name) as table_name, 
    concat(fci.field_name, '_value') as value_column,
    entity_type
  from field_config fc 
  left join field_config_instance fci on fc.id = fci.field_id 
  where fc.type like 'field_collection' 
  group by fci.field_name 
  order by fci.field_name, fci.id;

Second use the resulting table_name's and value_column's to check for Entity IDs which are sharing Field Collections like this for every table_name:

select group_concat(entity_id order by entity_id) as entity_ids, count(*) as count_shared 
  from <table_name> 
  group by <value_column> 
  having count_shared > 1;

Every resulting line will contain Entity IDs which share a Field Collection.

You now may remove a shared Field Collections from a node (or entity) by deleting the corresponding record from <table_name>.

I'm not sure if this is the same problem, but when I clone a node with a field collection, it clones fine, but when I try to add a new field collection ("add another item" - my content type allows an unlimited number of field collections) I get:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /system/ajax
StatusText: Internal Server Error
ResponseText:

If I save the node without adding a new field collection I can then edit it and add the new field collection with no problem. This workaround though won't help my users, who most of the time would be cloning the node precisely in order to add a new field collection.

If this isn't what the original issue is about let me know and I'll create a new issue.

This patch worked for me too.

So we can set the issue to RTBC.

This patch worked for me when I used "Save as a new node then edit" option from Node clone module settings page. When I used "Pre-populate the node form fields", then new node appeared just after clicking the "Clone" link.

I updated this patch to work with both "Pre-populate the node form fields" and "Save as a new node then edit"

If you have problems with applying this patch, then you can try using patch below.

#26 has sites/all/modules hardcoded instead of current path

Updated patch

Patch from #28 works for me.

We (I and RoSk0) are using this patch against 7.x-1.0-beta4 and it works fine.

The patch from #28 works with beta5.

The patch from #28 does not work with beta5.

#28 looks sound, for those looking for a more direct solution I did this recently so I don't have to patch for a 1-off. If you swap out the module name, form_id and field_games field name with your associated values this will work as well. Patch is much more generic and preferred solution, just wanted to post to help other devs in a pinch.

/**
 * Implements hook_form_alter().
 */
function league_glue_form_alter(&$form, &$form_state, $form_id) {
	// ater the game day form
	if ($form_id == 'league_game_day_node_form') {
		// account for cloning operation
		if (arg(2) == 'clone' && is_array($form_state['field']['field_games']['und']['entity'])) {
			// unset the item_id's of each item so that new ones are created on save
			foreach ($form_state['field']['field_games']['und']['entity'] as $key => $item) {
				$form_state['field']['field_games']['und']['entity'][$key]->item_id = NULL;
				$form_state['field']['field_games']['und']['entity'][$key]->revision_id = NULL;
				$form_state['field']['field_games']['und']['entity'][$key]->is_new = TRUE;
			}
		}
	}
}

foreach ($form_state['field'][$field_name][LANGUAGE_NONE]['entity'] as $item) {
  $item->item_id = NULL;
}

is enough. Thanks for the simple code!

How can I identify nodes that have already been affected by this?

I've successfully applied the patch from #28 against beta5 and everything is working great for me.

I've applied the patch from #28 to beta5 and it is working great for me, too.

Correction: The patch from #28 is not working for me using beta5. I'm trying to use it for a node that has a field collection with an unlimited number of values allowed (and 12 of them in the original node are filled with data in this case), so the problem may be specific to my use case.

The problem I'm experiencing is this: when I attempt the clone, the values for the first instance of the field collection are cloned correctly, but each of the subsequent instances simply repeats the values from the *last* instance of the field collection from the original node. It appears there may be a missing loop in the patch to cover field collections with unlimited values, though I'm not familiar enough with D7 fields or this module to figure it out at this point. If I do, I'll post a fix.

I tested the patch from #28 (against the latest dev) and it fixed the issue for me as well. Thank you.

The patch from #28 still applies with an offset:

patch -p1 < field_collection-1304214-28.patch 
patching file field_collection.module
Hunk #1 succeeded at 1945 (offset 489 lines).

However, it does not fix the issue. I have the same problem as described in #42.

If I delete the mutilated data, things get worse. There is no editable field collection anymore, and I get the error:

Notice: Trying to get property of non-object in field_collection_field_get_entity() (line 1644 of /var/www/d7/sites/all/modules/field_collection/field_collection.module)

Since there is no workaround and this bug mutilates data, changing category to "bug report" and priority to "major".

Since the patch for #1316162: Support content translation and host entity cloning is applied field collections should support their host being cloned now. I think this can be closed as a duplicate. Can anybody confirm with the latest dev version?

I'm using field_collection 7.x-1.x-dev from 2014-Jul-24. In this version, the issue still exists as described above: Cloned nodes with an attached field collection inherit the data from the last edit, back to the initial node that was cloned. It is not possible to enter data on cloned nodes without affecting the prior generations of clones. If you have 9 cloned nodes and edit one of them, you alter a total of ten nodes (clones plus original).