Project

General

Profile

Feature #88130

Updated by Jo Hasenau almost 5 years ago

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: 

 h2. 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.View newer replies 
 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 extension 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.

Back