Resolution
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/*"
Comments
Comment #1
drupal a11y CreditAttribution: drupal a11y commentedThe whole project online: http://zananda.drupal-rocks.com/admin/
User: drupalbuddy
Pass: checkitout
If anybody wants to have a closer look, please login ;-)
THANKS !!!!
Comment #2
drupal a11y CreditAttribution: drupal a11y commentedAnother 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).
Comment #3
drupal a11y CreditAttribution: drupal a11y commentedOther 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).
----
Comment #4
tim.plunkettHere 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.
Comment #5
amitaibuI 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:
I wasn't able to solve it yet, but hope this info can help in finding a solution.
Comment #6
tim.plunkettThat is exactly where it fails for me as well, and I'm on PHP 5.2.13, will try with 5.3.
Comment #7
clashar CreditAttribution: clashar commentedsimilar 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
Comment #8
amitaibuDuplicate of #889286: EntityAPIController::load() produces WSoD sometimes with PHP 5.2
Comment #9
webthingee CreditAttribution: webthingee commentedConfirming that http://drupal.org/node/1084268#comment-4193072 does remove the error, and the module is usable.
Comment #10
fagoAs 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.
Comment #11
tim.plunkettIndeed, a "hacky hack". :) Not sure why I even posted it.
Comment #12
tim.plunkettCross 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 relatedComment #13
tim.plunketthttps://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.
Comment #14
fagoSo 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.
Comment #15
tim.plunkettIt seems to work once you remove the
throw new Exception("Invalid field name given.");
in __construct. But still WSOD without editing anything.Comment #16
honigferd CreditAttribution: honigferd commentedI 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)
Comment #17
pbuyle CreditAttribution: pbuyle commentedI've the same error using 5.3.3-1ubuntu9.5. But in my case,
FieldCollectionItemEntity::_constrcut
is called fromDatabaseStatementPrefetch::current
fromincludes/database/prefetch.inc
because I'm using SQLite (DatabaseStatement_sqlite
extendsDatabaseStatementPrefetch
). Looks like a bug in core.Comment #18
rossmerriam CreditAttribution: rossmerriam commentedsubscribing
Comment #19
pbuyle CreditAttribution: pbuyle commentedCore issue is #1264440: DatabaseStatementPrefetch doesn't set instance properties before calling _construct when using PDO::FETCH_CLASS
Comment #20
tim.plunkettFixing version
Comment #21
alaa CreditAttribution: alaa commentedsubscribing
Comment #22
sachbearbeiter CreditAttribution: sachbearbeiter commentedsub
Comment #23
sachbearbeiter CreditAttribution: sachbearbeiter commented@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 ...
Comment #24
pbuyle CreditAttribution: pbuyle commentedHere is a patch to workaround the issue in core.
Comment #25
tim.plunkettActually, that's not a bad idea.
Comment #26
kmajzlik CreditAttribution: kmajzlik commentedI 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.
Comment #27
jamesTbaker CreditAttribution: jamesTbaker commentedI'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!
Comment #28
leup CreditAttribution: leup commentedFile to patch :
field_collection.module
The workaround seems to work fine for me. Thanks !
Comment #29
jamesTbaker CreditAttribution: jamesTbaker commentedCygwin 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 :)
Comment #30
NicolasH CreditAttribution: NicolasH commentedsubscribe
Comment #31
gazwal CreditAttribution: gazwal commentedsubscribing
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)
Comment #32
ablondeau CreditAttribution: ablondeau commentedI can vouch for mongolito404's patch - module was unusable without applying it.
Comment #33
tim.plunkettI'm 100% okay with this patch, but I want to check with fago.
Comment #34
ChrDr CreditAttribution: ChrDr commentedI 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).
Comment #35
fagoYep, 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.
Comment #36
sam.spinoy@gmail.com CreditAttribution: sam.spinoy@gmail.com commentedI 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.
Comment #37
pbuyle CreditAttribution: pbuyle commentedWhat 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.
Comment #39
fagoRead #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.
Comment #40
pbuyle CreditAttribution: pbuyle commentedI 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.
Comment #41
pbuyle CreditAttribution: pbuyle commentedComment #42
kmajzlik CreditAttribution: kmajzlik commentedI 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.
Comment #43
dboulet CreditAttribution: dboulet commentedPatch 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.
Comment #44
mirian CreditAttribution: mirian commentedI 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???
Comment #45
mansspams CreditAttribution: mansspams commentedJust run accros same error. Using PHP 5.3.4 and building view listing field-collection items and trying to display non-existing fields.
Comment #46
pbuyle CreditAttribution: pbuyle commentedHere is the patch that should have been attached to #40.
Comment #47
dboulet CreditAttribution: dboulet commentedComment #48
dwwI 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.
Comment #49
tim.plunketthttp://drupalcode.org/project/field_collection.git/commit/3a13633
Postponed on #1264440: DatabaseStatementPrefetch doesn't set instance properties before calling _construct when using PDO::FETCH_CLASS. Committed the workaround.
Comment #50
John Pitcairn CreditAttribution: John Pitcairn commentedPatch works for me (applied from module root folder). 7.x-1.0-beta2, PHP 5.2.13.
Comment #51
bago CreditAttribution: bago commentedSame here on Centos 5 and php 5.2.13. Fixed upgrading to 5.2.17 from atomicrepo.
Comment #52
joshbgosh10592 CreditAttribution: joshbgosh10592 commentedHey 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).
Comment #53
John Pitcairn CreditAttribution: John Pitcairn commented@joshbgosh10592 - Apply the patch
Comment #54
joshbgosh10592 CreditAttribution: joshbgosh10592 commentedoh 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?
Comment #55
John Pitcairn CreditAttribution: John Pitcairn commentedIt'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.
Comment #56
Macronomicus CreditAttribution: Macronomicus commentedI 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.
Comment #57
Macronomicus CreditAttribution: Macronomicus commentedI 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.
Comment #58
mrfelton CreditAttribution: mrfelton commentedWe 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:
I suspect the use of entity_import() may be the cause?
Comment #59
pirog CreditAttribution: pirog commentedI am getting the same issue as 58. Currently unsetting the offending default value using hook_field_default_fields_alter. This is a workaround.
Comment #60
pirog CreditAttribution: pirog commented@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.
Comment #61
moonray CreditAttribution: moonray commented@pirog Removing the defaults seems to remove the fields from the field collection.Never mind, it actually works when I remove the defaults.Comment #62
moonray CreditAttribution: moonray commented#1269750: Exporting a Field Collection field with a default value to Features leads to a PHP parse error seems to be related.
Comment #63
moonray CreditAttribution: moonray commentedUpgrading 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.
Comment #64
pirog CreditAttribution: pirog commentedis 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?
Comment #65
mrfelton CreditAttribution: mrfelton commentedconsidering 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.
Comment #66
twardnw CreditAttribution: twardnw commentedI 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?
Comment #67
raspberryman CreditAttribution: raspberryman commentedIf 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.
Comment #69
wizonesolutionsmoonray, 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.
Comment #69.0
wizonesolutionsadd resolution
Comment #70
knalstaaf CreditAttribution: knalstaaf commented#1938620: Orphaned field collection items can exist in field_collection_item table
Comment #71
Elijah LynnComment #72
Logesh waran CreditAttribution: Logesh waran at Ameex-Drupal Geeks for Ameex-Drupal Geeks commentedComment #73
sreenivasparuchuri CreditAttribution: sreenivasparuchuri commentedwhen i am trying to create field collection through code, still getting same error.
Exception: Invalid field name given: field_skills is not a Field Collection field. in FieldCollectionItemEntity->__construct() (line 101 of C:\wamp\www\drupal7\sites\all\modules\contrib\field_collection\field_collection.entity.inc).
Once user login, using hook_user_login I am trying to create a collection, with some fields.
My php version is 5.5.12.
If any know, help me to sovle this issue.