Typoscript: CONTENT | slide: multilanguage not correctly respected in content_fallback mode
The sliding functionality doesn't respect the content_fallback mode correctly. It delivers always content elements of the fallback/calculated language from the current selected page. The attached patch fixes this bug by an additional check of the page record which is referenced by the content element.
Steps to Reproduce (only in "content_fallback" mode)
1) Create a marker in a template which slides content elements of a column...
template.bla = TEMPLATE
template.bla.marks.BLA < styles.content.get
template.bla.marks.BLA .select.where = colPos = 0
template.bla.marks.BLA .slide = -1
2) Create a page with a subpage and assign the template via typoscript
3) Create the content elements on the top page which should be slided
4) Create a translation of the top page and the content elements
5) Test the result in the frontend for the top page and the parent page in both site languages. Oopps...
(issue imported from #M9975)
#2 Updated by Stefan Galinski over 10 years ago
I have added the missing trunk patch to the report.
The bug causes any multilanguage site with an enabled "content_fallback" mode to be broken with slided content elements. You always get the content elements of the default language on the subpage, even if there is a valid translation (!) on the parent page. This is caused due to a missing check of the page overlay record.
You can only reproduce the bug, if you haven't add an alternative language to the subpage! IMHO the content sliding should not depend of an existing alterntive language on the subpage. It's tricky enough to describe the slide behaviour to redacteurs without such traps.
#3 Updated by Susanne Moog over 9 years ago
For the sake of completeness here the explanation from Bernhard on the mailing list on this topic:
The problem is relatively complex. It shoul be clarified that there are
two different ways of how the scenario "language" + "sliding" could get
A Slide down the rootline, until you find a page with current
language. If nothing is found, eventually slide down the rootline again
looking for elements of "content_fallback" language.
B Slide down the rootline, and on every depth check if there are
elements which could satisfy current "content_fallback" settings.
The situation YOU described only occurs, when you have set
config.sys_language_mode = content_fallback
config.sys_language_overlay = 1
But you are correct: If you have &L=1 in your URL and visit a page which
hasn't got a translation, then the fallback mode will switch
TSFE->sys_language_content to "0" (lets assume this easy case - when
there are only two languages) ...
now when sliding-back happens, it will always try to use content
elements with sys_language_uid=0 ... altough &L=1 was passed .... to
describe the problem somewhat easier ...
You patch properly fixes this problem, and I have no objections if you
are going to commit it this way. It will implement type B. So +1 from
me for your patch!!!
But it should get noted that the feature "sliding" + "languages" is not
completly finished with this patch.
Be aware: this does not cover all possible ways of translating a page.
It could be, someone didn't set "sys_language_overlay = 1". When this
flag IS set (like in your case), TYPO3 usually fetches all content
elements with sys_language_uid=0, and the performs the overlay.
So in this case it is a "must" that you translate your default-language
elements to the alternative language. So if you have 3 default-language
elements for example, you can't have 4 translated elements ...
(sys_language_parent of tt_content gets used here) ...
But if sys_language_overlay is NOT set, the CONTENT cObj usually simply
pulls all content elements having the requested sys_language_uid
directly, without overlay. In this case sliding-backwards now becomes
problematic. One would have to "re"-set TSFE->sys_language_content for
every depth again (storing the original value), to check if there are
content elements (to implement type B)
So you see - it can get VERY tricky. Above descriptions only solve
variant B - it could still be someone requests variant A and we are
all totally fu**** up !!!
#4 Updated by Xavier Perseguers over 8 years ago
- Category deleted (
- Target version deleted (
Hi, did not test this patch yet but sounds like the way to solve my problem where I'd like to use fallback language for page resources before sliding to parent pages.
If this is what is intended to be allowed, could you please update your patch with current master?
#5 Updated by Stefan Galinski over 8 years ago
I'am using this patch since ages, but it's doesn't work like it should in some cases. See the comment one above yours. It's a very tricky stuff that costs some performance and would need a lot of tests. Just updating the patch for master wouldn't solve the problems. :-)
#10 Updated by Sigfried Arnold over 4 years ago
This issue might also be related to #65863 - it is pretty much the same, where solution "B" should apply in most cases but does it the other way around - this was not an issue in 4.5 and worked "fine" since there was no need to translate images at all.
now with FAL you could translate your images or your description and this messes up the whole page overlay and levelmedia thing