Bug #44470
closed
Content elements in wrong column in page module
Added by Oliver Hader about 11 years ago.
Updated over 6 years ago.
Category:
Backend User Interface
Estimated time:
(Total: 0.00 h)
Description
If working on workspaces, it might happen that content elements just appear in the wrong column.
The reason is, that live(!) content elements are selected using a specific column value and then are overlays by workspace data.
If the column value has been modified in a workspace, this is currently just ignored during rendering.
- Status changed from New to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Under Review
- Status changed from Under Review to Resolved
Patch for TYPO3_4-6 has been dropped due to EOL
The solution causes an issue with the sorting buttons in page module because the colPos is ignored when attaching the sorting information in method PageLayoutView::getResult()
. (see #48939 and related)
I suggest to revert the patch and use #32967 and #39983 instead.
@Thorsten Kahler : the patches you mention do not solve this issue, nor do they solve the problem with the sorting buttons. This particular patch solved the problem that the content elements from the live workspace were first retrieved for each column and after that the workspace overlay was applied. If the column was moved to another column in the workspace it was displayed in the column where it was in the live workspace. This patch solves that by first retrieving the content elements from all columns, applying the workspace overlay and then distribute them to the columns.
The problem in getResult is that it was designed for use in a single column. The solution in https://review.typo3.org/25001 may not be perfect yet, but it will move the handling of the sorting links data to the right place.
Jigal van Hemert wrote:
This particular patch solved the problem that the content elements from the live workspace were first retrieved for each column and after that the workspace overlay was applied. If the column was moved to another column in the workspace it was displayed in the column where it was in the live workspace. This patch solves that by first retrieving the content elements from all columns, applying the workspace overlay and then distribute them to the columns.
If move placeholders are created when content elements are moved between columns the original code of
PageLayoutView
works flawless because
- placeholder records are fetched in the right column
- moved records are detected when applying the WS overlay
If changing the colPos is handled as move operation this doesn't only solve the BE display issue #44470 but also fixes FE preview.
The problem in getResult is that it was designed for use in a single column. The solution in https://review.typo3.org/25001 may not be perfect yet, but it will move the handling of the sorting links data to the right place.
The (IMO) "perfect" solution would be to use move placeholders consistently. Then there would be no problem with getResult()
.
Please try to change the column via drag-n-drop and via BE form to see the difference: drag-n-drop already creates a move placeholder.
- Status changed from Resolved to Closed
Also available in: Atom
PDF