Bug #14408

lang-children "get lost"(should be deleted) when deleting parent-record in default language

Added by Francois Suter almost 15 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Should have
Category:
Backend API
Target version:
-
Start date:
2004-11-24
Due date:
% Done:

0%

TYPO3 Version:
4.3
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Sometimes, when I am in List view, not all elements appear in the list. This behaviour seems restricted to page content elements.

I have included an example as screenshots. I have a sysFolder with uid=45. If I search the tt_content table for items with pid=45, I find 14 records (see mysql.png screenshot). In the list view, I have only 6 (see list.png screenshot). This is a real problem because I can't edit those elements that don't apear (of course).

It also checks with the TV Page view. More elements appear when choosing the "non-used elements" tab than (see page.png screenshot) in the List view (see list2.png screenshot).

MySQL 4.0.18
PHP 4.3.6
Apache 1.3.27
Mac OS X Server 10.3.5

Screenshots in attached ZIP file
(issue imported from #M539)

0000539-screenshots.zip (35.6 KB) Administrator Admin, 2004-11-24 10:23

0000539-screenshots2.zip (9.85 KB) Administrator Admin, 2004-11-26 15:32

0000539-updated_screenshot.png View (12 KB) Administrator Admin, 2004-12-01 13:29

0000539-mysql.pdf (45.2 KB) Administrator Admin, 2004-12-01 13:29

0000539-list4_uid.png View (5.65 KB) Administrator Admin, 2004-12-22 14:57

0000539-mysql2.png View (23.9 KB) Administrator Admin, 2004-12-22 14:57

0000539-deleteL10nOverlays.patch View (5.34 KB) Administrator Admin, 2009-10-19 15:44

0000539-deleteL10nOverlays_v2.patch View (10.7 KB) Administrator Admin, 2009-10-20 13:39


Related issues

Related to TYPO3 Core - Bug #19014: Copying Content Elements does not copy Language Overlays Closed 2008-06-25
Related to TYPO3 Core - Bug #15452: When moving records the translation do not move with it Closed 2006-01-19
Duplicated by TYPO3 Core - Bug #19461: translation do not follow parent when cut'n'paste Closed 2008-10-15
Duplicated by TYPO3 Core - Bug #17724: linked records not updated when deleting the original Closed 2007-10-26
Duplicated by TYPO3 Core - Bug #16847: Deleting localized content elements fails Closed 2007-01-10

History

#1 Updated by Francois Suter almost 15 years ago

I now have an example of a similar problem, but reversed (see the files in screenshots2.zip).

I have created an Alternative Page Language for a page. I cannot select it in Page view, but I can see it in List view...

#2 Updated by Wolfgang Klinger almost 15 years ago

.. and you haven't deleted any records? You'll find them in the database (with deleted = 1) but not in any view... (just a thought)

#3 Updated by Francois Suter almost 15 years ago

Indeed some elements are destroyed, but unfortunately that doesn't explain everything. I will now upload an updated screeshot (the web site has changed between) and the full output of the SQL query on tt_content for pid=45.

Just as an example, tt_content with uid=42 (and titled "(copy 1)") is not deleted and doesn't appear in the list.

#4 Updated by Peter Niederlag almost 15 years ago

like said. deleted=1 => never shows in list or page Module as well as all(?) core modules.
I think it can be closed.

#5 Updated by Francois Suter almost 15 years ago

Indeed deleted elements never show up, but the problem is not as simple here. Juggler, you may not have looked closely at all the exemples I attached with the bug. Would you please reconsider?

As for the part with the Alternative Page Language not showing up, I will open a separate bug.

#6 Updated by Peter Niederlag almost 15 years ago

I'm sorry. :-< (miscount 7 <=> 9)

Could you please
1) provide screenshot of sql-select instead of PDF and have it include 'i18n_parent' and 'sys_language_uid' fields?
2) open single-table view of list-module an let it include [uid] field?

Thx,
Peter

(maybe sys_language_uids have been changed in between?)

#7 Updated by Francois Suter almost 15 years ago

l18n_parent is the answer. I am attaching the screenshots you requested, but I checked them first and all the "phantom" elements I was mentioning have a common characteristic: they are translated elements whose language parent was deleted.

So this is the problem: when a content element is deleted, its l18n children have their l18n_parent field set to 0. The bug is then that they don't appear in list view, but appear in the "Non-used elements" tab in the Web > (TV) Page module. I still contend that this is a bug, although maybe not as severe as I indicated. "Translation children" should be marked as deleted when their parent is. I think it makes no sense to have "free-floating" translations.

#8 Updated by Peter Niederlag almost 15 years ago

Glad we tracked it down. I changed summary/title of the bug.
No solution yet though

#9 Updated by Francois Suter almost 11 years ago

Taking the opportunity of a Bug Day to go back to that bug. The behaviour of TYPO3 hasn't changed 4 years down the line:

- when deleting a record, translations of that record don't get deleted too, which doesn't make sense.

Actually the same problem occurs when copying/moving: when copying or moving a record, the translation children are not carried around (only the pid of the parent record is changed). Whether this behaviour is desirable when copying is debatable. However when moving it would be quite obvious for the translation records to follow the original.

This would probably require quite some work in TCEmain...

#10 Updated by Uschi Renziehausen almost 11 years ago

Aaaah, finally I problem I have with one content element (used for testing multilanguage features) has a name!

About what should happen localized versions in my eyes:
In general, localized versions should be copied/moved with their parent, but what if the target page does not exist in all of the languages?

Uschi

#11 Updated by Francois Suter almost 11 years ago

Good point. I would say they should be copied along. They will not appear while the page translation still does not exist and will pop into existence once it does. This may seem odd at times, but I think there's some consistency to that behaviour.

#12 Updated by Francois Suter almost 11 years ago

Upated the TYPO3 version to 4.2.2 since the bug is still alive.

#13 Updated by Luc Muller almost 11 years ago

Could you please consider this bug ?

#0009566

because the problem not only occurs with deleted stuff but also when copy/pasting on other pages.

Thus means, if we act on a default language content. then the same action should be done on all the localised element.

this seems strange beacause I think it's kind of huge bug in localisation handling.

#14 Updated by Peter Kuehn over 10 years ago

basically the problem seems to start in tcemain line 2663 function copyRecord():

t3lib_BEfunc::getRecordWSOL($table,$uid) is called to fetch the record to be copied.
It seems like theres nothing (even planed, not just not working) to take possible translations into account from there down to line 2727 where tcemain is instanciated again to store the copy.

A possible solution might be to extend remapListedDBRecords() with a check if records stored in $this->copyMappingArray had a translation and to act accordingly.

#15 Updated by Tobias Pierschel about 10 years ago

Is there a solution in sight? We got the same strange issue in a clients project.
Thanks

#16 Updated by Tolleiv Nietsch about 10 years ago

I've just sent a patch to the dev-list (it resolved a couple of related issues as well) - I'd be glad to get some feedback

#17 Updated by Tolleiv Nietsch almost 10 years ago

attached patch is required by #15452 and #15452 - togehter they resolve copy, move and delete of records with l10n-overlays...

#18 Updated by Rupert Germann almost 10 years ago

FYI: commited to trunk rev 6192

Also available in: Atom PDF