Project

General

Profile

Actions

Bug #88784

closed

Record language is incorrectly changed to default language in overlayLanguageAndWorkspace

Added by Jonas Schwabe about 5 years ago. Updated 10 months ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
Extbase
Target version:
-
Start date:
2019-07-16
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

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

wdb_language_hook.zip (11.3 KB) wdb_language_hook.zip David Bruchmann, 2019-07-16 17:39

Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #81208: Invalid SQL query when previewing a workspace with translated relationsClosedBenni Mack2017-05-12

Actions
Related to TYPO3 Core - Bug #93484: TYPO3 Workspace, Preview module raising exception for versioned plugin recordsClosed2021-02-10

Actions
Related to TYPO3 Core - Bug #87160: Creating site config breaks language processing in news and vhs extensionsClosed2018-12-14

Actions
Actions #1

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.

Actions #2

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).

Actions #3

Updated by David Bruchmann about 5 years ago

Ohh I'm sorry, you can just remove the semikolon in that line.

Actions #4

Updated by David Bruchmann about 5 years ago

  • File deleted (wdb_language_hook.zip)
Actions #5

Updated by David Bruchmann about 5 years ago

I uploaded the extension without that semikolon and deleted the wrong version.

Actions #6

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

Actions #7

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.

Actions #8

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?

Actions #9

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.

Actions #10

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.

Actions #11

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

Actions #12

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.

Actions #13

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:

https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.5/Important-82363-MakeExtBaseTranslationHandlingConsistentWithTyposcript.html

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#

Actions #14

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

Actions #15

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?)

Actions #16

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)

Actions #17

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

Actions #18

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.

Actions #19

Updated by Stefan Neufeind over 2 years ago

Too bad this didn't get a followup/was abandoned ...

Actions #20

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

Actions #21

Updated by Benni Mack about 2 years ago

  • Related to Bug #81208: Invalid SQL query when previewing a workspace with translated relations added
Actions #22

Updated by Benni Mack about 2 years ago

  • Related to Bug #93484: TYPO3 Workspace, Preview module raising exception for versioned plugin records added
Actions #23

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

Actions #24

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

Actions #25

Updated by Benni Mack 10 months ago

  • Status changed from Under Review to Needs Feedback
Actions #26

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.

Actions #27

Updated by Christian Kuhn 10 months ago

  • Related to Bug #87160: Creating site config breaks language processing in news and vhs extensions added
Actions #28

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.

Actions

Also available in: Atom PDF