TYPO3 Core

I repeated the same experiment of Benni on 9.5.4 and agree that the only "weird" case is b) that is:

- original element: hidden
- translated element: not hidden

which leads to (please uncheck "Show hidden content elements"):

BE:
- original element: Not visible (visible only in list view of course)
- translated element: Visible

FE:
- original element: Not visible
- translated element: Not visible

As we're discussing about "connected mode" I see only two options here:

1) The [hidden] property should be not editable in "connected mode" (like [starttime] for example) and so it is inherited from the original element. So case b) is not possible (and also a))

2) the "[hidden]" property can still be modified in "connected mode" so the "original" and "translated" state are kinda "unrelated" (like [header] for example) and so the status of the element in frontend reflects its status on backend

I'd recommend the 2) solution as IMO is more flexible and does not seem to have unpleasant side effects.

P.S. there would be also a third option, which is an alert that warns the editor in case b) there would be a discrepancy and if the goal is

FE:
- original element: Not visible
- translated element: visible

the good option is not "connected mode" but the other one.

Dear Gentlemen,

the current situation breaks compatibility with 8LTS.
I have just been testing a bigger migration with more than 30 languages and here this changes becomes a true pain.

So, I found line 7024 in typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php
it was
$languageQuery = $expressionBuilder->in($languageField, [0, 1]);
and I changed it to
$languageQuery = $expressionBuilder>in($languageField, [-1, $languageAspect->getContentId()]);

and it seems to fix the compatibility issue here.

The major issue behind all this is that it breaks compatibility when you migrate from an 8LTS system.

Imagine you have a system where default language is English and all other Languages have a higher sys_language_uid.
You have multiple domains as you are in an international organization with local sites.
So in some cases English is not even being used.
Now the editors have been trained to create any content in "Default"(==English) first and then to translate it.
In some cases they have different content for English and their local Language, so they used to disable/hide the "Default" part of their content as the localized part remained visible.

With 9LTS this breaks tens of thousands of content elements in my migration case.
My developers and I are developing a patch today and we will publish it here as soon as possible.
I am quite used to run a patched system, but I hope with the structural changes of the TYPO3 Organization, that the Vanilla TYPO3 becomes more useable and will include such important compatibility patches faster.

Best regards,

Patrick

Hey Patrick,

can you send us your TypoScript settings that worked for you in TYPO3 v8?

Thanks.
Benni.

Dear Benni,

to fix for compatibility, I had to extend the patch:

if ($table == 'pages') {
              $languageQuery = $expressionBuilder->in($languageField, [0, 1]);
            } else {
              $languageQuery = $expressionBuilder>in($languageField, [-1, $languageAspect->getContentId()]);
            }

And this fixes now all my issues.

The main issue behind all this is that content elements always refer to the "default" language "pages" element.
So the original Expression did fix issues with Menues, etc. but it broke the content elements themselves as their visibility, etc. was depending on the "default" language.
Now that presented two severe issues:
1. the visibility of the content element was depending on the "default" language part of that element.
2. it was impossible to have the "default" language element hidden where the translated element should be visible.
In my case this broke compatibility with hundreds of thousands content elements in my multi language multi domain system which I am currently preparing for upgrade to 9LTS.
In the end I had to conclude that we need different logics here, if it is about "pages" compared to "tt_content" or other tables and I ended up with the construct above.

I hope this will be included in the main core in the next patch version, as probably many people will have issues.
However I am well aware that those who have started with a new multilanguage system will face the changed behavior.

I would give priority to compatibility.

Best regards,

Patrick

Daxboeck no-lastname-given wrote:

...
And this fixes now all my issues.

Just the make sure we are taking about the correct "line 7024", I've added a link to recent Git change in v9.5 branch, it's "line 7029" now - please correct if that's still the wrong one
https://github.com/TYPO3/TYPO3.CMS/blob/d181eb9e4e32f377fe38fe66c78e40ba3088b2d6/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php#L7029

In case that's the correct place, next step would be to identify which settings and scenarios are causing trouble on your side since implementation does not look that dramatically different compared to line 7505 in v8 (https://github.com/TYPO3/TYPO3.CMS/blob/5bb260cb0170355d23ff696c1bc3c2d2caffa37b/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php#L7505).

• Can you please provide the TypoScript configuration that worked for you in TYPO3 v8?
• How was l18n_cfg behavior defined (on page level and/or globally)?
• Have been other 3rd party l10n_* extension involved in your scenario?

Dear Maintainers,

I have to add another fix here on a side effect:

--- RootlineUtility.php-2019-04-26-dax 2019-04-26 06:17:01.183964267 0200
++ RootlineUtility.php 2019-04-26 06:18:30.467159728 0200
@ -405,7 +405,7 @
$parentUid = $page['pid'];
}
$cacheTags = ['pageId_' . $page['uid']];
- if ($parentUid > 0) {
if (($parentUid > 0) && ($page['is_siteroot'] === 0)) {
// Get rootline of (and including) parent page
$mountPointParameter = !empty($this->parsedMountPointParameters) ? $this->mountPointParameter : '';
$rootline = GeneralUtility::makeInstance(self::class, $parentUid, $mountPointParameter, $this->context)->get();

Without that fix the Rootline Utility goes beyond the root of a site.

Best regards,

Patrick

We have to add some more tests to that. The recent change that will be built in 9.5.6 about fallback handling should handle most of the issues already
https://docs.typo3.org/typo3cms/extensions/core/latest/Changelog/9.5.x/Feature-86762-EnhancedFallbackModesForTranslatedContent.html