PHP Fatal error: Cannot use string offset as an array in custom_formatters/includes/fieldgroup.inc on line 74
and the result is a blank WSOD page..
I'am using a field type "text" checked Handle multiple values formatter on a field that has multiple checkbox values (cck core text field). The formatter simply has a return 'TEST'
I tried both the stable and -dev releases and the same result.
Comments
Comment #1
abaddon commentedso for -dev is on line 74, for stable is on line 68, same code there in both releases, the problem is that the $item in question is not an array, but a string "custom_formatters_formatter_custom_formatters_FORMATTER_NAME" (formatter name is what i used for my formatter)
to fix it, im using the following code to skip the loop (added the if/continue block):
im not sure this isnt a problem from somewhere else just showing up in here.. but the fix works for me
Comment #2
nicholasthompsonI have just had the same issue - what file is that line "68"?
The problem actually appears to be when you select "Handle Multiple Values" on the formatter options, but the field you're applying it TO only has a single value (or at least that was the "fix" in my case). It'd be nice if a single formatter could be used for both Multiple and Non Multiple though...
Comment #3
decipheredFixed and committed to 6.x-1.x
Cheers,
Deciphered.
Comment #5
mirie commentedHi,
I am also having this issue with the latest stable release (6.x-1.5). The problem occurs when the field has multiple values.
In the function theme_custom_formatters_fieldgroup of fieldgroup.inc, line 68, I added the line
as comment #1 suggested. However, I see in #3 that this was fixed and committed. What version should I be using?
Thanks!
Comment #6
asb commentedHi,
I'm getting this fatal error when trying to load a page with a content type where the custom formatter is not even used. Error:
Disabling the Custom formatter has no effect in regard to the fatal error. So basically one custom formatter I'm using on content type A kills all nodes of content type B. Since this affects the whole Drupal installation, I'm adjusting the priority to critical. This applies to recommended release custom_formatters 6.x-1.5 from 2011-Apr-13.
Next I upgraded to custom_formatters 6.x-1.x-dev from 2011-Aug-25 and issued a 'drush cache clear' (all). This resulted in another fatal error:
Also this killed the complete site (the fatal error mentioned above when accessing anypage on the site). Thus I downgraded to the 6.x-1.5 release via drush (thank god for drush!), enabled the one custom formatter I was using to be able to remove it from the content type A's display settings. Accessing a node of content type B still resulted in the fatal error:
Next I deleted my one custom formatter at
.//admin/build/formatters, disabled and uninstalled the 'custom formatters' module, and deleted the module's files. Hooray! I have access to nodes of content type B again.My one custom formatter is was labelled "Converted EXIF Value"; it is was applicable to field type "text" and uses the following PHP code:
I don't have the faintest idea what this code does to fieldgroups on content type B, or whatever 'custom formatters' actually is breaking. "Allows users to easily define custom CCK Formatters" - sorry, this module is neither usable for "users", nor does it anything "easy". This is a pure developer tool, and it'd be really nice if the project page would state that honestly. Normal "users" or even site builders will simply damage their sites, and waste lots of time for nothing.
Comment #7
decipheredasb,
If this was a major issue, it would have be reported by more than a handful of people. I don't doubt that the issue is present for you, but I think your reaction is a little over the top.
While I do agree that this is somewhat a developer tool, it is also simple enough for an average user to use (I've seen it repeatedly) when using the HTML+Tokens method, and nor does it 'damage their sites and waste lots of time for nothing.'.
A fix was committed for this issue to 6.x-1.x-dev, are you or are you not using that version?
If you aren't, please do, because if people never use the fix nor confirm that the fix fixes the issue how can I reliably release the fix to a stable release?
Comment #8
asb commentedRegarding this, please review the paragraph starting with "Next I upgraded to custom_formatters 6.x-1.x-dev from 2011-Aug-25..." in #6. And no, now I am not longer trying to use this module as the "stable" release causes significant damage, there is a known issue about this (#5072464), and supposedly there is even a fix for that issue (6.x-1.x-dev) which causes even more damage.
Imho this module by far isn't ready for production use and I was simply misguided by the existence of a "stable" release. This is a programmer's toy which requires in-depth debugging and coding skills, and I am not a code developer. Sorry for wasting your time.
Comment #9
decipheredasb,
Please understand, I do sympathize, however based on your own comments it's quite clear that the core issue, the critical issue, is not an issue with Custom Formatters at all, but some other glitch.
You're words prove this point:
There's two copies of this file, which implies that during the upgrade you didn't delete the old files. This may be an issue with Drush, or something else, but it is not an issue with the module itself.
Can you please confirm this by delete the 'custom_formatters/modules' directory?
Cheers,
Deciphered.
Comment #10
asb commentedThank you for your help, but, as I said, I'm no longer trying to use 'Custom Formatters'. I am happy for being able to restore my site and to mimic the needed functionality with 'Views Customfield' and a Views block.
Comment #11
decipheredasb,
Given that you accused the module of of being useless due to a possible mistake of your own, I am disappointed that you won't even take a few minutes of your time to confirm whether or not the functionality is broken.
I know as a fact that the original issue here is fixed and that your issue is due an error during updating of the module files, so I am marking this issue as fixed again, and will have a new stable release out shortly.
Cheers,
Deciphered.
Comment #13
dalu commentedI had the error message in my logs
Fatal error: Cannot redeclare fieldgroup_custom_formatters_theme()turned out that I have not deleted the dir previous to upgrading from previous version to 1.6
so modules and includes directory was present which resulted in this error message and a unusable site.
just a heads up for someone having the same issue
Comment #14
panosp commentedI was getting this error too when viewing a node. In my case it was using backreference fields within a fieldgroup. (Fields: Render back reference views as content fields and using this field in a fieldgroup)
Removing it from the group resolved the error.
Just an addition to the list of reasons. Hope this helps someone...