Resolution

Commit 3a13633 on 7.x-1.x

This has been released in beta3.

Original summary

Exception: Invalid field name given. in FieldCollectionItemEntity->__construct() (line 107 of /Applications/MAMP/htdocs/2011.03.03 Zananda/sites/default/modules/cck/field_collection/field_collection.module).

I am currently trying to get all work with panel layouts, but had problems when adding field-collection-fields in the node-edit-form or front-end-view mode by clicking "+"

I think it would be much better to add stuff in the backend with the backend-theme than in the frontend, cause if the theme does not support the needed stuff it always ends in troubles I guess.

I use an modified Bartik version.

Maybe I can somehow prevent drupal from using the wrong layouts by adding a selection rule for the path "domain/field-collection/*"

Files: 
CommentFileSizeAuthor
#40 workaround_undefined_index_error_in_user_permission_features_export_render-1305048-1.patch1.09 KBmongolito404
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch workaround_undefined_index_error_in_user_permission_features_export_render-1305048-1_0.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#46 field_collection_workaround_bug_in_PDO_and_core-1084268-40.patch1.65 KBmongolito404
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection_workaround_bug_in_PDO_and_core-1084268-40.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#24 field_collection_workaround_bug_in_core-1084268-24.patch1.3 KBmongolito404
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection_workaround_bug_in_core-1084268-24.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#4 field_error-1084268-4.patch1.51 KBtim.plunkett
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_error-1084268-4.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Comments

The whole project online: http://zananda.drupal-rocks.com/admin/

User: drupalbuddy
Pass: checkitout

If anybody wants to have a closer look, please login ;-)

THANKS !!!!

Another issue coming up when checking for updates:

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /batch?id=43&op=do StatusText: OK ResponseText: {"status":true,"percentage":"1","message":"Trying to check available update data ...\u003cbr \/\u003eChecked available update data for \u003cem class=\"placeholder\"\u003eOptions element\u003c\/em\u003e."}Exception: Invalid field name given. in FieldCollectionItemEntity->__construct() (line 107 of /Applications/MAMP/htdocs/2011.03.03 Zananda/sites/default/modules/cck/field_collection/field_collection.module).

