Project

General

Profile

Actions
Copy link

Bug #44470

closed

Content elements in wrong column in page module

Added by Oliver Hader about 12 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Oliver Hader
Category:
Backend User Interface
Target version:
4.5.23
Start date:
2013-01-13
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

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.

Subtasks 1 (0 open — 1 closed)

Bug #44481: Check for new content element button uses old query objectClosedJigal van Hemert2013-01-13

Actions

Related issues 5 (0 open — 5 closed)

Related to TYPO3 Core - Bug #43430: Drag and Drop of content elements does not workClosed2012-11-29

Actions
Related to TYPO3 Core - Bug #32967: Backend workspace copy/cut paste column content fails on publishClosed2012-01-04

Actions
Related to TYPO3 Core - Bug #39983: Change colPos of content element in draft workspaceClosed2012-08-20

Actions
Related to TYPO3 Core - Bug #48939: Moving a content down moves it in another columnClosedNicole Cordes2013-06-07

Actions
Precedes TYPO3 Core - Bug #47529: Regression in 4.7.11rc1: Invalid argument supplied for foreach() in class.tx_cms_layout.php line 404Closed2013-04-24

Actions
Actions
Copy link
 #1

Updated by Gerrit Code Review about 12 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/17468

Actions
Copy link
 #2

Updated by Gerrit Code Review about 12 years ago

Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/17468

Actions
Copy link
 #3

Updated by Gerrit Code Review about 12 years ago

Patch set 1 for branch TYPO3_6-0 has been pushed to the review server.
It is available at https://review.typo3.org/17496

Actions
Copy link
 #4

Updated by Oliver Hader about 12 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions
Copy link
 #5

Updated by Gerrit Code Review about 12 years ago

  • Status changed from Resolved to Under Review

Patch set 1 for branch TYPO3_4-7 has been pushed to the review server.
It is available at https://review.typo3.org/17497

Actions
Copy link
 #6

Updated by Gerrit Code Review about 12 years ago

Patch set 1 for branch TYPO3_4-5 has been pushed to the review server.
It is available at https://review.typo3.org/17637

Actions
Copy link
 #7

Updated by Gerrit Code Review about 12 years ago

Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at https://review.typo3.org/17638

Actions
Copy link
 #8

Updated by Jigal van Hemert almost 12 years ago

  • Status changed from Under Review to Resolved
Actions
Copy link
 #9

Updated by Oliver Hader almost 12 years ago

Patch for TYPO3_4-6 has been dropped due to EOL

Actions
Copy link
 #10

Updated by Thorsten Kahler over 11 years ago

  • Is Regression set to No

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.

Actions
Copy link
 #11

Updated by Jigal van Hemert over 11 years ago

@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.

Actions
Copy link
 #12

Updated by Thorsten Kahler about 11 years ago

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.

Actions
Copy link
 #13

Updated by Riccardo De Contardi over 7 years ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF