Task #86321

Page Module: Connected Mode does not reflect hidden flag properly

Added by Benni Mack 9 months ago. Updated about 2 months ago.

Should have
Backend User Interface
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Sprint Focus:


When having a translated content element ("connected mode") from default language in connected mode, it is unclear how the backend should render the translated content element, if the content element in default language is hidden. The four states exist:

a) Default Language = not hidden, Translation = hidden > Translation hidden in FE & BE
b) Default Language = hidden, Translation = not hidden > Translation hidden in FE & not hidden in BE
c) Default Language = hidden, Translation = hidden > Translation hidden in FE & BE
d) Default Language = not hidden, Translation = not hidden > Translation not hidden in FE & BE

Translation hidden in FE means that it is not rendered.
Translation hidden in BE means that the CE is "greyed out".

Interesting case is "b" where it has to be defined if the translation should be hidden in BE as well. If so, the content element should also be greyed out, or not... Question is - what should an editor expect?

We had this issue and an editor was confused about the current state on case "b".


#1 Updated by Riccardo De Contardi 4 months ago

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"):

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

- 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

- original element: Not visible
- translated element: visible

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

#2 Updated by Daxboeck no-lastname-given 3 months ago

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,


#3 Updated by Benni Mack 3 months ago

Hey Patrick,

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


#4 Updated by Daxboeck no-lastname-given 3 months ago

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,


#5 Updated by Oliver Hader 3 months ago

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

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?

#6 Updated by Daxboeck no-lastname-given about 2 months ago

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,


#7 Updated by Benni Mack about 2 months ago

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

Also available in: Atom PDF