http://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692013-05-09T11:18:49ZTYPO3 ForgeTYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=1643952013-05-09T11:18:49ZAlexander Opitzopitz.alexander@googlemail.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Needs Feedback</i></li><li><strong>Target version</strong> deleted (<del><i>0</i></del>)</li></ul><p>The issue is very old, does this issue exists in newer versions of TYPO3 CMS (4.5 or 6.1)?</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=1820962013-09-10T08:25:52ZAlexander Opitzopitz.alexander@googlemail.com
<ul><li><strong>Status</strong> changed from <i>Needs Feedback</i> to <i>Closed</i></li><li><strong>Is Regression</strong> set to <i>No</i></li></ul><p>No feedback for over 90 days.</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=2220032014-06-27T13:56:00ZGleb Levitingleb.levitin@dkd.de
<ul></ul><p>yes, the issue exists in TYPO3 CMS 4.5 as well.</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=2220142014-06-27T14:52:44ZThorsten Kahler
<ul><li><strong>Category</strong> set to <i>Localization</i></li><li><strong>Status</strong> changed from <i>Closed</i> to <i>New</i></li><li><strong>TYPO3 Version</strong> changed from <i>4.4</i> to <i>4.5</i></li><li><strong>PHP Version</strong> changed from <i>4.3</i> to <i>5.3</i></li></ul><p>Reopened after feedback and quick check with TYPO3 4.5.34 on Ubuntu 12.04</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=2663652015-07-16T12:46:47ZRiccardo De Contardierredeco@gmail.com
<ul></ul><p>It seems still present in 6.2.14 and 7(latest master); I just performed a test with both and I report my findings:</p>
<p>1) I have 2 languages, italian (L=0) and english (L=1)<br />2) my TS setup:</p>
<pre>
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
</pre><br />3) I also made a BE layout record, assigned to every page:<br /><pre>
backend_layout {
colCount = 2
rowCount = 1
rows {
1 {
columns {
1 {
name = Main content
colPos = 0
}
2 {
name = Side Content
colPos = 1
}
}
}
}
}
</pre><br />4) I created a CE (text) in italian in Main Content (colPos=0), and then I translated it into english<br />5) After that, I drag and drop it to Side Content (colPos=1)
<p>Results:<br />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</p>
<p>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 <code>styles.content.get</code> and <code>styles.content.getLeft</code> consider only the colPos of the main language, and this could be confusing.</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=2988762016-03-04T19:31:01ZJo Hasenauinfo@cybercraft.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Accepted</i></li><li><strong>Assignee</strong> set to <i>Jo Hasenau</i></li><li><strong>Priority</strong> changed from <i>Should have</i> to <i>Must have</i></li><li><strong>Target version</strong> set to <i>next-patchlevel</i></li></ul><p>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.<br />Moving elements to the first position of a column does not move translations as well - so the conclusion is:</p>
<p>The actual problem is to move translations to the first position of their column.</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3122182016-08-23T17:35:21ZDaniel Alderdalder@snowflake.ch
<ul></ul><p>I can confirm that this issue is not solved in 7 LTS.</p>
<p>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.</p>
<p>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.</p>
<p>Description in core:<br /><em>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</em></p>
<p>In the ajax request the colPos for the element itself will be set already in the "process_datamap"-function (\TYPO3\CMS\Core\DataHandling\DataHandler).</p>
<p>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.</p>
<p>As you can see, the colPos is not part of that process.<br />So after everything is done in "moveRecord_raw" the function "fixCopyAfterDuplFields" will be executed. This will update the translation with the correct colPos.</p>
<p>Simplified code passage:<br /><pre>
<?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);
}
...
}
</pre></p>
<p>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.</p>
<p>Possible solution could be changing the condition to</p>
<pre>
if($origDestPid === $resolvedPid) {
$this->fixCopyAfterDuplFields($table, $uid, abs($origDestPid), 1);
}
</pre>
<p>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.</p>
<p>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?)</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3122582016-08-24T09:16:44ZDaniel Alderdalder@snowflake.ch
<ul></ul><p>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'].</p>
<p>So if I would set the uid from the l18n parent as the "previous content element". Usually it overwrites colPos and sys_language_uid.<br />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.</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3141402016-09-20T16:24:18ZDaniel Alderdalder@snowflake.ch
<ul></ul><p>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)?</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3189402016-12-02T15:25:53ZOliver Haderoliver.hader@typo3.org
<ul></ul><p>Confirmed in master (8.5-dev)</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3196552016-12-14T12:16:43ZKay Strobach
<ul></ul><p>also valid in 7.6.13.</p>
<p>Question is how we can solve that ... as BE Layouts get more and more popular and such basic functionality is broken.</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3196562016-12-14T12:58:26ZOliver Haderoliver.hader@typo3.org
<ul></ul><p>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.</p>
<p>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.).</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3196572016-12-14T13:06:34ZKay Strobach
<ul></ul><p>atleast in the html we have data-colpos set in the html attributes, so this should be solveable ...</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3274442017-03-27T09:16:44ZDaniel Alderdalder@snowflake.ch
<ul></ul><p>This issue still appears in 8.7.0-dev.<br />Already an idea or intention to fix that?</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3360752017-06-30T13:20:46ZMarkus Goldbachmarkus.goldbach@gmail.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-1 priority-4 priority-default" href="/issues/81753">Bug #81753</a>: Content element translations dissapear in page module after move to another column</i> added</li></ul> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=3983572019-04-17T23:40:51ZBenni Mackbenni@typo3.org
<ul><li><strong>Target version</strong> changed from <i>next-patchlevel</i> to <i>Candidate for patchlevel</i></li></ul> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=4509972021-09-01T16:34:52ZStefan Froemkenfroemken@gmail.com
<ul></ul><p>One of our customers has the same problem in TYPO3 9 and I can reproduce that issue on TYPO3 10.4, too.<br />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:</p>
<p><a class="external" href="https://extensions.typo3.org/extension/jwtools2">https://extensions.typo3.org/extension/jwtools2</a></p>
<p>Activate option: typo3ApplyFixForMoveTranslatedContentElements</p>
<p>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.</p>
<p>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...</p>
<p>Stefan</p> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=4510022021-09-01T16:58:57ZStefan Froemkenfroemken@gmail.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-4 priority-default closed" href="/issues/95069">Bug #95069</a>: Add eventDict to DragDrop JS lib</i> added</li></ul> TYPO3 Core - Bug #21161: Problem with moved translated content elements (wrong column)http://forge.typo3.org/issues/21161?journal_id=4985392023-08-03T20:08:28Zleon jänicke
<ul><li><strong>Related to</strong> <i><a class="issue tracker-10 status-1 priority-7 priority-highest parent" href="/issues/101557">Epic #101557</a>: Translation Handling Findings</i> added</li></ul>