Other issues from the logfile: (Location: http://zananda.dev/batch?id=43&op=do & Referer: http://zananda.dev/batch?op=start&id=43)

Notice: Undefined variable: itens in customfilter_filter_info() (line 42 of /Applications/MAMP/htdocs/2011.03.03 Zananda/sites/all/modules/editor-features/customfilter/customfilter.module).

Notice: Undefined index: title in _filter_list_cmp() (line 593 of /Applications/MAMP/htdocs/2011.03.03 Zananda/modules/filter/filter.module).

Exception: Invalid field name given. in FieldCollectionItemEntity->__construct() (line 107 of /Applications/MAMP/htdocs/2011.03.03 Zananda/sites/default/modules/cck/field_collection/field_collection.module).

Warning: uasort() [function.uasort]: Array was modified by the user comparison function in filter_get_filters() (line 583 of /Applications/MAMP/htdocs/2011.03.03 Zananda/modules/filter/filter.module).

Warning: Cannot modify header information - headers already sent by (output started at /Applications/MAMP/htdocs/2011.03.03 Zananda/includes/common.inc:2561) in drupal_send_headers() (line 1040 of /Applications/MAMP/htdocs/2011.03.03 Zananda/includes/bootstrap.inc).

Notice: Undefined variable: itens in customfilter_filter_info() (line 42 of /Applications/MAMP/htdocs/2011.03.03 Zananda/sites/all/modules/editor-features/customfilter/customfilter.module).

Notice: Undefined index: title in _filter_list_cmp() (line 593 of /Applications/MAMP/htdocs/2011.03.03 Zananda/modules/filter/filter.module).

Warning: uasort() [function.uasort]: Array was modified by the user comparison function in filter_get_filters() (line 583 of /Applications/MAMP/htdocs/2011.03.03 Zananda/modules/filter/filter.module).
----
Location http://zananda.dev/admin/structure/pages
Referrer http://zananda.dev/admin/appearance
Message Warning: Cannot modify header information - headers already sent by (output started at /Applications/MAMP/htdocs/2011.03.03 Zananda/includes/common.inc:2561) in drupal_send_headers() (line 1044 of /Applications/MAMP/htdocs/2011.03.03 Zananda/includes/bootstrap.inc).
----

StatusFileSize
new1.51 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_error-1084268-4.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Here is a hacky hack to get the errors to go away. This demonstrates my lack of knowledge of the Entity API module and OO in general.

I have debugged the issue, and it seems to be a PDO version related bug. On my mac with MAMP 5.3 it works ok, but fails on 5.2.13

The problem is when EntityAPIController::load() calls EntityAPIController::query() and then it crashes on:

foreach ($this->query($ids, $conditions, $revision_id) as $record) {

I wasn't able to solve it yet, but hope this info can help in finding a solution.

That is exactly where it fails for me as well, and I'm on PHP 5.2.13, will try with 5.3.

similar problem for me
Exception: Invalid field name given. in FieldCollectionItemEntity->__construct() (line 108 of Z:\home\paris9.kz\www\emploi\sites\all\modules\field_collection\field_collection.module).

I use 7.x-1.0-beta1

Status:Active» Closed (duplicate)

Status:Closed (duplicate)» Reviewed & tested by the community

Confirming that http://drupal.org/node/1084268#comment-4193072 does remove the error, and the module is usable.

Status:Reviewed & tested by the community» Closed (duplicate)

As tim.plunkett noted, the patch in #4 is just a hack but no proper fix.

Generally, this exception is thrown when the API is wrongly used. The linked issue in #8 is a bug what might cause this. If you have another situation, please open a separate issue.

Indeed, a "hacky hack". :) Not sure why I even posted it.

Status:Closed (duplicate)» Active

Cross posting this from #889286: EntityAPIController::load() produces WSoD sometimes with PHP 5.2:

- field_collection_field_get_entity() is called
- which calls field_collection_item_load()
- which calls entity_load()
- which calls EntityAPIController::load()
- which calls the line foreach ($this->query($ids, $conditions, $revision_id) as $record) {

- query() loads the data from the DB
- the foreach construct triggers fetch()
- fetch() triggers __construct()

__construct() is *supposed* to have the object loaded with the values from the DB, which is what happens in PHP5.3, but in PHP5.2, the object does not have the values.

This is not evident in search_api, because its __construct() doesn't modify the object directly.

The order of loading the object and calling __construct is discussed here: #298309: DatabaseStatement::execute with PDO::FETCH_CLASS calls __construct() after setting object attributes, not sure if its directly related

https://bugs.php.net/bug.php?id=50875 seems to explain this problem, but it claims it was fixed in 5.2.12, I am running 5.2.13 and still encountering it.

So field-collection does not work at all on this installation?
I was running a 5.2 installation with it recently and did not encounter any problems, so it looks like it was fixed there.

It seems to work once you remove the throw new Exception("Invalid field name given."); in __construct. But still WSOD without editing anything.

I can confirm that this error will pop up for me on 5.2.13 and disappears once I switch to 5.2.17 or 5.3 (those are the version I can easily "one click switch" to)

I've the same error using 5.3.3-1ubuntu9.5. But in my case, FieldCollectionItemEntity::_constrcut is called from DatabaseStatementPrefetch::current from includes/database/prefetch.inc because I'm using SQLite (DatabaseStatement_sqlite extends DatabaseStatementPrefetch). Looks like a bug in core.

Version:7.x-1.x-dev» 7.x-1.0-beta1

subscribing

Version:7.x-1.0-beta1» 7.x-1.x-dev

Fixing version

subscribing

sub

@4

if i'm right the modules code has changed a little bit in the current dev - could you post the patch/hack again for the current version?
i would be very thankful ...

StatusFileSize
new1.3 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection_workaround_bug_in_core-1084268-24.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Here is a patch to workaround the issue in core.

Status:Active» Needs review

Actually, that's not a bad idea.

I can confirm that update PHP from 5.2.12-2 to 5.2.17 works for me fine. On development server i have 5.3 and no error.

I'm having this problem on PHP 5.3.6.

If I apply the patch from #24, which file am I supposed to be patching? Will this patch cause problems for future updates?

Thanks!

File to patch :

field_collection.module

The workaround seems to work fine for me. Thanks !

Cygwin tells me the patch from #24 was successfully applied but I'm still receiving exactly the same error. Applied patch to both 7.x-1.0-beta2 (2011-Aug-18) and 7.x-1.x-dev (2011-Sep-27).

I see that this issue is unassigned and needs review. Anyone know if this is likely to be resolved soon (either a core bug fix or a successful workaround in the module)?

Any other / additional assistance will be greatly appreciated :)

subscribe

subscribing
I can confirm that this error pop up on 5.2.13 (my prod site)
it's OK on 5.2.6 (my DEV site)

I can vouch for mongolito404's patch - module was unusable without applying it.

Status:Needs review» Reviewed & tested by the community

I'm 100% okay with this patch, but I want to check with fago.

I still get this error despite having applied the patch when trying to add an EntityReference View Widget to a view of field collection items (using the latest dev versions of ctools, views, field_collection, entityreference and entityreference_view_widget).

Status:Reviewed & tested by the community» Needs work

Yep, let's go with the workaround. But let's note there it's because of the PDO bug. Still, field collections shouldn't be created without being associated to a fieldcollection-field.

+    // Avoid checking field type if properties are not set yet.
We are not checking for a field type, but for the field name.

Status:Needs review» Needs work

I have the same issue as described in this thread. I was running PHP 5.2.13, switched to 5.3.2 which seemed to get rid of the PDO-Exception error. I can now add one group of fields, but adding multiple groups is not possible anymore. Either Drupal doesn't upload the file, or it gives me a "an invalid choice has been detected" error.

I have the 7.x-1.0-beta2 version and tried the suggested patch but it doesn't work. I am using NetBeans to apply the patch and I get the error "The patch cannot be applied in the selected content".

Is there an other way around this issue? It seems to make the module kind of unusable.

EDIT: another thing I have noticed with the beta version is that it doesn't seem to work too well with images or files, things that need uploading.

EDIT2: I have downloaded the dev version, that seems to fix the issues.

What work is needed here?
The patch includes references to the two relevant issues (this one and #1264440: DatabaseStatementPrefetch doesn't set instance properties before calling _construct when using PDO::FETCH_CLASS). The comment ''Avoid checking field type if properties are not set yet." apply to the content of the if block. The condition is used to test if the properties are set, and to avoid running the block if not. The content of the block is a field type check.

Read #35 .

a) The check is not about a field type.
b) The comment should explain this is a workaround for the PDO bug.

