Bug #59409
closedf:link.page invalid argument value when pageUid is missing
0%
Description
Hi,
i have strange behaviour when building navigation menu for records.
On list view im using this code:<f:link.action pageUid="{settings.detailsPid}" action="show" arguments="{foo : foo}"> {foo.name}</f:link.action>
and this one works fine here.
Now when generated link is cliked, user is moved to page with record single view and menu with links to other records of the same type. So here is used the same viewhelper to link to other records:<f:link.action pageUid="{settings.detailsPid}" action="show" arguments="{foo : foo}"> {foo.name}</f:link.action>
And now i have small problem: if i don't set 'settings.detailsPid' option in my plugin connfiguration the current page should be used (and it is) but generated urls always links to the current record so here: arguments="{foo : foo} always is used value from url argument: tx_myext_plugin[foo]=10 not the one that brlongs the the record i want to link. The problem is gone when i set 'settings.detailsPid' option in plugin configuration ... strange
TYPO3 6.2.3
PHP 5.4
Updated by Markus Klein over 10 years ago
Hi Marcin,
please do not open new issues in Fluid or Extbase, but create them on the Core project and assign the category.
Updated by Markus Klein over 10 years ago
- Project changed from 2559 to TYPO3 Core
- Category deleted (
Fluid: ViewHelpers)
Updated by Markus Klein over 10 years ago
- Category set to Fluid
- Is Regression set to No
- TYPO3 Version set to 6.2
Updated by Claus Due about 9 years ago
- Status changed from New to Resolved
I think all of this boils down to this:
It is by design and it is caused by the fact that while your `pageUid` setting may be empty, it is not explicitly null which is the only value that triggers automatic UID resolving. Result: unexpected link gets built.
Suggested workaround: surround with <f:if> and do not provide the `pageUid` when the setting is empty. That way the default value of NULL will be used and the UID gets resolved automatically.
The second problem described is one of URL argument scoping and likely caused by the two views residing in different plugins. That's a fact of life in Extbase and if it causes you further grey hairs I suggest reading the Extbase book, specifically the chapters about the URL paramters and their scope separations.
Closing as resolved: has workaround, problem case caused by incorrect usage.