Bug #19718

Typoscript: CONTENT | slide: multilanguage not correctly respected in content_fallback mode

Added by Stefan Galinski almost 11 years ago. Updated 5 months ago.

Status:
Accepted
Priority:
Should have
Assignee:
Category:
Frontend
Target version:
-
Start date:
2008-12-18
Due date:
% Done:

0%

TYPO3 Version:
4.2
PHP Version:
5.2
Tags:
typoscript, localization, frontend
Complexity:
nightmare
Is Regression:
No
Sprint Focus:

Description

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)

typo3_9975.patch View (1.5 KB) Administrator Admin, 2008-12-18 16:00

9975_v2.patch View (1.41 KB) Administrator Admin, 2009-02-14 13:37

typo3_9975.patch View (1.5 KB) Stefan Galinski, 2011-09-23 20:12


Related issues

Related to TYPO3 Core - Bug #19114: sys_language_mode content_fallback with a defined fallback chain does not output expected fallback content Closed 2008-07-16
Related to TYPO3 Core - Bug #17354: fallback for menus. "content_fallback;1,0" has no affect for page records (e.g. menu) Closed 2007-07-22
Related to TYPO3 Core - Bug #65863: content_fallback / mergeIfNotblank fails with content slide, pageOverlayFields is ignored Closed 2015-03-20

History

#1 Updated by Stefan Galinski almost 11 years ago

The attached patch is against TYPO3 version 4.2.3

#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 about 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
handled/interpreted:
------------------------------------------------------------------------
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 (Communication)
  • Target version deleted (0)

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

Hi Xavier,

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

#6 Updated by Stefan Galinski almost 8 years ago

Just attached the patch for the latest stable 4.5 release. This version doesn't fixes the first case mentioned by Bernhard.

#7 Updated by Stefan Galinski over 6 years ago

  • Assignee set to Stefan Galinski

#8 Updated by Stefan Galinski over 6 years ago

  • Assignee deleted (Stefan Galinski)

#9 Updated by Mathias Schreiber over 4 years ago

  • Target version set to 7.2 (Frontend)
  • Complexity set to nightmare
  • Is Regression set to No

#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

#11 Updated by Benni Mack over 4 years ago

  • Target version changed from 7.2 (Frontend) to 7.4 (Backend)

#12 Updated by Susanne Moog about 4 years ago

  • Target version changed from 7.4 (Backend) to 7.5

#13 Updated by Benni Mack almost 4 years ago

  • Target version changed from 7.5 to 7 LTS

#14 Updated by Mathias Schreiber almost 4 years ago

  • Target version deleted (7 LTS)

#15 Updated by Riccardo De Contardi about 2 years ago

  • Tags set to typoscript, localization, frontend

#16 Updated by Benni Mack 5 months ago

  • Assignee set to Benni Mack

I have to evaluate if this is fixed in 9.5 now finally...

Also available in: Atom PDF