CEs dropped in flux container that are within a gridelemnts container get lost.

[paul-hph]

TYPO3 V: 10.4.36
EXT:gridelements : 10.4.3

FluxContainerWithinGridElement.mov

[NamelessCoder]

@paul-siteway I doubt there's anything I could do about this problem. Gridelements works by overriding the colPos value of content within its content areas, setting it to -99. Flux works by using a calculated, unique colPos value for each content area. In this case, Gridelements does not appear to respect that the moved child is not a direct child of a content type which Gridelements should handle, and therefore incorrectly forces the child content element to receive colPos = -99.

I would suggest that you report this issue to the Gridelements tracker and reference this comment. It should be a relatively simple matter for Gridelements to implement a sort of condition that disables their special colPos overriding in cases where the content area is not a direct child of a Gridelements-managed content type.

[Bunnyfield]

@NamelessCoder Paul sent me to this bug report to check if the idea might be working.

First of all - the colPos is -1 not -99

Second the problem is not, that Gridelements is overriding something, but that Flux does not, although it would be responsible for the specific action.

While the D&D action works fine, when you drag the element out of a Flux Container into a Gridelements-Container column, it is broken, when the user drags the element back into the Flux container. So Flux misses to (re)assign the necessary values to its child elements, which is something Gridelements does not have to take care of.

My recommendation for @paul-siteway was to stop using both approaches at the same time, since it does not give the users any benefit but increases the possible problems. Still if they are used together, we should make sure that each container variant takes care of its children properly without interfering with the child elements of the other.

[NamelessCoder]

@Bunnyfield Flux doesn't actually do any assigning of colPos values as such. Instead, it uses the core's functionality to render a standard content area with a special colPos. The colPos is extracted and assigned by the core just like any vanilla drop zone. Unless the dropzone is somehow modified, or the record's colPos value is somehow changed in a DataHandler hook (Flux does not do this) I would expect Flux to be unaffected.

I see for example in Grideleements' DataHandler hook listener, that if tx_gridelements_container is filled in the record being moved, this forces the colPos value to become -1 (https://github.com/CodersCare/gridelements/blob/master/Classes/DataHandler/PreProcessFieldArray.php#L271). Is it possible that this tx_gridelements_container value is somehow preserved instead of cleared, when the child record is moved into a Flux column nested within a Gridelements container (technically, it leaves the Gridelements container)?

@paul-siteway it might help us to determine the actual cause if you could provide a dump of the child content record's columns before and after the last move.

[Bunnyfield]

@NamelessCoder Thanks for the quick reply and the investigation. If PreProcessFieldArray would be the culprit, we need to find out, why the drop action actually provides this key in the field array, because usually the fieldArray only contains values that have been changed in the editing form and/or during a drop or paste action.

So while dropping into a Flux container I would not expect the key "tx_gridelements_container" in that field array at all.

Still it could be there with a value of 0 though, to make sure it will be changed back from a positive value. - Maybe this could be part of a fix already.

[NamelessCoder]

@Bunnyfield I'm just shooting from the hip here, but could the problem be that Gridelements JS is triggering and/or assigning a drop event listener recursively on every content drop-zone within a Gridelements container, rather than just on direct-child drop-zones, causing the XHR data that gets dispatched when dropping the element in a Flux column inside a Gridelements column to unexpectedly be extended to contain tx_gridelements_container with a positive value?

Maybe @paul-siteway could also check the browser's XHR log to see what data is being dispatched when dropping a content element in a Flux column within a Gridelements column.

[Bunnyfield]

If this would be the case, nested Gridelements containers should have the same problem - but lets wait for some data from @paul-siteway