Project

General

Profile

Actions

Bug #80896

closed

TypolinkViewhelper with linkhandler ignores class attribute

Added by Kai Tallafus over 7 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Site Handling, Site Sets & Routing
Start date:
2017-04-19
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Linkhandler TypoScript definition:

config.recordLinks.products {
    forceLink = 0

    typolink {
        parameter = 9
        additionalParams.data = field:uid
        additionalParams.wrap = &tx_product_productlist[product]=|&tx_product_productlist[action]=show
        ATagParams.data = parameters : allParams
        useCacheHash = 1

    }
}

Fluidtemplate:

<f:link.typolink parameter="{teaser.primaryLink}" class="btn btn-yellow">....</f:link.typolink>

Output:

<a href="...">...</a>

How are we supposed to output such links with different classes?

ATagParams.data = parameters : allParams helps with links set and styled from RTE, but how can different classes be passed from typolink viewhelper?


Related issues 8 (0 open8 closed)

Related to TYPO3 Core - Bug #81316: linkhandler does not respect custom typolink configurationClosed2017-05-23

Actions
Related to TYPO3 Core - Bug #81620: Linkhandler remove all attributes set in the link wizard and the templateClosed2017-06-19

Actions
Related to TYPO3 Core - Bug #81903: DatabaseRecordLinkBuilder is ignoring other settingsClosed2017-07-18

Actions
Related to TYPO3 Core - Bug #97869: typolink with returnLast returns also more information than just the URLClosedBenni Mack2022-07-07

Actions
Related to TYPO3 Core - Bug #98065: TypoScript image file link with target _blankClosed2022-08-02

Actions
Related to TYPO3 Core - Bug #98108: Regression with nested parameter for typolinkClosed2022-08-09

Actions
Has duplicate TYPO3 Core - Bug #82985: class in f:link.typolink ignoredClosed2017-11-13

Actions
Precedes TYPO3 Core - Bug #90404: Linkhandler removes all attributes set in fluid viewhelper if parameter uses stdWrapClosed2017-04-202017-04-20

Actions
Actions #1

Updated by Benni Mack over 7 years ago

  • Target version changed from 8 LTS to next-patchlevel
Actions #2

Updated by Georg Ringer over 7 years ago

  • Related to Bug #81316: linkhandler does not respect custom typolink configuration added
Actions #3

Updated by Georg Ringer over 7 years ago

You can solve this by using

<a href="{f:uri.typolink(parameter:link) -> f:format.htmlspecialchars()}" class="xxx">{header}</a>

Actions #4

Updated by Wouter Wolters about 7 years ago

  • Has duplicate Bug #82985: class in f:link.typolink ignored added
Actions #5

Updated by Marc Hirdes over 6 years ago

Any news on this topic?

<a href="{f:uri.typolink(parameter:link) -> f:format.htmlspecialchars()}" class="xxx">{header}</a>

Is no workaround in any case. If the link has already a target, title etc. this would be ignored in this case.

Actions #6

Updated by Mordamir over 6 years ago

I dont know how to create a patch, so i post code which fixed it for me. I added the following code to TypolinkViewhelper.php at line 150.

if (strpos($typolinkConfiguration['url'], '&')) {
    // Separate additional params from url. uid needs to be in url, so we need to
    $pos = strpos($typolinkConfiguration['url'], '?') + 1;
    $url = substr($typolinkConfiguration['url'], 0, $pos);
    $query = substr($typolinkConfiguration['url'], $pos);
    parse_str($query, $params);
    $typolinkConfiguration['url'] = $url + 'uid=' + $params['uid'];
    unset($params['uid']);
    $typolinkConfiguration['additionalParams'].= '&' . http_build_query($params);
}

It basically looks into the url part of typolinkConfiguration for an ampersand, and if found, adds all additional query parameters to the 'additionalParams' section of the link configuration. Because the uid parameter needs to be part of the url section, the uid is handled separately.
Maybe the more correct place would be the decode function of the TypoLinkCodecService.

Actions #7

Updated by Mordamir over 6 years ago

Sorry, my code diddnt fix the issue. The class is now appied correctly, but the generated link is not. I think this is because the t3://record?identifier=tx_news&uid=... cannot be resolved if i move the uid in the first place.

Actions #8

Updated by Mordamir over 6 years ago

The probleme here is that DatabaseRecordLinkHandler ignores any settings from the $conf-array, because it uses the configuration from config.recordLinks.
It should somehow mix the config.recordLinks with the data from $conf, but it seems this is not a trivial task. Its not clear what parameters should be overwritten or appended. $target should be overwritten, but $class could be overwritten or appended. And mixing aTagParams would be a mess.

Actions #9

Updated by Rémy DANIEL over 6 years ago

Hello

A workaround:

<f:link.typolink parameter="123" additionalAttributes="{class:'some-class'}">

additionalAttributes will not be overriden by linkhandler config, but parameter will be.

Actions #10

Updated by Rémy DANIEL over 6 years ago

  • Related to Bug #81620: Linkhandler remove all attributes set in the link wizard and the template added
Actions #11

Updated by Rémy DANIEL over 6 years ago

  • Related to Bug #81903: DatabaseRecordLinkBuilder is ignoring other settings added
Actions #12

Updated by Tom Voigt over 6 years ago

DANIEL Rémy wrote:

Hello

A workaround:
[...]

additionalAttributes will not be overriden by linkhandler config, but parameter will be.

This is not working. I just tested it to get a class into the link like this:

   <f:link.typolink parameter="{link}" additionalAttributes="{class: 'class', data-test: 'test'}" title="{rondellItem.header}">Test</f:link.typolink>

