Feature #88130
closed
Make colPos NULLable to avoid conflicts and workarounds of extensions
0%
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.
Updated by Dmitry Dulepov over 5 years 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.
Updated by Jo Hasenau over 5 years 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.
Updated by Benni Mack over 4 years ago
- Status changed from New to Needs Feedback
Jo Hasenau wrote:
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.
I think making it nullable having it "DEFAULT '0'" would be beneficial and ease the pain for gridelements. I would also recommend adding a fixed colPos value for EXT:gridelemnets in general though, but that's not in my hands. Making a large colPos or signed colPos field seems like most workarounds... I've seen backend layouts with a really high (like colPos>300) with just backend layouts without third-party extension. Limiting this to a fixed "core" area would be very complicated. This is a similar issue as with pages.doktype (with certain pre-defined values and a possibility of overlaps if multiple extensions are used) and with TypoScript page.typeNum, but this is something core cannot or should not limit or guarantee that there won't be any conflicts.
Updated by Georg Ringer 6 months ago
- Status changed from Needs Feedback to Rejected
I am rejecting this issue as changing the behaviour and adding null might sound easy but I am pretty sure that we would get a lot of other issues, also for integrators because code just used an intval which will then convert null back to 0 which would make it even worse then.