Bug #21161
openProblem with moved translated content elements (wrong column)
0%
Description
There is a problem if you´ve got an website with 2 or more columns and more than one language. If you shift a content element (the default lang) from one column to an other, only the default language gets the new column attribute, the translated elements holds the old column. In the frontend it doesn´t matters because only the column attribute from the default language counts (that means in FE it looks good even though in BE it is wrong).
(issue imported from #M15413)
Updated by Alexander Opitz over 11 years ago
- Status changed from New to Needs Feedback
- Target version deleted (
0)
The issue is very old, does this issue exists in newer versions of TYPO3 CMS (4.5 or 6.1)?
Updated by Alexander Opitz about 11 years ago
- Status changed from Needs Feedback to Closed
- Is Regression set to No
No feedback for over 90 days.
Updated by Gleb Levitin over 10 years ago
yes, the issue exists in TYPO3 CMS 4.5 as well.
Updated by Thorsten Kahler over 10 years ago
- Category set to Localization
- Status changed from Closed to New
- TYPO3 Version changed from 4.4 to 4.5
- PHP Version changed from 4.3 to 5.3
Reopened after feedback and quick check with TYPO3 4.5.34 on Ubuntu 12.04
Updated by Riccardo De Contardi over 9 years ago
It seems still present in 6.2.14 and 7(latest master); I just performed a test with both and I report my findings:
1) I have 2 languages, italian (L=0) and english (L=1)
2) my TS setup:
config.linkVars = L config.uniqueLinkVars = 1 config.sys_language_overlay = content_fallback config.language = it config.locale_all = it_IT config.htmlTag_langKey = it-IT config.sys_language_uid = 0 [globalVar = GP:L = 1] config.language = en config.locale_all = en_EN config.htmlTag_langKey = en-EN config.sys_language_uid = 1 [global] page=PAGE page.10 < styles.content.get page.20=TEXT page.20.value=SIDE COL page.20.wrap=<h2>|</h2><hr> page.30 < styles.content.getLeft
3) I also made a BE layout record, assigned to every page:
backend_layout { colCount = 2 rowCount = 1 rows { 1 { columns { 1 { name = Main content colPos = 0 } 2 { name = Side Content colPos = 1 } } } } }
4) I created a CE (text) in italian in Main Content (colPos=0), and then I translated it into english
5) After that, I drag and drop it to Side Content (colPos=1)
Results:
1) in BE, the colPos of the translated CE is still 0 and not 1 (but I don't think it is fully wrong, I mean, colPos is "translatable" as the other fields, and when I create a new translation of a CE, this is hidden by default, so there's time to adjust the colPos to the correct value
2) in FE, the translated element is in fact placed as it were belonging to the side column and not main column....so it is true that styles.content.get
and styles.content.getLeft
consider only the colPos of the main language, and this could be confusing.
Updated by Jo Hasenau almost 9 years ago
- Status changed from New to Accepted
- Assignee set to Jo Hasenau
- Priority changed from Should have to Must have
- Target version set to next-patchlevel
It seems that moving translated elements to other columns is only broken, when the elements in the target column don't have translations yet or if these columns are completely empty.
Moving elements to the first position of a column does not move translations as well - so the conclusion is:
The actual problem is to move translations to the first position of their column.
Updated by Daniel Alder over 8 years ago
I can confirm that this issue is not solved in 7 LTS.
Dragging content elements into another column will not move their related translations. Issue pops up in several situations. Moving CE between columns in be_layouts. Dragging CEs into gridelements or try the same in fluidcontent elements.
As Jo already mentioned it appears only if the destination is an empty colum. That's causing the javascript setting a page id instead the previous content element id. IDs of content elements will be negative, page IDs positive.
Description in core:
Position to move to: $destPid: >=0 then it points to a page-id on which to insert the record (as the first element). <0 then it points to a uid from its own table after which to insert it
In the ajax request the colPos for the element itself will be set already in the "process_datamap"-function (\TYPO3\CMS\Core\DataHandling\DataHandler).
After that, the function "process_cmdmap" get executed. Since we are moving an element the function "moveRecord" get called. That again will use "moveRecord_raw" to move the record definitely. Now all our translations will be moved as well.
As you can see, the colPos is not part of that process.
So after everything is done in "moveRecord_raw" the function "fixCopyAfterDuplFields" will be executed. This will update the translation with the correct colPos.
Simplified code passage:
<?php // After another CE: // $destPid = 3 (correct page id) // $origDestPid = -45 (previous content element) // Is first CE: // $destPid = 3 (correct page id) // $origDestPid = 3 (no previous element, so page id will be provided) // Insert as first element on page (where uid = $destPid) if ($destPid >= 0) { ... $this->databaseConnection->exec_UPDATEquery($table, 'uid=' . (int)$uid, $updateFields); // Check for the localizations of that element $this->moveL10nOverlayRecords($table, $uid, $destPid, $destPid); ... // fixCopyAfterDuplFields if ($origDestPid < 0) { $this->fixCopyAfterDuplFields($table, $uid, abs($origDestPid), 1); } ... } else { ... $this->databaseConnection->exec_UPDATEquery($table, 'uid=' . (int)$uid, $updateFields); // Check for the localizations of that element $this->moveL10nOverlayRecords($table, $uid, $destPid, $originalRecordDestinationPid); ... // fixCopyAfterDuplFields if ($origDestPid < 0) { $this->fixCopyAfterDuplFields($table, $uid, abs($origDestPid), 1); } ... }
As you can see in case of the first element the function "fixCopyAfterDuplFields" never gets executed since the $origDestPid is positive as we don't have a previous element.
Possible solution could be changing the condition to
if($origDestPid === $resolvedPid) { $this->fixCopyAfterDuplFields($table, $uid, abs($origDestPid), 1); }
But, the function "fixCopyAfterDuplFields" is meant to use a previous content element (which is not available if it is the first CE anyway). So this function would need some attention too.
Hopefully there is someone around with a bigger picture of the overall process (for example, why the dragged content element getting the correct colPos already in the "process_datamap" function?)
Updated by Daniel Alder over 8 years ago
Ok "fixCopyAfterDuplFields" as it is doesn't work in its current state. This will be used after copying any record. Fields are defined in $GLOBALS['TCA']['my_table']['ctrl']['copyAfterDuplFields'].
So if I would set the uid from the l18n parent as the "previous content element". Usually it overwrites colPos and sys_language_uid.
In our example, the fields will be copied from the l18n parent (instead of a real "previous CE"). ColPos will be correct at this point, but the sys_language_uid is wrong.
Updated by Daniel Alder about 8 years ago
Bump: Hopefully there is someone around with a bigger picture of the overall process (for example, why the dragged content element getting the correct colPos already in the "process_datamap" function)?
Updated by Kay Strobach almost 8 years ago
also valid in 7.6.13.
Question is how we can solve that ... as BE Layouts get more and more popular and such basic functionality is broken.
Updated by Oliver Hader almost 8 years ago
The main problem is to reference by the negative PID (which is actually the UID of the element to be inserted after). If this information is not given or cannot be resolved (e.g. there's just one content element), it's not possible to update to positions.
Thus, the only way to solve this, is to get rid of the negative PID reference behavior in this scenario and submit valid valid imperatives (colPos, sorting, etc.).
Updated by Kay Strobach almost 8 years ago
atleast in the html we have data-colpos set in the html attributes, so this should be solveable ...
Updated by Daniel Alder over 7 years ago
This issue still appears in 8.7.0-dev.
Already an idea or intention to fix that?
Updated by Markus Goldbach over 7 years ago
- Related to Bug #81753: Content element translations dissapear in page module after move to another column added
Updated by Benni Mack over 5 years ago
- Target version changed from next-patchlevel to Candidate for patchlevel
Updated by Stefan Froemken over 3 years ago
One of our customers has the same problem in TYPO3 9 and I can reproduce that issue on TYPO3 10.4, too.
It's not a perfect solution, but I have added a solution as option in Extension Settings of jwtools2 to add a hook into DataHandler which will add the missing DB queries to translated records:
https://extensions.typo3.org/extension/jwtools2
Activate option: typo3ApplyFixForMoveTranslatedContentElements
But I don't found a nice and cool solution in JavaScript to move the translated records directly in one move. So currently you have to reload the right frame on your own to see the changed position of the translated records.
If there is someone with more knowledge to Backend JS feel free to adapt the code and write a patch for TYPO3. I have gived up after 4 hours...
Stefan
Updated by Stefan Froemken over 3 years ago
- Related to Bug #95069: Add eventDict to DragDrop JS lib added
Updated by leon jänicke over 1 year ago
- Related to Epic #101557: Translation Handling Findings added