Project

General

Profile

Actions

Feature #88130

closed

Make colPos NULLable to avoid conflicts and workarounds of extensions

Added by Jo Hasenau over 5 years ago. Updated 6 months ago.

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

0%

Estimated time:
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.

Actions

Also available in: Atom PDF