Bug #80080
closedIRRE and allowLanguageSynchronization
0%
Description
I have the following TCA field definition:
'product_variants' => [ 'exclude' => TRUE, 'l10n_mode' => 'exclude', 'label' => 'LLL:EXT:product/Resources/Private/Language/locallang_db.xlf:tx_product_domain_model_product.product_variants', 'config' => [ 'type' => 'inline', 'foreign_table' => 'tx_product_domain_model_productvariant', 'foreign_field' => 'product', 'foreign_sortby' => 'sorting', 'maxitems' => 9999, 'minitems' => 1, 'appearance' => [ 'collapseAll' => 1, 'levelLinksPosition' => 'both', 'showSynchronizationLink' => 1, 'showPossibleLocalizationRecords' => 1, 'useSortable' => 1, 'showAllLocalizationLink' => 1 ], 'behaviour' => [ 'allowLanguageSynchronization' => TRUE, ], ], ],
If I copy a default language product, which is already localized, the copied product localization has an additional product variant, which should not be there (the original one get´s copied and another one is created by the synchronization feature, I think).
May this new feature even be used with IRRE?
TYPO3 Version is 8.6.1
Updated by Oliver Hader almost 8 years ago
- Status changed from New to Needs Feedback
- Assignee set to Oliver Hader
Hi Kai, I don't really know your whole domain model - is product_variants creating a symmetric relation to the same table or are products stored in a different table than tx_product_domain_model_productvariant? And more important, what is the localization state of the product_variants field - is it "custom" or "parent"?
Did I understand it correctly, that the duplication localization of the product record contains one (expected) product variant and an additional (unexpected) product variant?
Please try to reproduce the behavior with the current version of the Git master branch to benefit from recent core changes in general - TYPO3 8.6.1 only contains security fixes and not all current bugfixes. Thanks
Updated by Kai Tallafus almost 8 years ago
Hi Oliver,
sorry for the late answer!
Product variants are stored in a different table than the product itself. Regarding the locazation state - it's the default state, because the field is hidden in the localization (l10n_mode=exclude). Or do you mean something different?
Did I understand it correctly, that the duplication localization of the product record contains one (expected) product variant and an additional (unexpected) product variant?
this is correct, yes
I just tried the dev-master version today, but the behaviour is still the same.
Updated by Kai Tallafus almost 8 years ago
Hi!
I tested this again with 8 LTS.
The duplication problem seems to be fixed, but I noticed some other things:
with l10n_mode=exclude:- if I update a field value of a product variant in default language, the translation is not updated until I open the localized product record and save it (is this intended??)
- the synchronized product variant records have sys_language_uid=0 and l10n_parent=0, which is kinda odd (again - is this intended?)
- the synchronization does not work - changes in default language are not synchronized
Updated by Kai Tallafus almost 8 years ago
I did another test with
'behaviour' => [
'localizeChildrenAtParentLocalization' => TRUE,
],
Here, the resulting localized product variant has sys_language_uid and l10n_parent fields set correctly.
Updated by Riccardo De Contardi almost 8 years ago
- Assignee deleted (
Oliver Hader)
Hi Kai, after your findings, do you think that this issue could be considered resolved, or is there still something left to do?
Thank you very much for your answer!
Updated by Kai Tallafus almost 8 years ago
Hi Riccardo,
no, the issue is NOT resolved.
localizeChildrenAtParentLocalization is no solution for the problem, it was just a comparison how it should behave IMO.
There is currently no way to keep the locatizations for inline-records in sync. The new synchronization feature does not work as described above, the synchronize buttons do not work (as discribed here: https://forge.typo3.org/issues/80855), and maintaining each language separate using the "Add new"-Buttons of the IRRE field does not work either, because of this bug: https://forge.typo3.org/issues/57272 (which seems to be related to IRRE in general, not only FAL).
Do you need more info to fix this issue? We´re stuck in the middle of a project and we need at least one of these issues being fixed...
Updated by Riccardo De Contardi almost 8 years ago
- Status changed from Needs Feedback to New
Updated by Oliver Hader about 6 years ago
The issue with l10n_parent
and sys_language_uid
is addressed in issue #87640 - probably that fixes the mentioned side effects as well (since synchronization can resolve default language siblings again). This applies only when having l10n_mode=exclude
defined in TCA.
Updated by Oliver Hader about 6 years ago
- Status changed from New to Needs Feedback
Updated by Oliver Hader about 6 years ago
- Related to Bug #87640: Keep language reference for associated l10n_mode=exclude children added
Updated by Susanne Moog almost 5 years ago
- Status changed from Needs Feedback to Closed
No feedback and no new reports of the issue since a year. Closing now. If this pops up again, please re-open.