Feature #88130

Make colPos NULLable to avoid conflicts and workarounds of extensions

Added by Jo Hasenau 7 months ago. Updated 6 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
DataHandler aka TCEmain
Target version:
-
Start date:
2019-04-10
Due date:
% Done:

0%

PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

Just an idea, how to solve the problems for any extension abusing negative or very large positive colPos values for child elements in one go:

How about making colPos NULLable?

This way we could still determine children by their parent field, which is tx_gridelements_container for Gridelements but they would not pop up in the "normal" column anymore. And we get rid of the problem people have when doing a database compare with Gridelements uninstalled, since this will break their negative values.

First problem solved:

Child elements, which are created in the tt_content table, should not have a colPos value at all, since they are not located in any column of the page module.
Workaround for flux 18181, mask 999, gridelements -1.
Each of them should have NULL as a colPos, so we don't need to make colPos SIGNED.

Second problem solved:

Because colPos is SIGNED for Gridelements, the extension must be installed during database compare actions, which is not the case, since people are told to uninstall extensions before upgrading the core.
It's not a big deal, since you can get children back with a single query based on their container ID, but it would be better, if there would be NULL as a possible colPos value from the core already,
since we would not have to change the database information at all then. Still '0' could stay as the default value.

Nice side effect:

If NULL would be possible, elements would not be recognized as "unused" anymore,
so we would not need a hook anymore to tell the core, that they are used as child elements.

History

#1 Updated by Jo Hasenau 7 months ago

  • Description updated (diff)

#2 Updated by Jo Hasenau 7 months ago

  • Description updated (diff)

#3 Updated by Jo Hasenau 6 months ago

  • Description updated (diff)

#4 Updated by Dmitry Dulepov 6 months ago

I'd rather make it signed and large.

#5 Updated by Dmitry Dulepov 6 months ago

Or better: introduce reservation of colPos values in the core. If an extension wants to have a dedicated colPos, apply for it, get a value and put it somewhere to the documentation. There can be a range set for such values (from 10000 to 65535, foe example). If extension applies for reservation, docs are updated with the name of the extension and column number. There will be no conflicts this way.

#6 Updated by Jo Hasenau 6 months ago

If we just go for NULL and extensions provide their own parent field, we won't have any need for reserved colPos values.
So IMHO negative values and large values are just workarounds, while NULL will actually tell the truth about those content elements, namely that they are not located in any column of a page at all.

Also available in: Atom PDF