lang-children "get lost"(should be deleted) when deleting parent-record in default language
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).
Mac OS X Server 10.3.5
Screenshots in attached ZIP file
(issue imported from #M539)
#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.
#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?
(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.
#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?
#13 Updated by Luc Muller almost 11 years ago
Could you please consider this bug ?
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.