Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I'm not 100% sure if this is a problem with field_collection, but it seems to be.
I'm trying to export a content type with Features and I get a PHP Parse Error when I copy the feature under sites/all/features/my_content_type/
PHP Parse error: syntax error, unexpected '{' in /Users/user/Sites/sitename/sites/all/modules/features/play_content_type/play_content_type.features.field.inc on line 844, referer: http://sitename.dev/
When I create the feature without including any fields which are part of a field_collection, I don't get any errors.
Just asking here if anyone has this problem and where should I look to try to fix it?
Comments
Comment #1
mErilainen CreditAttribution: mErilainen commentedIt seems that there is something hairy going on here (the default_value of the field_instance doesn't have proper syntax according to parser):
I have another date field also which is not inside a collection and that one works normally. On the other hand I have another field collection which has a text field and a node reference field, and they also work normally. So it seems that field collection doesn't like date fields inside it.
Comment #2
mErilainen CreditAttribution: mErilainen commentedI had a default value for the date field for some reason, which I don't need. After removing the default value I can export the feature without breaking the site. But the issue is still valid if someone wants to export fields with default values, but I'll close this since I'm not sure if this has anything to do with field_collection anymore.
Comment #3
pcambraThis has happened to me exporting a field collection with default addressfield values.
Comment #4
svdhout CreditAttribution: svdhout commentedThe same thing occurs to me when i try to enable a feature containg a field_collection.
I have a collection with a field 'List (text)' and the 'Check boxes/radio buttons' containing default values.
The error in the feature's code:
Update: After removing the field_collection, and adding it again everything worked fine
Comment #5
rlnorthcuttI got the same error message on my local and a 500 error on the dev server when trying to view the Features page.
Removing the default values removed one error (so thats still an issue), but it still happened. I finally tracked it down to a field collection that referenced another field collection. I created a field collection on a user profile (Profile2) for address with these fields:
- address1 (text)
- address2 (text)
- city (text)
- state (list)
- zip (integer)
- hours (field collection)
The Hours field collection contained 4 fields:
- day (text)
- start (list-float)
- end (list-float)
- closed (checkbox)
When exporting the feature, I got the error on my local and the 500 error on the server when clearing cache or trying to view the Features page. The only way I could fix it was either to overwrite the feature with an older one OR manually removing the field references in the field list .inc in the feature.
Now the errors are gone and I can access Features again, but the state of the feature never leaves "checking"...
Comment #6
rlnorthcuttFYI - here is the error I get on my local:
"Parse error: syntax error, unexpected '{' in C:\wamp\www\swooperdeal\drupal\sites\all\modules\features\features.export.inc(574) : eval()'d code on line 242"
Comment #7
tim.plunkettComment #8
robert.laszlo CreditAttribution: robert.laszlo commentedI am having the same problem. My Field Collection includes Address Field module fields (http://drupal.org/project/addressfield), and this module requires the use of a default value for Country (although the developers of the module are debating changing that). The result is that I can't export this content type as a Feature.
Comment #9
tim.plunkettThis is coming from entity.module's
EntityAPIControllerExportable::export()
: http://drupalcode.org/project/entity.git/blob/refs/heads/7.x-1.x:/includ...It's called by
entity_export()
, which is in turn called byexport_render()
, which is kicked off by Entity's implementation ofhook_features_export_render()
.Field collection might have to define it's own import and export. Not sure what it would do instead though...
Comment #10
bofrost CreditAttribution: bofrost commentedComment #11
bofrost CreditAttribution: bofrost commentedComment #12
bofrost CreditAttribution: bofrost commentedsame here... after exporting a feature with addressfield
Comment #13
tim.plunkett@Drupaldise, please stop subscribing, start following.
Comment #14
Bevan CreditAttribution: Bevan commentedI think the bug is further upstream, in the Features module, probably in
features_var_export()
or something close to it.Field Collection (and Entity API) render the exportable configuration for the default value of node-instances of a field collection as JSON with
entity_var_json_export()
.Features' exporter does not wrap the JSON in a string—possibly because it expects a PHP/
var_export()
string instead of JSON or because it thinks that the string is already a PHP/var_export()
string. The formats look similar and any syntax detection with regex or character-searching would be difficult to implement and likely to be buggy.I could not debug this further because the bug went away and Features began exporting the code fine, for no apparent reason. Possibly because I installed Strongarm or manually added single quotes around the unquoted JSON. However even after removing the field configuration from the Features-package and adding it to a new Features-package, I could not reproduce the bug. Odd.
Comment #15
chalee CreditAttribution: chalee commented@Bevan: You said in #14 above "I installed Strongarm or manually added single quotes around the unquoted JSON...". Can elaborate on where exactly you place the single quotes. below is the snippet of my code giving the error.
Comment #16
stevectorThis bug was also reported over here #1188898: Exporting a field_collection field resulted in fatal errorful code due to default value having {} in it
Comment #17
Bevan CreditAttribution: Bevan commentedchalee;
would become
to become syntactically correct PHP. I changed lines 6 and 12.
Comment #18
chalee CreditAttribution: chalee commented@Bevan: Thanks.
Comment #19
drubbels CreditAttribution: drubbels commentedThanks @Bevan, worked for me too!
Comment #20
bschilt CreditAttribution: bschilt commentedI'm experiencing the same issue. I have a date field as part of a field collection. The potential solutions mentioned in the previous comments haven't worked for me yet.
Comment #21
bradjones1This still needs a patch and I'm happy to help - though can anyone point me to the right place in Features module were the export actually happens? Re: any relation to Strongarm module, I have 7.x-2.0-beta4 installed and I still get this error... so using both modules in tandem doesn't seem to be a workaround (at least not for me.)
Comment #22
bradjones1Following up on my own in #21:
Bevan said testing on the string to determine if it is JSON would be tough - but what about doing a
json_decode()
on the string and testing for NULL as the return value? Per the docs, if it doesn't evaluate, we should get NULL. (It also does so if the recursion limit is reached - but I'm guessing that's not much of an issue here.)See attached patch that tries that approach. It seems to export properly (that is, the feature doesn't give a fatal error) but the feature gets stuck in an "overridden" status.
drush fd
says, "Feature is in its default state. No diff needed." anddrush fr
refuses to revert since "Current state already matches defaults." So I suspect there's something else that needs to change to make this a complete patch.Comment #23
bradjones1Marking this needs review to get some eyes on the above patch - There's open debate as to where the proper place for this patch should be - that is, inside Entity API or Features... Some definitive input from a maintainer might help to get this in the right place and incorporated?
Comment #24
tim.plunkettNo one line conditionals, and mind the spaces after "if".
Comment #25
bradjones1Thanks for the nudge on coding standards. Try this?
Comment #26
bradjones1I am earnestly looking for some help on the best way to do this - case in point, the patch above addresses this issue, but has the side-effect of wrapping any other data that validates with json_decode() (booleans, integers, strings) in single-quotes. So at least the first time you update/diff your features after this is applied, you'll get a bunch of "false" changes as the files do indeed differ from the non-quoted versions on disk.
This may not be a huge issue at least for integers - they seem to be sometimes quoted anyway. Here's a diff just after a drush fua:
So there's a cid and pid that were quoted to begin with. I am however seeing some booleans (TRUE, FALSE) being quoted, which could be a problem?
Comment #27
bradjones1Sorry for lengthening this - I believe the attached patch should be much closer. The second parameter to json_decode() is to return an associative array, which would be what we're getting as input (in a {} string) - so if we set that to TRUE, ints, bools and strings appear to pass through unchanged and unquoted.
Comment #28
Bevan CreditAttribution: Bevan commentedBrad; I am glad someone has the time and energy to fix this. I think there is a better way to fix this bug at an architectural level rather than detecting whether or not a string looks like JSON.
Someone with thorough understanding of the internals of Features, Entity API and Field Collection modules would likely be able to either provide comprehensive direction, or fix it quickly. They are usually busy people though and are probably most effectively sought directly via PM or IRC.
Comment #29
Bevan CreditAttribution: Bevan commentedAlso, look out for #1086098: D6 JSON is total garbage - Create RFC 4627 compliant HTML safe JSON.
Comment #30
mrfelton CreditAttribution: mrfelton commentedPatch in #27 is working for me. Thanks.
Comment #31
hefox CreditAttribution: hefox commentedspace between $export, TRUE
I'm curious, if you call features_var_export on a something that will return a json, instead of an array of items that end up as json? I think the json detection is likely needed for whatever part returns the json (haven't looked into it at all to see if it's the object export code or the var_export fallback).
Also, is this a problem with ctools_var_export and drupal_var_export?
Comment #32
girishmuraly CreditAttribution: girishmuraly commentedWhy do we want to export in JSON format when we can decode it in features_var_export() anyway? For me, this lead to the Fatal error mentioned here #1281974: Missing bundle property on entity - related to translations on actually trying to create the content type that I just exported having a field collection field.
I had to wrap a drupal_json_decode() to the export itself like:
Comment #33
jeffschulerPatch in #27 worked for me.
Comment #34
ygerasimov CreditAttribution: ygerasimov commentedIf we dig into Entity API on example of Field Collection, features_var_export() on FieldCollectionItemEntity object calls EntityAPIController::export() method. And this export() method calls entity_var_json_export() that is prettier looking drupal_json_encode().
Please review attached patch that will not enclose non-objects.
Comment #35
pwaterz CreditAttribution: pwaterz commentedThere is a problem with the above patch. When the json object get read back into drupal, it doesnt get json decoded. It directly related to this bug http://drupal.org/node/1281974
Comment #36
hefox CreditAttribution: hefox commentedComment #37
pwaterz CreditAttribution: pwaterz commentedI think #32 is on the right track.
Comment #38
pwaterz CreditAttribution: pwaterz commentedHere is an updated patch that should resolve the import issue.
Comment #39
KLicheR CreditAttribution: KLicheR commentedTested patch #38
We applied the patch on source and destination sites, exported the feature and re-imported it into the destination site. Then we went to add content of the type including the field collection concerned, and got this error:
Here is a dump of the pertinent lines in our field.inc:
We found it off that the entire drupal_json_decode() call was in single quotes, so we tried this again moving the single quotes to encapsulate the json string (
drupal_json_decode('foo')
instead of'drupal_json_decode(foo)'
) - but continue to get the same error.Comment #40
pwaterz CreditAttribution: pwaterz commentedCan you go into common.inc where entity_extract_ids is defined and right before where is says 'throws new...' put 'debug($entity);' and paste those results here.
Comment #41
KLicheR CreditAttribution: KLicheR commentedIn response to #40:
I founded that if a manually change the JSON object in the field.inc file, it work:
BEFORE
AFTER
or
Comment #42
danmuzyka CreditAttribution: danmuzyka commentedThis is a very difficult issue to solve...thanks to all who have worked on this so far.
I created a patch that exports entities in the format in the AFTER code block in #40. I found it worked OK until I did a features-revert, at which point the default_value stored in the field_config_instance table in the database was no longer correct. At that point, I could no longer edit my field_collection field nor save new article nodes (which have the field_collection attached to them).
Here is my Features-exported field_collection:
Here is an example of what the database had BEFORE the features-revert:
data column from field_config_instance
Here is how the same table cell looked AFTER the features-revert:
data column from field_config_instance
If you look carefully, you'll see that in the first instance, the entity is stored as an object of class
FieldCollectionItemEntity
, whereas after the features-revert it is converted to a genericstdClass
object. This, of course, is the limitation of converting the object to an array and then casting it as an object again.Unfortunately, since the current approach is based on
var_export()
, which is not the most convenient way to store an object as a string, converting the object into an array and then casting it back to an object is the best method I know for getting an object into code using this method.Perhaps we would be better off using
serialize()
instead ofvar_export()
to store objects in features, but I have a feeling that approach would require a huge amount of code refactoring.Any thoughts/suggestions?
Comment #43
pwaterz CreditAttribution: pwaterz commented+1 serialize
Comment #44
hefox CreditAttribution: hefox commentedlike #1437264: features_var_export is converting custom class objects to arrays if don't have export method?
Comment #45
danmuzyka CreditAttribution: danmuzyka commentedI'm attaching my stopgap patch (that doesn't really solve the underlying issue) in case it helps illustrate the approach I described in the comment above.
@hefox It is not exactly the same issue...in this case, there is actually an existing export method for Field Collections (
class FieldCollectionItemEntity
), which they inherit from the Entity API module (class Entity
). TheEntity::export()
method callsEntityAPIController::export()
, which generates the JSON code that is being discussed in this ticket:The JSON code doesn't seem to generate the field_collection field settings in the database correctly when I run drush features-revert, however. These are the settings that live in the
data
column of the tablefield_config_instance
.I also see that there is a
EntityDefaultFeaturesController::export()
method in the Entity API module, which I believe is used for exporting entities themselves to Features code. The issue here is that the default settings for field_collection fields that are attached to nodes use the JSON generated byEntityAPIController::export()
, which doesn't seem to capture everything needed.I'm wondering if this is really an issue with
EntityAPIController::export()
and perhaps this issue should be moved to the entity module queue...I am not familiar enough, yet, with the purpose of that method and its accompanyingEntityAPIController::import()
method to know for sure if that is where the change should occur.Thoughts everyone?
Comment #46
zorroposada CreditAttribution: zorroposada commentedI used this patch; it worked fine for exporting a feature that contained a content type with a field collection in it.
But, I started having troubles when I exported other features that contained nodequeues. So, I changed it a bit so that the JSON code doesn't get included.
Comment #47
pwaterz CreditAttribution: pwaterz commented+1 to #46
Comment #48
mr.york CreditAttribution: mr.york commentedpatch
Comment #49
czigor CreditAttribution: czigor commentedPatch #48 works for field collections, thanks!
Comment #50
danmuzyka CreditAttribution: danmuzyka commentedI will try this again to verify when I have time, but I believe my patch still doesn't solve the underlying issue, because if you have a field collection with customized default settings, and you export it to a feature and then later run a features-revert, the field collection settings get messed up in the field_config_instance table because they no longer reflect the correct PHP class (they are converted to stdClass).
This patch is really just a bandaid...I more complete solution is needed. I'm going to try to look for a better solution as soon as I can make some time to do so....
Comment #51
Macronomicus CreditAttribution: Macronomicus commentedThanks #48 does mostly fix it, at least there is no wsod after enabling the feature now, still its like you said, seems some field settings didnt all carry over.
Comment #52
czigor CreditAttribution: czigor commentedOK, as its name suggests #48 does not really fix it. I had to manually set the default_value of the field collection to an empty array:
Comment #53
David_Rothstein CreditAttribution: David_Rothstein commentedI spent a while looking into this issue, and I think @danmuzyka has the right idea here (e.g. in #45).
The Features module's export format is PHP, not JSON. It's therefore not its job to try to detect JSON (or any other type of data) and convert it into PHP. Rather, if a module is overriding Features' export method, it's the module's job to make sure that valid PHP is produced in the end. (For an example of a module that does that correctly, converting its own native JSON format into PHP for a Features export, have a look at Rules.)
The proof of this is that even if Features were changed to look for JSON, that still wouldn't fix the fact that the exported field collection object is the wrong class (see #42) or that putting JSON in the {field_config_instance} table still won't actually work (i.e., the default value will not take effect) because that's not how Drupal normally stores things.
The problem here might actually be a name clash; Features assumes it can call $object->export() when a feature is being exported, but the Entity module uses the export() method for something else, namely direct JSON-based exports via the user interface. So it seems like it might just be called accidentally here. Maybe the ultimate correct solution is for one of those modules to change its API?
In the meantime, since Field Collection entities are not exportable via the UI anyway, but are exportable via Features when they are attached as a field somewhere else, it might make sense for Field Collection to simply override Entity here and use the export() method the way Features expects it to. That's what I did in the attached patch; it's not really an ideal solution, but it does work for the time being.
Comment #54
hefox CreditAttribution: hefox commentedI think either features either a way to detect whether the export method is valid and use it (else not use that function and export as it would if that method didn't exist), else entities provide a way to return valid PHP; opened #1566104: Provide a method to return PHP from export method along that line.
Comment #55
David_Rothstein CreditAttribution: David_Rothstein commentedIf there were a way to detect whether an export method is valid, then that (combined with #1437264: features_var_export is converting custom class objects to arrays if don't have export method) does seem like it would solve this issue... but also seems like it would be tricky to do that detection?
Comment #56
hefox CreditAttribution: hefox commentedWould likely have to
Comment #57
emptyvoid CreditAttribution: emptyvoid commentedThe #53 patch does indeed fix the object for the features index can properly render and the feature will validate. However, how I get the following on every page of the site.
Comment #58
emptyvoid CreditAttribution: emptyvoid commented#53: field-collection-export-1269750-53.patch queued for re-testing.
Comment #59
30equals CreditAttribution: 30equals commentedjust applied patch from #53, and i got no parsing error anymore, nor do i have the problem mentioned in #57.
Comment #60
30equals CreditAttribution: 30equals commentedupdate: when i enabled my exported feature (after the patch) with drush, i got the following drush error:
class_implements(): object or string expected entity.module:304 [warning]
in_array() expects parameter 2 to be array, boolean given [warning]
entity.module:304
#304 in the entity.module file is part of the entity_import function, so i guess it's related to this issue..?
Comment #61
marvil07 CreditAttribution: marvil07 commentedThis is the patch from comment 53, but it uses the entity type instead of a class name, which is what
entity_import()
expects.Comment #62
estrejlau CreditAttribution: estrejlau commentedI'm getting the following error after applying the above patch: "Strict warning: Declaration of FieldCollectionItemEntity::export() should be compatible with that of Entity::export() in include_once() (line 100 of [...]/sites/all/modules/contrib/field_collection/field_collection.module)." Any ideas?
Comment #63
agentrickardMake sure the arguments passed to the method are the same in both implementations and then update the patch.
Comment #64
estrejlau CreditAttribution: estrejlau commentedThanks agentrickard.
Comment #65
kenorb CreditAttribution: kenorb commentedThe same problem here.
Comment #66
sluceroThe patch in #64 has worked well for me and fixed the issue in all my test cases.
Comment #67
pwaterz CreditAttribution: pwaterz commentedI am having an issue after patch 64. After Collection field is featurized i get an error with no message when i try to edit the field settings.
Comment #68
pwaterz CreditAttribution: pwaterz commentedI was able to get it working by completely recreating the feature.
Comment #69
tim.plunkettAssigning for review tomorrow/this weekend.
Comment #70
tim.plunkettI was able to test this and it worked wonderfully. Thanks to bradjones1, ygerasimov, pwaterz, danmuzyka, mr.york, David_Rothstein, marvil07, eroepken and everyone else!
http://drupalcode.org/project/field_collection.git/commit/92a68e3
Comment #72
Amber Himes MatzWhat exactly is "fixed?" Or what are the steps necessary to implement this fix? I have updated field_collection to the June 8 dev and recreated my features. Still getting errors.Recoverable fatal error: Argument 1 passed to field_collection_item_is_empty() must be an instance of FieldCollectionItemEntity, instance of stdClass given, called in /mysite/sites/all/modules/contrib/field_collection/field_collection.module on line 1271 and defined in field_collection_item_is_empty() (line 693 of /mysite/sites/all/modules/contrib/field_collection/field_collection.module).andEntityMalformedException: Missing bundle property on entity of type field_collection_item. in entity_extract_ids()(line 7539 of /mysite/includes/common.inc).
Update: Through some serious blunt force, mashing of keyboard, and tapping my heels three times, it is now working.