Links without linkhandler are correct. Links with the linkhandler do not have any class or other attribute. Testet on TYPO3 8.7.13.

Actions #13

Updated by Riccardo De Contardi over 6 years ago

Maybe solved with #81620 ? Or am I wrong?

Actions #14

Updated by Rémy DANIEL about 6 years ago

Riccardo De Contardi wrote:

Maybe solved with #81620 ? Or am I wrong?

#81620 solves part of the issue.

But, it remains an edgecase.

TLDR;
always put the page uid directly in the typolink parameter, not in parameter.

Context

- A typolink is make from a Fluid VH : <f:link.typolink parameter="{linkValue}" class="btn btn-small">{linkLabel}</f:link.typolink>
- In the Fluid template, {linkValue} contains t3://record?identifier=rss&uid=416

Not working TS config:

config.recordLinks.rss {
    typolink {
        parameter.data = field:uid
        useCacheHash = 1
    }
}

Working TS config:

config.recordLinks.rss {
    typolink {
        parameter = {field:uid}
        parameter.insertData = 1
        useCacheHash = 1
    }
}

Explanation:

In both cases, DatabaseRecordLinkBuilder receives t3://record?identifier=rss&uid=416 - "btn btn-small" as typolink parameter.
In both cases, DatabaseRecordLinkBuilder builds a typolink configuration (result from a merge of the typolink parameter and the TS config), and call ContentObjectRenderer->typolink function.

But...

In the former, ContentObjectRenderer->typolink receives this:

parameter = - - "btn btn-small" 
parameter.data = field.uid

Here, stdWrap overrides the whole paremeter value, and the part - "btn btn-small" of the typolink config is lost.

In the latter, ContentObjectRenderer->typolink receives this:

parameter = {field:uid} - "btn btn-small btn-outline-white" 
parameter.insertData = 1

Here, stdWrap replaces {field:uid}, and the typolink config is complete: 416 - "btn btn-small"

Conclusion
I don't think this is a bug: with #81620, a typolink configuration is now correctly merged from the Fluid VH to the linkhandler configuration.
But the linkhandler TS config must be very carefully wrote.

Regards.

Actions #15

Updated by Susanne Moog about 6 years ago

  • Sprint Focus set to On Location Sprint
Actions #16

Updated by Benni Mack over 5 years ago

  • Target version changed from next-patchlevel to Candidate for patchlevel
Actions #17

Updated by Susanne Moog almost 5 years ago

  • Sprint Focus deleted (On Location Sprint)
Actions #18

Updated by Benni Mack over 4 years ago

  • Status changed from New to Closed

Hey,

thanks for the detailled explanation, I will close this issue now. If you still feel there is more work to do, let me know, and I will re-open the ticket.

Actions #19

Updated by Felix Nagel over 2 years ago

  • Precedes Bug #90404: Linkhandler removes all attributes set in fluid viewhelper if parameter uses stdWrap added
Actions #20

Updated by Felix Nagel over 2 years ago

In specific cases, this bug is still an issue. See https://forge.typo3.org/issues/90404

Actions #21

Updated by Benni Mack over 2 years ago

  • Status changed from Closed to New

Re-opening

Actions #22

Updated by Gerrit Code Review over 2 years ago

  • Status changed from New to Under Review

Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74534

Actions #23

Updated by Gerrit Code Review over 2 years ago

Patch set 2 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74534

Actions #24

Updated by Gerrit Code Review over 2 years ago

Patch set 1 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74576

Actions #25

Updated by Gerrit Code Review over 2 years ago

Patch set 2 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74576

Actions #26

Updated by Gerrit Code Review over 2 years ago

Patch set 3 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74576

Actions #27

Updated by Gerrit Code Review over 2 years ago

Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74620

Actions #28

Updated by Gerrit Code Review over 2 years ago

Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74620

Actions #29

Updated by Gerrit Code Review over 2 years ago

Patch set 3 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74620

Actions #30

Updated by Gerrit Code Review over 2 years ago

Patch set 4 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74620

Actions #31

Updated by Felix Nagel over 2 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #32

Updated by Gerrit Code Review over 2 years ago

  • Status changed from Resolved to Under Review

Patch set 4 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74576

Actions #33

Updated by Gerrit Code Review over 2 years ago

Patch set 5 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74576

Actions #34

Updated by Felix Nagel over 2 years ago

  • Status changed from Under Review to Resolved
Actions #35

Updated by Philipp Kitzberger over 2 years ago

Upgrading to 11.5.11 seems to be breaking the returnLast feature:

link = TEXT
link.typolink.parameter.field = header_link
link.typolink.returnLast = url

header_link contains "https://www.example.org _blank" is my example.

With 11.5.10 the result is https://www.example.org
With 11.5.11 the result is https://www.example.org _blank

Actions #36

Updated by Benni Mack over 2 years ago

Philipp Kitzberger wrote in #note-35:

Upgrading to 11.5.11 seems to be breaking the returnLast feature:
[...]

header_link contains "https://www.example.org _blank" is my example.

With 11.5.10 the result is https://www.example.org
With 11.5.11 the result is https://www.example.org _blank

Hey Philipp,

thanks for this important hint. I will open a new ticket for this

Actions #37

Updated by Benni Mack over 2 years ago

  • Related to Bug #97869: typolink with returnLast returns also more information than just the URL added
Actions #38

Updated by Oliver Hader over 2 years ago

  • Related to Bug #98065: TypoScript image file link with target _blank added
Actions #39

Updated by Christian Kuhn over 2 years ago

  • Related to Bug #98108: Regression with nested parameter for typolink added
Actions #40

Updated by Benni Mack about 2 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF