title likely doesn't make any sense and maybe this is a support question rather than a bug as hard to imagine this has gone unnoticed.

i have a node with numerous collection fields.

when i view the node, i get very handy edit/add links to (i thought) update the node with just this part of its content: http://screencast.com/t/kFD6JXMbym22

but, when i use these links to "add" content to my node, even though it appears in my node view, when i edit the node, the values are not set.

from the example above:

node view: the last item is showing as 40-70%: http://screencast.com/t/4eAeeONil
collection edit: this also shows this value: http://screencast.com/t/bMnxc4sQY2
node edit: shows no value has been entered yet: http://screencast.com/t/J4MmATf1n

further more.. if i enter a value in the node view this value does not replace or show with the "collection stored value", but is saved. so i now can edit and see 1 value from the node view and edit the node and see a completely different value.

this can't possibly be expected behavior is it?

Comments

liquidcms’s picture

liquidcms commented

further to support this is a bug:

if the data is initially entered view the node edit form; those values DO show on the node view and when editing the collection; any changes made there are reflected in both the node view and when i go to edit the node.

liquidcms’s picture

liquidcms commented
Title: collection item added from node view not attached to node » collection values not loaded for radio buttons on edit form

i now think this may be simply that the collection module doesn't work with radio buttons.

it seems like if i Add collection values to a node with the link in the node view the values are stored; but aren't properly loaded as defaults when i go to edit the node. then if i set any of the radios on the node edit form and submit; the original values are lost.

liquidcms’s picture

liquidcms commented
Title: collection values not loaded for radio buttons on edit form » default values not loaded for collections with multiple fields on node edit form

hmm.. ok, not just radio, but checkbox or select lists also do not load correctly when add from the field collection link IF they are grouped into more than one field.

in other words:

my node has 3 collection fields:

- first is comprised of 3 fields (all are list(integer) of radio, checkbox, select list)
- second has no fields added yet
- third has a single list(integer) field set as a select list

only the 3rd field loads its values on the node edit form correctly when they are added from the node view Add links added by collection module.

liquidcms’s picture

liquidcms commented

trying to narrow this down a little. tried it on a clean-ish D7 install and it works correctly. the site where it is broken also uses OG and the node type in question is OG content; so i thought possibly related to that; but i added my collection to a non-OG node type and it fails the same way.

most likely being caused by interaction with some other module; still searching

liquidcms’s picture

liquidcms commented
Priority: Major » Normal

i deleted the collection field and re-added it and the issue is now gone. there's a bug here somewhere; but likely going to be hard to find.

ad4m’s picture

ad4m commented

Hi,

I've recently had the same problem, but in my situation the bug was caused by the field_permissions module. If you set custom permission on a field level, you won't see the field on edit form. That is because field_permission module requires field's parent entity to have uid parameter set to correctly determine permissions.

I've added an uid column to the field_collection module's schema and added uid as a building parameter through entity_create and now everything seems to work fine.

drvdt’s picture

drvdt commented

Hi ad4m,
Can you explain more detail what did you do?
Thanks

johnpitcairn’s picture

johnpitcairn commented
Version: 7.x-1.0-beta4 » 7.x-1.x-dev

I am seeing this problem on an existing production site: a boolean checkbox, checked by default, is not checked for the first field collection item (in an unlimited values field) on the node/add form.

If I add a second field collection item, the checkbox is checked.

And, as per #5 ... I cannot reproduce this in a clean installation. Bah. So something, somewhere, is messed up for the field instance. The site has been live for about a year, it's not going to be fun to re-create and re-populate the field for the entire site.

7.x-1.0-beta5 or 7.x-1.x-dev makes no difference, so upping this to dev version.

johnpitcairn’s picture

johnpitcairn commented

OK, here's my problem: the "hide blank items" option was checked for the field on the host node.

Uncheck "hide blank items", save the field settings, re-check "hide blank items", save the field settings. Boolean default values now work correctly for the first item.

Perhaps this is a result of the field instance having existed since before that option was added?

manimejia’s picture

manimejia commented
Version: 7.x-1.x-dev » 7.x-1.0-beta1
Priority: Normal » Critical

I'm experiencing the same problem on a field collection assigned to a multi-value field. This field collection contains four "List (text)" fields (one of which allows multiple values), a couple of "List (integer)" fields, and a couple of "Text" fields. Only two of the single value "List (text)" field have this problem, and only when their widget is set to "checkboxes and radio buttons". I think it's related to the fact that 0 (zero) is a key in the list of allowed values, only for these two fields. Here's what happens:

  • Any "default value" assigned is not applied on the node edit form.
  • If the field has a value stored, this value is not pre-selected on the edit form. Instead, the value of 0 key is pre-selected.

I'm marking this as critical, because it can cause content to be overwritten unknowingly (and possibly lost forever) when the node is edited. It might be an edge use case, but it has the potential for catastrophic consequences.

the maxx’s picture

the maxx commented

having this exact same issue as well, it is certainly not specific to the radio/checkbox inut types.
I am using only text fields.
I have two field collections created in the same way.
For one, after entering values and saving, the values render to the custom theme, but are not visible in admin edit. (values are being stored in the DB with success)

For the second, only one field out of several is displaying this behavior.

It seems that if I go back and re-edit the node with new values, behavior returns to expected behavior.

jmuzz’s picture

jmuzz commented
Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

I tried it with some field collections with radio buttons. I didn't see any strange behavior about default settings or inputted values being lost on the edit form. Has anybody seen this happen in beta7+ or have any idea what module it might be interacting with to cause it?

Note that field permissions and entity translation are both known to break with field collections currently.

Rodge Darkfleet’s picture

Rodge Darkfleet commented

Hi,

I am experiencing a same issue:

I have a field collection (location, username and password) nested in a field collection (service).

Both can have multiple values. After getting a notice undefiended index, as fixed here, the values won't be displayed. The values are stored in the data table and in the revision table. Truncating the revision table and clearing cache doesn't solve the issue.

The thing is that the first collection is displayed correctely but only the first two nested items show the data as wanted..

Any ideas how to fix this?

jmuzz’s picture

jmuzz commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

@Rodge Darkfleet: If you needed the fix in #1822844: Notice: Undefined index: revision_id in field_collection_field_get_entity() (line 1586 of field_collection/field_collection.modu then your data has likely been corrupted as explained in the issue comments there.

I'm going to close this but if anybody can provide steps to reproduce it then it can be reopened.