-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing query arguments in language menus #62
Comments
Hi, I face the same problem on different cases. In fact it's the I tried @mbrodala's solution and used directly Are you ok for a PR ? |
When generating e.g. language menus with
addQueryString
, current internal query string arguments are not taken into account.This can easily be reproduced by opening e.g. a news record and having a look at the URI pointing to translations of that news record: the URI will point to the detail page instead of the specific record.
We currently use the following to map the news parameter within an URI:
After some debugging we found out that it's related to
$_SERVER['QUERY_STRING']
:When processing a request, CoolURI first retrieves this value through
GeneralUtility::getIndpEnv('QUERY_STRING')
, and processes it. At this point$_SERVER['QUERY_STRING']
is still empty and only updated afterwards.However, there is a runtime cache for
GeneralUtility::getIndpEnv()
since TYPO3 7.5, thus every subsequent call toGeneralUtility::getIndpEnv('QUERY_STRING')
will return the original empty value.And this brings us back to the menus: if you set
addQueryString = 1
,AbstractMenuContentObject::prepareMenuItemsForLanguageMenu()
calls theContentObjectRenderer::getQueryArguments()
method which usesGeneralUtility::getIndpEnv('QUERY_STRING')
if no method was specified (default) and thus gets the initial empty value.To finalize everything: CoolURI should directly access
$_SERVER['QUERY_STRING]
and thus bypass the runtime cache ofGeneralUtility::getIndpEnv()
. There is a methodGeneralUtility::flushInternalRuntimeCaches()
but it's marked as@internal
and should thus not be used here.Our temporary workaround to fix the language menus is adding
addQueryStringMethod = GET
which then uses the uncached raw GET parameters.The text was updated successfully, but these errors were encountered: