[TYPO3-core] RFC: Bug 5602: spamProtectEmailAddresses_atSubst is not recognized correctly

[Franz Holzinger]

Hello Oliver, 

>> But here a case is mentioned, when all characters are changed into Unicode
>> mailto:a at b.c will be converted to
>> mailto:a@b.c
>> So the new code line
>> $spamProtectedMailAddress = str_replace('@', ($atLabel ? $atLabel :
>> '(at)'), $mailAddress);
>> needs only be done in the ELSE block of this IF:
>> if ($GLOBALS['TSFE']->spamProtectEmailAddresses === 'ascii')
>> And IMHO even more lines doing replacements should go there.
> 
> Sorry, I didn't get your point...
> * there is a $mailToUrl, used like <a href="$mailToUrl">
> * there is a $linktxt, used like <a href="...">$linktxt</a>
> * the $linktxt normally contains something like "E-Mail: xy at host.com"
> * thus, after applying substitution to $linktxt we have e.g.
>   <a href="...">E-Mail: xy[at]host[dot]com</a>
> * using this substitution on $mailToUrl doesn't make much sense and
>   would be e.g. <a href="mailto:xy[at]host[dot]com"> 
> 
> Maybe I'm wrong, but I can't see the disadvantages you mentioned.

I did not mean the normal case where @ gets replace. But only the case with
$GLOBALS['TSFE']->spamProtectEmailAddresses === 'ascii')	{
     $mailToUrl = $GLOBALS['TSFE']->encryptEmail($mailToUrl); 

where only encrpytion takes place. Nothing will be replaced here. Therefore 
it is redundant and wrong to apply the replacement function for @ also in 
this case. 

 - Franz