Bug #39798

Story #82206: list module enhancements/bugfixes

Language and colpos changes on re-ordering of Content Elements

Added by Mario Rimann almost 7 years ago. Updated over 1 year ago.

Status:
Accepted
Priority:
Must have
Assignee:
-
Category:
DataHandler aka TCEmain
Start date:
2012-08-14
Due date:
% Done:

0%

TYPO3 Version:
6.0
PHP Version:
Tags:
Complexity:
medium
Is Regression:
No
Sprint Focus:

Description

If content elements on a page are moved up and down in the order, they get the sys_language_uid assigned of the record that they jumped over.

Steps to reproduce:

  1. go to the list module (extended view + localization view active)
  2. create a page
  3. add a content element, name it "foo" and assign it the language "all languages"
  4. add a second content element, name it "bar" and leave it on language "default"

The list now looks like this:

- foo - all languages
- bar - default

Now click the arrow down, to move "foo" down after "bar". Expected result is that only the order changes. But now, the order changes AND the language "default" will also be set for "bar", resulting in the following list:

- foo - default
- bar - default

Notes:

  • Disabling the Localization View has no effect -> bug is reproducable independent of that checkbox
  • Same mistake happens in the Page Module

Related issues

Related to TYPO3 Core - Bug #48673: Changed language overlay behaviour in TYPO3 6.* Closed 2013-05-30
Related to TYPO3 Core - Bug #39054: Copied Content Elements incorrectly inherit language Accepted 2012-07-18
Related to TYPO3 Core - Bug #14873: CE jumps from right to normal when moved in list mode Accepted 2005-07-21
Related to TYPO3 Core - Bug #72988: losing Localization when moving elements (Typo 7.6.2) New 2016-01-28

History

#1 Updated by Steffen Gebert almost 7 years ago

  • Status changed from New to Needs Feedback

Thanks for the report, Mario. Can you reproduce this with older TYPO3 versions?

#2 Updated by Mario Rimann almost 7 years ago

Steffen Gebert wrote:

Can you reproduce this with older TYPO3 versions?

I did not explicitely test it today in older versions, but my colleague who found this issue in a customer project is working in a 4.5.x environment - so I'm pretty sure it's also reproducable in 4.5.x and up to master (tested with a 6.0-dev today).

#3 Updated by Steffen Gebert over 6 years ago

  • Status changed from Needs Feedback to New

#4 Updated by Markus Klein over 6 years ago

Hi!

Can you please check whether there is a hook registered for:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['moveRecordClass']

You can use the Configuration module in the BE for checking that.
Thx.

#5 Updated by Mario Rimann over 6 years ago

Markus Klein wrote:

Can you please check whether there is a hook registered for:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['moveRecordClass']

On the installation where this was reported, the "multicolumn" extension is installed, which adds itself to exactly this hook. So I went to test it on another 4.5.x based setup, where multicolumn is not installed. So the only thing that is hooked into the mentioned hook (in both installations) is:

EXT:cms/tslib/hooks/class.tx_cms_treelistcacheupdate.php:&tx_cms_treelistCacheUpdate

The issue is reproducable also in this setup with only this hook in place.

#6 Updated by Mario Rimann over 5 years ago

I just tried to reproduce this as an editor user on a TYPO3 v6.1.5 installation -> error appears also in this situation.

#7 Updated by Markus Klein over 5 years ago

  • Category set to Backend API
  • Status changed from New to Accepted
  • Priority changed from Should have to Must have
  • Target version set to next-patchlevel
  • Complexity set to hard
  • Is Regression set to No

I can reproduce this on current master (6.2) too. Strangely this only happens when moving things "down"!

#8 Updated by Mathias Schreiber over 4 years ago

  • Target version changed from next-patchlevel to 7.4 (Backend)

#9 Updated by Susanne Moog almost 4 years ago

  • Target version changed from 7.4 (Backend) to 7.5

#10 Updated by Benni Mack almost 4 years ago

  • Target version changed from 7.5 to 7 LTS

#11 Updated by Mathias Schreiber over 3 years ago

  • Category changed from Backend API to DataHandler aka TCEmain
  • Target version deleted (7 LTS)

#12 Updated by Markus Klein over 2 years ago

  • Subject changed from Language changes on re-ordering of Content Elements to Language and colpos changes on re-ordering of Content Elements
  • Target version set to Candidate for patchlevel
  • Complexity changed from hard to medium

Can be reproduced in all versions independent of any third party extension.

The problem is that \TYPO3\CMS\Core\DataHandling\DataHandler::fixCopyAfterDuplFields() being called on a move command.
Specifically, when you have a CE list like that (list module):

- Title1 (colPos = 0)
- Title2 (colPos = 2)
- Title3 (colPos = 2)

If one clicks the up-button to move Title3 before Title2, the colPos AND sys_language_uid of Title3 is being set to zero.
=> Hence, it shows up below Title1, but in the wrong column

#13 Updated by Riccardo De Contardi over 1 year ago

  • Related to Bug #14873: CE jumps from right to normal when moved in list mode added

#14 Updated by Riccardo De Contardi over 1 year ago

  • Parent task set to #82206

#15 Updated by Riccardo De Contardi over 1 year ago

  • Related to Bug #72988: losing Localization when moving elements (Typo 7.6.2) added

Also available in: Atom PDF