Bug #88784
closedRecord language is incorrectly changed to default language in overlayLanguageAndWorkspace
0%
Description
When a record with language uid !=0 is processed while the current language uid is 0 overlayLanguageAndWorkspace incorrectly "transforms" the record into the default language.
The relevant code is as far as I can tell this one:
if (isset($GLOBALS['TCA'][$tableName]['ctrl']['transOrigPointerField']) && $row[$GLOBALS['TCA'][$tableName]['ctrl']['transOrigPointerField']] > 0) {
//force overlay by faking default language record, as getRecordOverlay can only handle default language records
$row['uid'] = $row[$GLOBALS['TCA'][$tableName]['ctrl']['transOrigPointerField']];
$row[$GLOBALS['TCA'][$tableName]['ctrl']['languageField']] = 0;
}
A foreign language record is handled by overlayLanguageAndWorkspace so the condition passes. The language uid is set to 0 for this record, the record is then considered as main language. When it is next passed into getRecordOverlay it's not being dropped (as it should be in this case).
The above "fake" should only happen if $languageUid is not 0:
if (isset($GLOBALS['TCA'][$tableName]['ctrl']['transOrigPointerField']) && $row[$GLOBALS['TCA'][$tableName]['ctrl']['transOrigPointerField']] > 0 && $languageUid > 0) {
//force overlay by faking default language record, as getRecordOverlay can only handle default language records
$row['uid'] = $row[$GLOBALS['TCA'][$tableName]['ctrl']['transOrigPointerField']];
$row[$GLOBALS['TCA'][$tableName]['ctrl']['languageField']] = 0;
}
This issue becomes visible e.g. when relations are resolved as in tx_news: https://github.com/georgringer/news/issues/843#issuecomment-511815126
Files
Updated by David Bruchmann about 5 years ago
- File wdb_language_hook.zip added
Jonas,
I'm interested if your issue can be solved with the attached extension. would be nice if you could try it and give feedback.
Installation is done either by composer or by extensionmanager, afterwards nothing is to do, just clear cache and test it.
Updated by Jonas Schwabe about 5 years ago
It gives me a syntax error (the semicolon in typo3conf/ext/wdb_language_hook/Classes/Hooks/Frontend/Page/PageRepository.php line 131).
Updated by David Bruchmann about 5 years ago
Ohh I'm sorry, you can just remove the semikolon in that line.
Updated by David Bruchmann about 5 years ago
- File deleted (
wdb_language_hook.zip)
Updated by David Bruchmann about 5 years ago
- File wdb_language_hook.zip wdb_language_hook.zip added
I uploaded the extension without that semikolon and deleted the wrong version.
Updated by Gerrit Code Review about 5 years ago
- Status changed from New 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/+/61308
Updated by David Bruchmann about 5 years ago
In the attached extension you can find how fake-entries are used very targeted for powermail.
powermail is using it or something similar by itself to produce in frontend forms with the same html-attribute 'name', so there is a reason for it.
concerning powermail the extension is not working like expected but that's another issue.
My point is that fake-entries should be used in very special cases - if at all - and extbase is doing it completely wrong in my opinion.
I never down-voted the patch but think that the whole construction with fake-entries is a real burden for the whole TYPO3 system.
Updated by Jonas Schwabe about 5 years ago
I will have a look at the extension later (just needed to get this done).
What exactly do you mean by fake entries? No entry is being created here. Can you specify what powermail does?
Updated by David Bruchmann about 5 years ago
With fake-entries I mean that a value to a row is assigned that isn't like that in the table:
$row[ $GLOBALS['TCA'][$tableName]['ctrl']['languageField'] ] = 0;
This construction makes proper handling by the core much more more difficult as it's intended to circumvent the core-handling, which is in my opinion the wrong way.
Updated by David Bruchmann about 5 years ago
The powermail problem is this:
You create a form, including a powermail-page and fields.
In the original language for fields you create markers which are saved in the database.
Translated records never have these marker-fields but take the markers from the original language. I never found out yet how powermail is doing it in detail, but the purpose is to have in Frontend the same markers, no matter about the language. If markers are different (that can happen if the records are wrong handled by a hook, or even in some fall-back situations perhaps) the forms never work. If powermail-forms never work it can be remarked when the form is shown again after sending instead of showing a response-page.
In my extension I called these fields `intrinsicFields` and they could be configured for every extension - but very targeted and not in general.
Concerning powermail these `intrinsicFields` are handled too late by the hook I used, but the extension serves as example how a targeted usage could be realized in general.
Updated by Gerrit Code Review about 5 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/+/61308
Updated by Jonas Schwabe about 5 years ago
$row[$GLOBALS['TCA'][$tableName]['ctrl']['languageField']] = 0;
Does not create a fake record. It's actually used to prime the core language overlay because this only works when the main records is passed.
The other option would be to drop the above code block completely and ignore every relation that does not refer to the base record.
I think the idea with the current code might be, that sometimes relations do not refer to the base record (e.g. because there was no foreign_table_where in a select TCA config that makes sure only sys_language_uid = 0 or l10n_parent = null records are selectable).
Dropping this handling would therefor lead to non resolvable relations in this case.
Regarding powermail: Using getRecordOverlay_postProcessshould work because if there is a translation it should be fetched from database and contain the correct sys_language_uid once passed to getRecordOverlay_postProcessshould as far as I understand the code.
Your extension hooks into getRecordOverlay_preProcess where sys_language_uid will always be 0 if the row comes from extbase. But this is the only time getRecordOverlay does something other then just returning the same data or dropping the row completely if there is a mismatch.
Updated by Tymoteusz Motylewski about 5 years ago
Hi All,
Thanks a lot for putting effort in this area!
The language handling topic is complex and its hard to fix stuff without breaking something else. I've put some months of work to improve the situation for v9 and writing tons of tests. I'm very happy to see other people also caring for it.
Before continuing the discussion, please take a moment to read the concept of the new language handling in v9.5, so we're sure we are on the same page:
Also a good start is to see how stuff works and what is missing in the tests, please check out functional tests:
extbase/Tests/Functional/Persistence/QueryLocalizedDataTest.php
extbase/Tests/Functional/Persistence/TranslationTest.php
I'm open for scheduling a call to discuss the topic with whoever is interested.
Please also note that depending on the relation type and configuration uid's used in the relation are sometimes default language record uids and sometimes translated record uids (e.g. in inline relations).
See a summary here for details:
https://docs.google.com/document/d/1lfJqotm_omkqIJTgo4xaHteDreBUQ9_Z1_9T6nomv9c/edit#
Updated by Gerrit Code Review about 5 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/+/61308
Updated by Jonas Schwabe about 5 years ago
I thought about this a little further.
The problem here is, that there is a relation between a non translated and a translated record. In this case there are actually two relations (one to the original language and one to the translated version). This happened for some reason when we translated sys_categories (relations were also "translated").
So in addition it would probably be a good idea make sure that only relations to the original record or records that have no translation and are of the current languge can be found through a relation - similar to what happens in the repository when initially loading records.
But sure we can schedule a call if that would help to sort this out :) (maybe via Slack?)
Updated by Frank Berger over 4 years ago
I have the same problem,
a record that is not translateable has child-records which are translateable.
If the child-records are listed, for example for a <select> to edit the child-record (think changing a status from 'open' to 'approved') the selected record will be in the default language, the other records will be in the pages' language.
I think this is an object caching effect as the selected child-record has already been fetched in context to loading the main record.
I think the problem lies in TYPO3\CMS\Frontend\Page\PageRepository->getRecordOverlay
where it checks if($sys_language_content > 0) - this should rather be the $this->context->aspect('language','id')>0
because the pages' aspect holds the correct language-uid
I made a proof of concept by adding a hook with the PageRepositoryGetRecordOverlayHookInterface, and I get the correct results after that, as intended..
(the hook exchanges $sys_language_content with the id from the aspect, and switches it back after the operation)
Updated by Gerrit Code Review over 4 years ago
Patch set 4 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/+/61308
Updated by Philipp Idler over 3 years ago
Any news on this?
This bug exists in v10 and v11 too.
My steps to reproduce:- Create a page in default language
- Create a category in default language
- Select that category in page's properties
- Translate the page
- Translate the category
Result: The default page record now has one relation to default category and another one to translated category.
Saving the default page record will erase the second (falsy) translation.
Updated by Stefan Neufeind over 2 years ago
Too bad this didn't get a followup/was abandoned ...
Updated by Stefan Neufeind over 2 years ago
If needed, as a workaround maybe consider this extension (thanks to Georg):
https://github.com/georgringer/extbase_with_no_l10n_parent
Updated by Benni Mack about 2 years ago
- Related to Bug #81208: Invalid SQL query when previewing a workspace with translated relations added
Updated by Benni Mack about 2 years ago
- Related to Bug #93484: TYPO3 Workspace, Preview module raising exception for versioned plugin records added
Updated by Benni Mack about 2 years ago
- Assignee set to Benni Mack
I will have a look if the issues related already solve the problem
Updated by Benni Mack 10 months ago
Benni Mack wrote in #note-23:
I will have a look if the issues related already solve the problem
Can somebody confirm that Georg's extension (or, this patch - for v12+) solves the issue? https://review.typo3.org/c/Packages/TYPO3.CMS/+/82087
Updated by Benni Mack 10 months ago
- Status changed from Under Review to Needs Feedback
Updated by Stefan Neufeind 10 months ago
@Benni Mack Haven't used/needed it in a while. But from my comment above I remember that the extension solved an error-case in one project for us.
Updated by Christian Kuhn 10 months ago
- Related to Bug #87160: Creating site config breaks language processing in news and vhs extensions added
Updated by Christian Kuhn 10 months ago
- Status changed from Needs Feedback to Closed
Hey. We implemented a solution with #87160. I hope its safe to close here.