Bug #81314
closed
doubled references upon related record change
100%
Description
Situation:
A pages record has been extended with some fields, each holds a file_reference_record. The TCA is standard with a maxitems = 1.
Additionally, the record holds a n:1 relation to another custom table record.
Meaning, the custom table record has many children, that are pages records. But each pages record can only hold relation to one custom table record.
Those pages records might or might not be translated.
The custom table record is not translated.
How to reproduce:
the child record (custom table) gets edited in BE.
Upon saving, the following exception is shown:
#1486233164: Child record was not processed, reason "[1.0.-1]: [newlog()] Attempt to localize record without permission".
Problem:
After the exception has been shown and the first record (pages) is opened again for editing, all references have been doubled, causing validation errors for the record.
TCA for the relation of custom table -> pages:
'pages' => [
'exclude' => 0,
'label' => label',
'config' => [
'type' => 'inline',
'foreign_table' => 'pages',
'foreign_field' => 'partner',
'appearance' => [
'collapseAll' => true,
'expandSingle' => false,
'enabledControls' => [
'sort' => false,
'new' => false,
'delete' => false,
'info' => false
]
],
],
],
Files
Updated by Joe Jones over 6 years ago
- File [TYPO3 CMS 8.7.8].html [TYPO3 CMS 8.7.8].html added
Hallo,
I have a problem that comes with the same error code:
I extended the TCA with
$GLOBALS['TCA']['pages_language_overlay']['columns']['media']['config']['behaviour']['allowLanguageSynchronization'] = 1;
in pages_language_overlay.php
Then a additional TCA-field appears in the media-ressource tab at the translation-page-setting of the specific language of a page: Translation behavior: Custom value Value of default language
I have another working installation, so I am sure, that the TCA-Extension works fine. But in this installation, an error appears on saving any changes in the page properties: Uncaught TYPO3 Exception #1486233164: Child record was not processed (More information) (full error output attached).
As Anja descriped, the media resources doubles, if I try saving the all-over-page-setting (not only the translation page setting). It only happens on pages with subpages.
Would be great if that problem could be solved.
Regards
Martin
Updated by Oliver Hader over 6 years ago
- Related to Bug #83009: Avoid invalid references in DataMapProcessor added
Updated by Oliver Hader about 6 years ago
- Status changed from New to Needs Feedback
Does this error still exist after #83009 has been resolved?
Updated by Joe Jones about 6 years ago
Oliver Hader wrote:
Does this error still exist after #83009 has been resolved?
Hi Oliver,
the problem does not exist anymore. Unfortunately I can't remember the point, when it has vanished. Maybe I did some tries and found a workaround, maybe I updated the instance. From my side it s resolved.
Thank you for your demand
Martin
Updated by Anja Leichsenring almost 6 years ago
- Status changed from Needs Feedback to Resolved
Updated by Christoph Volkamer almost 6 years ago
Hi there,
I stumbled again over this annoying bug, when using 8.7.15. I just updated from 8.7.10 and I'm pretty shure, that the bug was fixed. It's exactly the same as described before, depending on activation of "allowLanguageSynchronization" for media.
Thanks in advance for checking this again,
Chris
Updated by Alexander Opitz almost 6 years ago
- Status changed from Resolved to New
- Assignee set to Oliver Hader
Updated by Oliver Hader almost 6 years ago
Hi thanks for the report. Can you please provide the complete TCA configuration of all involved tables. Without having that information it's more like guessing the scenario. Having the specific configuration at hand makes it easier to reproduce the issue. Thanks in advance
Updated by Oliver Hader almost 6 years ago
- Status changed from New to Needs Feedback
Updated by Oliver Hader almost 6 years ago
I was not able to reproduce the issue mentioned in note 1 on a plain TYPO3 core 8.7.15.
@christoph -: Can you please give a step by step example on how to reproduce the behavior? Are there any other additonal extensions installed in your scenario that probably modify pages or pages_language_overlay?
Updated by Oliver Hader over 5 years ago
- Related to Bug #85914: Errors in L10nModeUpdater with "l10n_mode = exclude" in pages_language_overlay added
Updated by Xavier Perseguers over 5 years ago
Facing this problem with EXT:news records. Looks My scenario is as follows:
- News containing image relations (FAL) with translations in 3-4 languages
- When editing the base record and saving, I get doubled references and an error message "Child record was not processed"
- Those faulty news date back from TYPO3 v7
I can reproduce this problem with existing news. When I try to reproduce with new records created in TYPO3 v8, the problem does not seem to occur.
Updated by D. Kassor over 5 years ago
Xavier Perseguers wrote:
Facing this problem with EXT:news records. Looks My scenario is as follows:
- News containing image relations (FAL) with translations in 3-4 languages
- When editing the base record and saving, I get doubled references and an error message "Child record was not processed"
- Those faulty news date back from TYPO3 v7
I can reproduce this problem with existing news. When I try to reproduce with new records created in TYPO3 v8, the problem does not seem to occur.
I got this error message "Child record was not processed" also in combination with EXT:news (7.0.5) and TYPO3 8.7.19. After saving changes in default language news record with three translations.
Updated by Stephan Schuler over 5 years ago
- File data-map-processor-loop-detection-language-fragment.patch data-map-processor-loop-detection-language-fragment.patch added
Hey there.
Let me step in here. I face the very same issue currently. I'm upgrading from TYPO3 6.2 to 8.7 currently. So there's a lot of data in the database dating back to this ancient version schema.
After having read the initial post once again it sounds kind of different, but I' still sure the situation is related and dates back to DataHandler loop detection not considering the language value of a "localize" call.
- A page is translated in at least two foreign languages, say L=1 and L=2.
- I have a tt_content (1) with sys_language_uid:0
- I have a related tt_content (2) as a translation to sys_language_uid:1 pointing l18n_parent and l10n_source to tt_content (1)
- I have another related tt_content (3) as a translation to sys_language_uid:2 pointing l18n_parent and l10n_source to tt_content (2)
- There is a sys_file_reference (4) with sys_language_uid:0 connecting tt_content (1) wit a file.
- And there is another sys_file_reference (5) with sys_language_uid:0 connecting tt_content (1) with another file.
Now I save the tt_content (1) via backend. The very same happens when running the DatabaseRowsUpdateWizard and tt_content (1) is the first tt_content (of those mentioned) being processed.
- The DataHandler tries to translate the sys_file_reference (4) and sys_file_reference (5) into both, sys_language_uid:1 and sys_language_uid:2, hence creating 4 new sys_file_reference records.
- The first run creates for sys_file_reference (4) and sys_file_reference (5) a translation to sys_language_uid:1 each and registers "sys_file_reference:4:localize" and "sys_file_reference:5:localize" through DataHandler::registerNestedElementCall().
Here the language is not taken into account, so the DataHandler assumes both sys_file_references are already localized. - The second run tries to create for both, sys_file_reference (4) and sys_file_referenced (5), a translation to sys_language_uid:2.
DataHandler::localize()returns false because both sys_file_references are registered as already localized.
I guess the cache identifiers of actions already taken should contain not only $tablename:$recorduid:localize but $tablename:$recorduid:localize$language.
See patch file attached.
Regards,
Stephan.
Updated by Michael Stucki almost 5 years ago
I can confirm this problem with TYPO3 8.7.25. The bug occurs while running the update wizard "Execute database migrations on single rows":
#1486233164: Child record was not processed
I investigated this problem today and came to the same conclusion as Stephan: The cache identifier for DataHandler::registerNestedElementCall() needs to include the language id, otherwise a huge portion of code is skipped, which leads to the mentioned error.
In my case, the problem was triggered during the upgrade from TYPO3 7.6 to 8.7. I'm upgrading from the commandline using "typo3cms upgrade:all". I didn't try to reproduce it with 9.5, but the code is the same, so I expect that the same problem exists there, too...
Updated by Gerrit Code Review almost 5 years ago
- Status changed from Needs Feedback to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60722
Updated by Michael Stucki almost 5 years ago
- Has duplicate Bug #85168: Language synchronization fails for inline relations within inline relations added
Updated by Gerrit Code Review almost 5 years ago
Patch set 1 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60723
Updated by Gerrit Code Review almost 5 years ago
Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60724
Updated by Gerrit Code Review over 4 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60722
Updated by Gerrit Code Review over 4 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/60722
Updated by Michael Stucki about 4 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset a0b9ca1ec0a3860aa0dfc318f3ca8e6d14b9593b.
Updated by Michael Stucki about 4 years ago
Great to see that this is now fixed in TYPO3 8 / 9 / 10! Many thanks to all who helped to solve this. Special thanks to Benni for finishing this fix!
Updated by