Also, comment sentences should end with a trailing point.

StatusFileSize
new1.09 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch workaround_undefined_index_error_in_user_permission_features_export_render-1305048-1_0.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

I reworded the comment. If this need further work, please provide the wanted comment text. The intent of the code was already clear to me once you are aware of the two issues referenced in the comment. I've the honest feeling that my reworded comment only states the obvious (for anybody aware of the two referenced issues), which is unnecessary.

Note: The wrong patch has been attached, see #46 for the correct patch.

Status:Needs work» Needs review

Status:Needs work» Needs review

I am checking this issue and I needed urgently to have working field-collections yesterday. So here is (maybe temporary) fix for some of you:
- go to content type - display fields. Make field collection invisible (so the error is not breaking you node page).
- use Views + EVA. Create table view of entities (of type field collection item of course), create EVA display, use Contextual filter and it is working. At the moment i do not have add/edit/delete links (please can somebody write me a paths?), but i have items showing on node page and it was important for me at the moment.

Status:Needs review» Needs work

Patch in #24 seems to have fixed the error for me (using PHP 5.2.13). It still needs to be adjusted according to #35.

mongolito404, I think that you attached the wrong patch in #40.

I have the same problem. I'm going to try the solution you've suggested in #42.
BUT-
I really think this should be displayed correctly without he need to euse other display modules.
Is there any chance to fix it inside te module???

Just run accros same error. Using PHP 5.3.4 and building view listing field-collection items and trying to display non-existing fields.

StatusFileSize
new1.65 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection_workaround_bug_in_PDO_and_core-1084268-40.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Here is the patch that should have been attached to #40.

Status:Needs work» Needs review

I haven't looked closely to understand what's happening here, but confirming that I had the problem of the thrown exception using PHP 5.2.14 while trying to create a field_collection entity programaticly, and the exception went away with this patch applied.

Patch works for me (applied from module root folder). 7.x-1.0-beta2, PHP 5.2.13.

Same here on Centos 5 and php 5.2.13. Fixed upgrading to 5.2.17 from atomicrepo.

Hey everyone, I'm having the same problem, and have no idea what to do.. When I create the content everything goes ok until I try to view it. I'm using MAMP Pro 1.9.2 on a MacBook Pro OS X 10.6.8 using Drupal 7.10. The exact error is

Exception: Invalid field name given. in FieldCollectionItemEntity->__construct() (line 107 of /Users/joshbgosh9/Sites/romanos/sites/all/modules/field_collection/field_collection.module).

@joshbgosh10592 - Apply the patch

oh lol. sorry, sort of a Drupal noob.. Thank you! When I put it online on another server, I shouldn't have a problem, right? it's just a MAMP issue?

It's nothing to do with MAMP. Patch beta 2 until the patch has been (hopefully) included in the next beta, or use the dev version which should already have the patch committed.

Status:Postponed» Active

I still get this in the dev, I can see the workaround is in there.

Exception: Invalid field name given: field_some_gall_field is not a Field Collection field. in FieldCollectionItemEntity->__construct() (line 119 of /var/aegir/platforms/mesite-7/sites/all/modules/field_collection/field_collection.module).
...

php 5.3

i fixed it after I looked in my db in the (field_collection_item) table and found one entry that stood out (field_some_gall_field) which is what is in the exception error. all the other entries say (field_batch_entries)
So I deleted that one... I have no idea how that got there or if that was the culprit but it fixed it lol.

I noticed its doing this randomly when mucking with my view, now I see its singled out another field to throw the exception with, deleting that entry from db fixes it again. It's not happened again, so perhaps its related to slickgrid view, I will keep a watch and see if it does it again without slickgrid as the display type.

We are getting this error when an instal profile tries to enable a feature that contains a field collection item which has some default values set. Seems to be because of the way that the default value is defined in the feature:

<?php
   
'field_instance' => array(
     
'bundle' => 'user',
     
'default_value' => array(
       
0 => array(
         
'entity' => entity_import('field_collection_item', '{
            "item_id" : null,
            "field_name" : "field_cw_profile_contact_prefs",
            "field_cw_profile_pref_email" : { "und" : [ { "value" : 0 } ] },
            "field_cw_profile_pref_mail" : { "und" : [ { "value" : 0 } ] },
            "field_cw_profile_pref_phone" : { "und" : [ { "value" : 0 } ] },
            "field_cw_profile_pref_sms" : { "und" : [ { "value" : 0 } ] }
          }'
),
        ),
      ),
      ...
?>

I suspect the use of entity_import() may be the cause?

I am getting the same issue as 58. Currently unsetting the offending default value using hook_field_default_fields_alter. This is a workaround.

@mrfelton

i was playing around with this a little more and i'm not sure that defining a default value for the field collection is actually needed for use with installing via features. Someone please correct me if i am wrong.

It seems to me like if you just set the default value of the field collection to NULL then features will just use all the default values of the fields within that field collection... meaning the default value of the field collection is actually redundant.

@pirog Removing the defaults seems to remove the fields from the field collection. Never mind, it actually works when I remove the defaults.

Priority:Normal» Critical

Upgrading to critical; you can't create update any feature anymore once this bug hits. Basically once you have a feature enabled containing a field_collection that includes the import_entity default, any time you try to update any other feature through drush you get this error (since it tried to get the defaults for all existing features before updating the desired one).

The only work arounds are to either remove the default from the feature (set it to NULL), or to create the field_collection field manually (though you don't have to set up the collection's fields).

EDIT: Something just occurred to me. Might it be that the entity_import function is run BEFORE the field it's attached to is created? The problem then is that the field (of type field_collection) doesn't yet exist to import the collection's fields into.

is there any actual value added in having the field collection set a default value when it seems sufficent for just the children fields to set their own default values?

considering that the field instances that are attached to the field collections are not used anywhere other than the field collection that they are attached to, I think @pirog is probably right. If those field instances already have the default field values stored with them - which they do - then is this not just needless duplication? It's not like you could have the field instances define a default value and then override that in the field collection.

I will +1 for having the fields contained in a collection being responsible for their defaults. It does not make sense to me that the container would set those. What say the maintainers?

Status:Active» Fixed

If you are experiencing this bug, please try to reproduce using the beta4 release.

The patch in #46 was RTBC and committed, and has passed tests from others in multiple environments. Let's close this issue, open new ones if Features or other bugs are popping up, and I added #1834638: Reminder: Remove PDO workaround code when two core bugs are closed. to remind us to remove the workaround once the core bugs are resolved.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

moonray, pirog, mrfelton, twardnw: See #1649548: Setting default values in Content Types -> [content type] -> [field collection field] -> edit causes incorrect Features export for more info on this and the workaround. I'm going to retitle it as a follow-up to this one.

Issue summary:View changes

add resolution