TableField deletes cells and content during save if multiple tablefields are present

same problem here, also D7 beta4

I'm going to need some help diagnosing this one as I really don't have any free time these days.

Patches? Thanks!

I have the exact same problem (as soon as there is more than one table field in the form).

Poking in the code hasn't gotten me any farther yet unfortunately.

Just a quick update. I found some time this afternoon to poke around. It's going to be a frustrating fix :(

Inside of hook_field_presave, you get the argument &$items, which contains the Form API-style form submission for each widget in the form. Unfortunately, this is only sending correct values for the /last/ changed row/col count... as you have pointed out.

We need to figure out a way to access each one when the form is submitted. Before you hit save, the row/col counts are still correct. Somewhere in the process, the Field API is ignoring previously Ajax-altered form elements.

I'll keep digging, but any help would be very appreciated ;)

Ok, I /think/ I nailed it. When the form widget is produced in hook_widget_form, we need to figure out what is happening - rebuild, csv, load from db, or use defaults. The conditional that was rebuilding the widgets was too specific, and only tracking the table whose button was clicked. This effectively sent the others to the else condition to load the defaults.

This patch should fix the 7.x-2.0-beta4 branch. If it works, I think it can be easily applied to 6.x as well.

Let me know if it works!

I applied the patch and it did not help me. It seems as if when there are 2 table field controls on the node and you change the rows/columns on one of them, it tries setting the other to the "default" number of columns/rows. I will take a look to see if I can figure out why.

The code at line 293 is a little confusing to me:

// Determine how many rows/columns are saved in the data
if (!empty($default_value)) {
$count_rows = count($default_value);
$count_cols = 0;
foreach ($default_value as $row) {
$temp_count = count($row);
if ($temp_count > $count_cols) {
$count_cols = $temp_count;
}
}
}
else {
$count_rows = count($default_value);
$count_cols = isset($default_count_cols) ? $default_count_cols : 0;
$count_rows = isset($default_count_rows) ? $default_count_rows : 0;
}

it looks like it sets the number of rows to the "default" value in either case. Am I missing something? I do not see the number of rows variable available or I would just set it in the "else" condition. Any help would sure be appreciated.

Have any updates of this problem?

I have fixed this problem, tomorrow I will test and I will create patch.

@DmitryDrozdik, thanks! I'll keep my eye on it and try to get it into a new release.

Here is my patch.

I just noticed this problem in Beta 5.

Has this patch been tested? Looking in tablefield.module the patch does not appear to have been committed yet.

I applied the patch in Beta 4 and it seems to work.

I was confused because I had a node created today and the tables went blank. Based on this issue, it appears nodes containing more than one table, have all the tables deleted when the node is updated and saved. In my case the two tables were in separate fields.

To test the patch I created a new node with two tables in two dfifferent fields, saved the node, updated the node with various changes in different fields a few times, and the tables remained intact.

EDIT

I apologize, the problem I have appears to be different.

The problem I have occurs when I update a node via Editable Fields - all the tables in the node are deleted:

http://drupal.org/project/editablefields

Also found this similar but perhaps unrelated error, where tables are deleted when files are uploaded, with working patch:

http://drupal.org/node/1103020

With the 2.0 release a month ago, I am confused: did the patch here find its way into the new stable (?) release, or not? Should this issue be closed? I find it hard to believe that a stable release could be pushed out with this kind of bugs unsolved... (or should the priority of this issue be downgraded for some reason currently not apparent here?)

I have not yet tested this module (because of the status of this bug), so not sure if the 2.0 release has this problem or not. Can anyone confirm?

I have the same problem with 2.0. I would recommend staying with beta6 until the stable release is fixed.

Scratch that 2.0b6 and 2.0 are identical. Not sure why the one wasn't working but I reinstalled 2.0, flushed all my caches, and everything seems ok.

had the same problem and some observations:

in the serialized array in the db table you have some kind of index like "tablefield_csv_field_XXXXX_0". I guess the 0 is the delta. I am working with entity translation and I have for this entity_id two entries with the same delta.

Please remember that there are 4 columns building the table index for fields, the entity_id, deleted, language and delta. perhaps it helps if you use all of them to build this internal index.

Perhaps this explains my problem or this has nothing to do with the problem.

Regards

There may be a better way of doing this but I believe this patch should fix the issue.

this patch did not work for me.

Based on my tests, none of the previous patches fix the problem:
the module only saves the last change in the DB,
so any previous translation for the table is lost.
Only one record per node or entity is saved, but it should be one
record per node/entity AND per translation.

The bug seems to be caused by the messy code in hook_field_widget_form(),
it does not returns all the saved records in the array, only the last one.

As the maintainer himself acknowledged in #5, the fix is not easy,
due to the complexity of how the code handles the form states,
may be a FAPI expert could help here (sorry, I am not).

This issue may be related: https://drupal.org/node/1194484

If 2-column tables are enough, and Entity translation support is urgent
(as it was my case), I recommend to use the Double Field Module,
it offers several useful display formatters and it works fine
with ET.

This issue has nothing to do with the entity translation problem. Therefore changing the title back to something more original.

But I can confirm that there is a problem with entity translation and opened another issue for that. #2231009: Existing (entity) translations are removed after saving a new translation

@aufumy: Don't highjack issues and change the complete topic. I was very confused after looking through the patches as they had nothing to do with translations.

@interdruper: The patches in this issue will not help with entity translation problems, you got confused by the misleading title like me.

Closing, as strictly speaking this issues has been fixed, even if there are other issues in the neighbourhood of what has been described.