Bug #39798
Language changes on re-ordering of Content Elements
| Status: | Accepted | Start date: | 2012-08-14 | |
|---|---|---|---|---|
| Priority: | Must have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | Backend API | Spent time: | - | |
| Target version: | 7.4 (Backend) | |||
| TYPO3 Version: | 6.0 | Is Regression: | No | |
| PHP Version: | Sprint Focus: | |||
| Complexity: | hard |
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:¶
- go to the list module (extended view + localization view active)
- create a page
- add a content element, name it "foo" and assign it the language "all languages"
- 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
History
#1 Updated by Steffen Gebert almost 3 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 3 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 2 years ago
- Status changed from Needs Feedback to New
#4 Updated by Markus Klein over 2 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 2 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 1 year 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 1 year 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 6 months ago
- Target version changed from next-patchlevel to 7.4 (Backend)