Bug #76731
closedDiffering behaviour for handling addQueryStringMethod in Frontend and Backend
0%
Description
While comparing buildBackendUri()
in TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder
and getQueryArguments()
in TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer
, I found that buildBackendUri()
has a fallback to GeneralUtility::_GET()
if no addQueryStringMethod
parameter is provided.
getQueryArguments()
on the other hand has no such fallback, resulting in differing behaviour when no addQueryStringMethod
is provided or can't be provided as is the case with the f:form
viewhelper.
I found this out while using a Powermail form on a page with another plugin, which displays the current event and needs the UID for this. Without RealURL this works, because all parameters are still part of the QUERY_STRING
environment variable, which is the default for buildFrontendUri()
because of the above mentionend behaviour of getQueryArguments()
, after the Powermail form is submitted.
If I deactivate RealURL for my plugin to generate a speaking URL, the uid of my event is now part of the URL and therefore part of the GET
array after RealURL does its job, but not a part of QUERY_STRING
anymore. This results in parameters being lost after the Powermail form has been submitted.
- provide a fallback in
getQueryArguments()
, but I have no clue what kind of global impact this change could have - provide the
f:form
viewhelper with an additional parameteraddQueryStringMethod
, as it is now the case withf:uri.page
and similar functions
As far as I can see, this behaviour also exists in the latest 6.2.x release.
Updated by Christian Eßl over 5 years ago
I think this issue is obsolete as the form viewhelper supports the "addQueryStringMethod" parameter since TYPO3 7.6.