Drag & drop addition adds meaningless numbers to table data, could break integrating code

Just coming here to report similar issues, all my tablefields got broken after testing the upgrade to the latest tablefield version.

This change should have been at least mentioned in the 2.4 release:

https://www.drupal.org/project/tablefield/releases/8.x-2.4 →

Confirmed. This breaks decoupled sites because the code adds weight data at the form level, then removes the data on render. However in decoupled sites (through graphQL or JASONAPI) the weight data is not removed and the FrontEnd has no idea there is extra data to remove.

Duplicate of https://www.drupal.org/project/tablefield/issues/3221175 🐛 Column weight is shown as a seperate column Active

+1. Adding a patch that disables the weighted data.

+1. Added a patch that disables the weighted rows for those who may find it useful.

In looking at the submitted patch, I think it needs to go deeper and revert all the related code.
https://git.drupalcode.org/project/tablefield/-/commit/26d63be6aa25d34d1...

This would of course wipe out the option of drag and drop, but it "un-breaks" the module for anyone that is running a decoupled site and is now dealing with extraneous data being added to content.

Good call, swirt.

This should roll back the changes made in Issue 3040358 - Drag table rows (https://git.drupalcode.org/project/tablefield/-/commit/26d63be6aa25d34d1...).

Thanks @tsquared212 this does what it needs to and is being used on our production. Data saved under the un-patched code, needs to have the extra column removed and re-saved. I am changing this to RTBC.

HOWEVER, this is really a stop-gap measure as it reverts the draggable table rows. At some point, the solution that @bvoynick suggested should be looked into as a more permanent fix.

Patch #9 works for me on 2.4.0, +1 for RTBC.

This is causing warnings in the Charts Field Formatter contrib module, ref 🐛 Undefined array key warning with Tablefield 2.4 Needs review .

As the patch at #9 is only a stop-gap approach, I guess this ticket should be 'needs work'.

In the meantime, how about an approach like this patch, to change what's considered 'empty', with the same condition as the formatter? That way, the field will get wiped on saving, if the weight is the only thing that's saved in the table. I've also replaced a !empty($cell) with strlen($cell) because otherwise the number '0' isn't considered a non-empty cell value.

Those are good points @james.williams. Just a note that neither @tsquatred212 nor I are on the project that had a need for this fix. It is not that I don't want to see this fixed, I just no longer have an existing site that was broken by this to test this against.

This is a re-roll of patch #9.

This is a re-roll of patch #18 with coding standards fixed.