Project

General

Profile

Actions

Bug #82946

open

Categories get lost when translating content elements created in a draft workspace

Added by Till Kleisli over 6 years ago. Updated 11 days ago.

Status:
Needs Feedback
Priority:
Must have
Assignee:
-
Category:
Workspaces
Target version:
-
Start date:
2017-11-07
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
8
PHP Version:
7.0
Tags:
workspaces localization
Complexity:
Is Regression:
Sprint Focus:

Description

1. Create a content element in a draft workspace with some categories assigned.

This will result in
  1. PLACEHOLDER-Element with uid 42 (for example)
    • t3ver_label: INITIAL PLACEHOLDER
    • t3ver_oid: 0
    • t3ver_wsid: 1 (Workspace-Id)
    • t3ver_state: 1
    • t3origuid: 0
    • sys_language_uid: 0
    • No categories assigned
  2. Draft element with uid 43
    • pid: -1
    • t3ver_oid: 42
    • t3ver_label: First draft version
    • t3ver_wsid: 1 (Workspace-Id)
    • t3ver_state: -1
    • Entries in table sys_category_record_mm are made with uid 43

2. Make a translation of this element

You get
  1. New translated placeholder
    • uid: 44
    • t3ver_label: INITIAL PLACEHOLDER
    • t3ver_oid: 0
    • t3ver_wsid: 1
    • t3ver_state: 1
    • t3origuid: 42
    • sys_language_uid: 1
    • No categories assigned
  2. new translated draft
    • uid: 45
    • pid: -1
    • t3ver_oid: 44
    • tever_label: First draft version
    • t3ver_wsid: 1 (Workspace-Id)
    • t3ver_state: -1
    • t3origuid: 42
    • sys_language_uid: 1
    • No categories assigned

3. Problem

The translated elements do not have the categories assigned.
The reason is, the translations are always made from the Placeholder record (uid 42) which has no categories assigned. The categories only get assigned to the placeholder record, when the element is published to the LIVE workspace.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #81585: Update categories are not visible in Web > ListClosed2017-06-15

Actions
Actions #1

Updated by Till Kleisli over 6 years ago

  • Related to Bug #81585: Update categories are not visible in Web > List added
Actions #2

Updated by Till Kleisli over 6 years ago

I think the solution with the least necessary changes would be:
  • IF (creating a element with sys_language_uid > 0 and t3ver_wsid > 0)
    • look for rows in the same table with t3ver_oid = {t3origuid of the new draft element
    • IF (there are entries in sys_category_record_mm with foreign_uid = {uid of the row we found})
      • duplicate these entries with foreign_uid SET to {uid of the new draft element}

I would provie a patch, when someone can tell me, where I have to look for the code that is creating the localized elements.

Actions #3

Updated by Susanne Moog over 6 years ago

  • Sprint Focus set to On Location Sprint
Actions #4

Updated by Mathias Brodala about 6 years ago

  • Sprint Focus deleted (On Location Sprint)
Actions #5

Updated by Riccardo De Contardi over 3 years ago

are these somehow related?

#77917

#82086

#89231

Actions #6

Updated by Riccardo De Contardi 11 days ago

  • Status changed from New to Needs Feedback

IS this still true? I tried to reproduce it with 11.5.35, 12.4.14 and 13.1.0-dev (latest main) with the following test

Prerequisites

  • TYPO3 installation with two languages (default id=0 e.g. Italian and another id=1 e.g. Englisgh)
  • a Draft workspace
  • some categories

Test procedure

  1. on LIVE workspace create a page "test" and translate it to the 2nd language
  2. switch to "Draft" workspace (important)
  3. create a content element, e.g "header only" and assign to it some categories; save it and close
  4. Translate the CE into the 2nd language
  5. edit it

Result

Both using the "connected" and "free" translation mode, when you edit the 2nd element, the same categories you selected are applied

Do you think that this test is sufficient? Or a different one is necessary?

Actions

Also available in: Atom PDF