Bug #21161

Problem with moved translated content elements (wrong column)

Added by Axel Kloss almost 9 years ago. Updated 2 months ago.

Status:
Accepted
Priority:
Must have
Assignee:
Category:
Localization
Start date:
2010-08-10
Due date:
% Done:

0%

TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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)


Related issues

Related to TYPO3 Core - Task #66540: Avoid having content jump up and down when dragging elements Closed 2015-04-22
Related to TYPO3 Core - Bug #72547: Moving orig tt_content records does not move translated records Closed 2016-01-06
Related to TYPO3 Core - Bug #81753: Content element translations dissapear in page module after move to another column New 2017-06-30

History

#1 Updated by Alexander Opitz about 6 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)?

#2 Updated by Alexander Opitz almost 6 years ago

  • Status changed from Needs Feedback to Closed
  • Is Regression set to No

No feedback for over 90 days.

#3 Updated by Gleb Levitin almost 5 years ago

yes, the issue exists in TYPO3 CMS 4.5 as well.

#4 Updated by Thorsten Kahler almost 5 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

#5 Updated by Riccardo De Contardi almost 4 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.

#6 Updated by Jo Hasenau over 3 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.

#7 Updated by Daniel Alder almost 3 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?)

#8 Updated by Daniel Alder almost 3 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.

#9 Updated by Daniel Alder almost 3 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)?

#10 Updated by Oliver Hader over 2 years ago

Confirmed in master (8.5-dev)

#11 Updated by Kay Strobach over 2 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.

#12 Updated by Oliver Hader over 2 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.).

#13 Updated by Kay Strobach over 2 years ago

atleast in the html we have data-colpos set in the html attributes, so this should be solveable ...

#14 Updated by Daniel Alder about 2 years ago

This issue still appears in 8.7.0-dev.
Already an idea or intention to fix that?

#15 Updated by Markus Goldbach almost 2 years ago

  • Related to Bug #81753: Content element translations dissapear in page module after move to another column added

#16 Updated by Benni Mack 2 months ago

  • Target version changed from next-patchlevel to Candidate for patchlevel

Also available in: Atom PDF