[BUGFIX] Avoid PHP error with empty GLOBALS lang #26
Conversation
| return $data; | ||
| } | ||
| if (TRUE === empty($GLOBALS['TSFE']->lang)) { | ||
| $GLOBALS['TSFE']->lang = $languageKey; |
There was a problem hiding this comment.
We definitely do not want to be doing this. It is far from the job of FLLL to be manipulating the frontend context - we should instead plan and simple avoid processing when no language is set and no default is given.
Be aware also that the "TSFE" object has changed in recent TYPO3 versions. The public property may no longer be trustworthy or the correct way of resolving the current language.
|
The behavior is really strange. In my option it is the fault of T3 API, it is public and allows empty values, but does not allow default and checks against it. Default isn't set in core class and throws the Exception. |
|
It is absolutely the fault of TYPO3's API - the question is, how do we avoid the situation without manipulating the frontend context? We don't want the situation where FLLL is actually patching what is essentially a bug, or even setting a value that makes some other extension or the core itself fail to use languages correctly. Instead, we want the situation where FLLL either doesn't try to generate labels or becomes capable of resolving the default language if this bad API public property is empty. |
xf-
force-pushed
the
workaroundExceptionLang
branch
2 times, most recently
from
891bd8b
to
33194cc
Compare
xf-
force-pushed
the
workaroundExceptionLang
branch
from
33194cc
to
876878c
Compare
|
Hook that caused the issue is now removed. We should not prevent building of labels completely in FE, rather avoid the problem at the source. Thanks btw for helping me track down the source last week! |
Core does not check against empty lang. - Empty means it uses complete object, not the wanted language. This sets a lang if it is empty.
@NamelessCoder shouldn't we disable it in FE?