[TYPO3-english] RealURL and typeNum bug

[Dmitry Dulepov]

Hi!

Victor Livakovsky wrote:
> I supposed so, because, when I have such path: /index.php?id=4&type=98,
> everything is OK, but with: /page-with-id-4.html?type=98 there was
> such problem.
> As I wrote at last post, adding:
> 'GETvar' => 'type',
>          'valueMap' => array(
>                     'print' => '98',
>          ),
>          'noMatch' => 'bypass'
> to preVars solves the problem, but I think it should work even without
> it.

Yes, it should work without preVar.

> Because, f.e., if I don't have such section in preVars:
> 'GETvar' => 'L',
>          'valueMap' => array (
>                     'en' => '1',
>                     'de' => '0',
>          ),
>          'noMatch' => 'bypass'
> i'll get such url: /page-with-id-4.html?L=1 (for english version) and
> everything will be displayed like with /index.php?id=4&L=1.

So it works with "L" but does not work with "type". RealURl does not know anything about "L" or "type". In fact, it does know anything about TYPO3 magic URL variables except for "id".

> That's why I supposed, that it's RealURL problem.

I still do not see how it can be possible. Decoding process uses only path (/path/to/page), it does not use anything after the question mark (query part). There was a bug in ancient versions of RealURL, where everything after question mark was ignored. But this bug was fixed long time ago (many months) and existing query part is always appended to the regenerated query string. Unless you use a very old version of RealURL, I cannot see how RealURL can be invloved in "eating" type number :(

-- 
Dmitry Dulepov
TYPO3 Core team
My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book
In the blog: http://typo3bloke.net/post-details/iphone_as_productivity_tool/