Bug #25823

tslib_cObj::typoLink() geneates invalid links

Added by Michiel Roos about 2 years ago. Updated 3 months ago.

Status:New Start date:2011-04-07
Priority:Must have Due date:
Assignee:- % Done:

0%
Category:Content Rendering
Target version:4.5.12
TYPO3 Version:4.5 Complexity:
PHP Version:
Votes: 1 (View)

Description

TypoLink generates (W3C) invalid links.

Example link in URL bar:
index.php?id=36&TEST=blah[something]

Observed result link from a certain extension using TypoScript typoLink:
index.php?id=36&TEST=blah%5Bsomething%5D&tx_powermail_pi1[mailID]=255&cHash=c81838f48ba09c7dd254e1b37814a86e

Expected result:
index.php?id=36&TEST=blah%5Bsomething%5D&tx_powermail_pi1%5BmailID%5D=255&cHash=c81838f48ba09c7dd254e1b37814a86e

Errors:
- & should be &
- The brackets in the extension parameters are not encoded

Probable problem areas:
- t3lib_div::implodeArrayForUrl()
- t3lib_div::explodeUrl2Array()
- t3lib_TStemplate::linkData()
- realurl

When realurl is enabled, the link parts for which there is no realurl configuration are properly encoded but the & is not replaced with &. RealUrl uses the hook 'typoLink_PostProc' in typoLink().

But it makes sense for TYPO3 to generate validating links out of the box without realurl being enabled.

History

#1
Updated by Michiel Roos about 2 years ago

Damn these fancy html issue trackers . . .

:-)

Example link in URL bar:
index.php?id=36&TEST=blah[something]

Observed result link from a certain extension using TypoScript typoLink:
index.php?id=36&TEST=blah%5Bsomething%5D&tx_powermail_pi1[mailID]=255&cHash=c81838f48ba09c7dd254e1b37814a86e

Expected result:
index.php?id=36&TEST=blah%5Bsomething%5D&tx_powermail_pi1%5BmailID%5D=255&cHash=c81838f48ba09c7dd254e1b37814a86e

Errors:
- & should be &
- All values and parameters should be properly encoded (brackets etc.)

#2
Updated by Oliver Hader almost 2 years ago

  • Target version changed from 4.5.3 to 4.5.4

#3
Updated by Jo Hasenau almost 2 years ago

Well - actually the & should be only "amp;ed" for doktypes that require the amp;

HTML should get no amp; at all, while XHTML xxx should get it.

We had to fix some issues like that in a clients project still using the 4.3.x core and noticed that typolink doesn't care about the doktype at all, since it always uses htmlspecialchars for the whole URL. So it looks like we have to fix typolink completely so that it will generate a valid output for any available doktype.

Since this might break the output of extensions that are using typolink and provide a workaround for the problem, we will have to decide though, if this should be fixed in 4.5 at all.

#4
Updated by Oliver Hader almost 2 years ago

  • Target version changed from 4.5.4 to 4.5.6

#5
Updated by Chris topher over 1 year ago

  • Target version changed from 4.5.6 to 4.5.8

#6
Updated by Ernesto Baschny over 1 year ago

  • Target version changed from 4.5.8 to 4.5.12

Also available in: Atom PDF