[FEATURE] Multiple GETvars with lookUpTable configuration in a single fixedPostVars set

[jensengelmann]

In a recent project we encountered the following problem: We had to map the single view of different controllers on one page. TYPO3-wise it's not the problem - you can check the given GETvar (for example tx_myextension_pi1[article] and tx_myextension_pi1[project]) and then set the controller and action accordingly.

The problem arose when we tried to configure realurl accordingly. We skipped the controllers and the actions with 'noMatch' => 'bypass, but then needed to check for two different GETvars each with a lookUpTable configuration. We just tried it and realurl did encode the url but added a additional slash when the first GETvar with lookUptable configuration didn't match and the second GETvar lookUpTable configuration was triggered.

mysite.html?tx_myextension_pi1[controller]=Project&tx_myextension_pi1[action]=Detail&tx_myextension_pi1[project]=1 => mysite/title-of-the-project.html

mysite.html?tx_myextension_pi1[controller]=Article&tx_myextension_pi1[action]=Detail&tx_myextension_pi1[article]=1 => mysite//title-of-the-article.html

It seemed that realurl was running thru the first GETvar llookUpTable configuration although the parameter was not actually in the url and then added an empty path segment. So we tried to fix it by changing the encodeUrlParameterBlockUsingLookupTable like this:

protected function encodeUrlParameterBlockUsingLookupTable(/** @noinspection PhpUnusedParameterInspection */ $getVarName, $getVarValue, array $configuration, array &$segments, &$previousValue)
{
    $result = FALSE;

    if (isset($configuration['lookUpTable'])) {
        // check if the get parameter is actually in the request url
        if (strpos(rawurldecode($this->urlToEncode),$getVarName)) {
            $previousValue = $getVarValue;
            $segments[] = rawurlencode($this->createAliasForValue($getVarValue, $configuration['lookUpTable']));
        }
        $result = TRUE;
    }

    return $result;
}

It now works fine for us, but we don't know if it might break intended behaviour anywhere else. Maybe it's a feature you can implement in realurl since I think it might be a not so uncommon use case.

[dmitryd]

It seemed that realurl was running thru the first GETvar llookUpTable configuration although the parameter was not actually in the url and then added an empty path segment.

This is correct. You configured two GETvars, so there should be two segments. If one of your GETvars can be missing, you have to make two different postVars for them.

In your case this works only because you have a cache entry. However if you remove the cache entry, decoder will treat the only segment as the first GETvar, not as the second. So you will get wrong decoding.

This cannot work as you expect. Your only way is to make two separate postVars.