Dmitry Dulepov

> If you configure the _DOMAINS you loose the language param for page path decoding No, you do not. Path decoding only uses language variable. It is set [here](https://github.com/dmitryd/typo3-realurl/blob/development/Classes/Decoder/UrlDecoder.php#L987) and...

Realurl does not create cHash. cHash is created by TYPO3 and passed to realurl. However `type` is excluded from cHash calculation. There is nothing that realurl can do about it....

Different types should generate different URLs. If it generates the same URL for different types, it means something is missing in the configuration. This is not possible to solve unless...

> Problem appeared here with 2.1.5 and with the url-cache cleared. When you clear realurl cache, you make realurl blind and it has to work hard to guess what the...

RealURL does not work well when you install TYPO3 in a subdirectory. Currently there are no plans to fix that because this is a rare case.

Please, fix your TypoScript instead: https://docs.typo3.org/typo3cms/TyposcriptReference/Setup/Config/Index.html#linkvars It is not realurl's job to change or manipulate parameters passed by users. Realurl uses and stores them as is. You should always have...

Realurl processes parameters as it gets. It will not convert anything to int. Please, do it in the calling side. Goal of RealURL is to convert URLs as is according...

Firsts, that is no such thing as "Real Url". Secondly, if original URL contains `L` in this bad format, than your TypoScript is clearly wrong because the limitation for `L(int)`...

The problem still may happen if you use `typolink.addQueryString` without `exclude=L`. This option bypasses checks for `config.linkVars` and it is the most typical case of bad parameters in links.

@jhamecher > The problem is that RealURL is adding false entries to the tx_realurl_urldata table. There is no such thing as "false entries". Realurl receives those URLs from TYPO3. If...