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.
Error appeared every time when I view node with tablefield field.
Warning: Invalid argument supplied for foreach() in tablefield_field_formatter_view() (line 343 of /sites/all/modules/tablefield/tablefield.module).
Can you help me with this issue?
Thanks
Comment | File | Size | Author |
---|---|---|---|
#15 | tablefield_again_handle_null_field_values-2066929-15.patch | 741 bytes | rjacobs |
#14 | tablefield-empty_warning_fix-2066929-13.patch | 975 bytes | corentin.crouvisier |
Comments
Comment #1
aluzzardiI add a small change in the file and that solve that warning for me.
Comment #2
mortician CreditAttribution: mortician commentedError disappear. Thanks
Comment #3
Les LimComment #4
Les LimEven better would be to check for usable table data at the top of the loop, and go on to the next item if there isn't any.
Comment #5
Les LimComment #6
devad CreditAttribution: devad commentedI had a same issue:
Warning: Invalid argument supplied for foreach() in tablefield_field_formatter_view() (line 346 of /home/mysite/public_html/sites/all/modules/tablefield/tablefield.module).
Patch #4 fixed it.
Thank you aluzzardi, Les Lim.
Comment #7
aluzzardiHi Les Lim,
Thanks, you patch solve another problem on the header data.
Regards,
André
Comment #8
vitalie CreditAttribution: vitalie commented@devad, @aluzzardi could you help me reproduce this error for version 7.x-2.4 of the module? What are the steps? What are the settings that you have for your tablefield field? I did not apply patch in #4, still I do not get the error.
Comment #9
devad CreditAttribution: devad commented@vitalie
I have installed TableField module on xPalladium distribution together with bunch of other modules including i18n modules.
Field settings:
----------------
Required field: unchecked
Default: 3 columns, 4 rows
Number of values: 1
All three checkboxes: unchecked
Table cell processing: Plain text
D7.37
xPalladium distribution (doublemthemes) all modules and core updated to latest versions
i18n, 4 languages enabled
Comment #10
vitalie CreditAttribution: vitalie commented@devad, sorry, I still cannot reproduce. Could you tell me the values of the given tablefield field row in the respective field_..._data database table?
Comment #11
dieuweThanks, this patch fixed this bug. The conditions under which it appears are a bit vague, but the patch definitely cleans things up a little.
Comment #12
jenlamptonLooks like this needs a reroll for the latest -dev.
It would also be good to confirm that it's still necessary. There are some changes to this bit of code that may have fixed the problem and I'm not seeing the error on an empty table without the patch.
Comment #13
jenlamptonMarking as postponed until we can confirm this fix is still necessary.
Comment #14
corentin.crouvisier CreditAttribution: corentin.crouvisier commentedSame problem for me with tablefield 7.x-2.5 when empty :
Here a simple patch to remove warning and to do not render the element when empty.
Comment #15
rjacobs CreditAttribution: rjacobs at Center for Research Libraries commentedThis problem seems to arise for tablefield fields that have a row with a NULL value in their respective field_data_[name] table. What's not clear to me however are the exact conditions that can lead to such rows with NULL values. I've had a look at the code going back to 7.x-2.3 and it would seem that tablefield_field_is_empty() would be properly flagging empty tables (at least up to 7.x-2.5), which I think should prevent any field-specific data from going into the database in such cases. So how NULL values could get set certainly vexes me, though I might guess that it has something to do with past core changes to the field API or to field schema changes in this module. Anyway we have multiple production DB instances that demonstrate that is can happen (that have used various versions of this module over time), and it seems like we might not be alone. I suppose it's a safe conclusion that the current state of the code needs to be more robust to these NULL value entries, at least for some potential legacy support of old field data.
It seems like the proposal from #14 would work, but it also seems like it might be further complicating what appears to be some already convoluted logic in tablefield_field_formatter_view(). That field hook implementation has some conditions that seem to differentiate between not set (
!isset($tablesdata)
) and empty (empty($tabledata)
) rationalized table data. Why is that? It seems like an empty() check should be all that's needed, and when the tabledata is empty there is just nothing to render.Here's an alternative patch that might be cleaner/simpler, though it would be interesting hear back from a maintainer on the not set vs empty logic in case I'm missing something here.
Please also note that there is a conceptually related issue in #2796955: Empty tablefields are not property detected - can affect tablefields of all cardinalities. It's conceptually related in that some of the symptoms are the same (data is shown for fields that are empty), but I think the underlying issue is still a separate one. In this issue I think the problem is linked to the view handling of tablefield value data stored by previous module versions, but in #2796955 I think tablefield_field_is_empty() logic is failing, which is leading to potentially corrupt saved tablefield value data going forward. Anyway, a maintainer will likely want to investigate both these issues together and note that fixes to both issues seems to be needed to fully restore the expected empty table handling behavior.
Comment #16
lolandese CreditAttribution: lolandese at HCL Technologies Limited commentedAfter a refactoring of the code in #2697105: RFC: Proposal to Enable Table Data Storage as JSON this seems to be fixed or at least I am not able to reproduce.
Can you please check the latest dev?
Comment #17
lolandese CreditAttribution: lolandese at HCL Technologies Limited commentedComment #18
knalstaaf CreditAttribution: knalstaaf commentedSeems to be fixed in DEV.
Comment #19
lolandese CreditAttribution: lolandese at HCL Technologies Limited commentedNice. Thanks.