Bug #24726
closedNumbering of colPos inconsistent
0%
Description
This happens when working with less than the default 4 columns:
TSconfig:
mod.SHARED.colPos_list = 0,2
works as expected, only normal and right columns are shown.
However, using
TCEFORM.tt_content.colPos.removeItems = 1,3
to remove left and border column from selection field in CE, the column numbering is incorrect. The above setting will remove the NORMAL and BORDER column. The numbering here is corresponding to the physical position in the BE:
0 = LEFT (should be NORMAL)
1 = NORMAL (should be LEFT)
2 = RIGHT
3 = BORDER
(issue imported from #M17215)
Files
Updated by Steffen Gebert almost 14 years ago
Yes, it seems really confusing, however, as you pointed out, colPos_list deals with column numbers, whilst remove items deals with entires in the list (and is independent from colPos_list, as it works for every field of every table).
Reordering the entries in tt_content.colPos might lower the confusion, however break existing sites.
So I would say: won't fix, sorry...
Updated by Jochen Weiland almost 14 years ago
well, but then the behaviour is not consistent with older versions of TYPO3, since this IS breaking existing sites.
Updated by Jochen Weiland almost 14 years ago
Just for clarification: if you use this code in TSconfig:
mod.SHARED.colPos_list = 0,2
TCEFORM.tt_content.colPos.removeItems = 1,3
this will have the following effect:
in version 4.4.6 and below: in column view the normal and right columns are displayed and in content elements you can only select normal and right columns in the column select box.
The TCEFORM.tt_content.colPos.removeItems configuration ONLY affects the form
In version 4.5beta4/rc1: in column view only the right column is shown, the normal column does not exist anymore. In content elements you can still select normal and right columns.
The TCEFORM.tt_content.colPos.removeItems configuration ALSO affects the column view.
Updated by Steffen Gebert almost 14 years ago
Ah, okay.. I misunderstood. You didn't write that behavior has changed.
So this has to be investigated..
Updated by Jo Hasenau almost 14 years ago
So if I got you right and from my own experience trying to reproduce this bug:
This one is buggy
TCEFORM.tt_content.colPos.removeItems
while this one is OK
mod.SHARED.colPos_list = 0,2
so we just have to care about colPos.removeItems ?
Updated by Jo Hasenau almost 14 years ago
I guess I nailed down the problem:
It seems as if getColPosListItemsParsed in class.tx_cms_backendlayout.php behaves completely strange and does not what was intended.
Will come up with a patch today.
Updated by Jo Hasenau almost 14 years ago
I think I got it now:
removeItems ALSO affects the column view to make sure the user won't be able to create new content in a column that he is not allowed to use. This is a new behaviour introduced in 4.5, but it won't necessarily break existing stuff, unless the implementation is as buggy as it is i RC1.
BUT: The bug is just about the array key, which does NOT represent the actualy colPos Key used by the item. After fixing that, the keys match each other, so removeItems works as expected.
Updated by Jo Hasenau almost 14 years ago
Attached V2 fixes an additional bug: Pages with backend layout "none" should always show the default columns.
Updated by Ernesto Baschny almost 14 years ago
Committed to trunk, rev. 10287. Will be included in 4.5 RC2