Bug #16741

typoLink doesn't use "type" correctly with simulateStaticDocuments

Added by Oliver Hader almost 13 years ago. Updated almost 8 years ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2006-11-27
Due date:
% Done:

0%

TYPO3 Version:
4.7
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Imagine a TypoScript configuration like the following and simulateStaticDocuments enabled:

page.10 = TEXT
page.10 {
stdWrap = 1
stdWrap.typolink {
returnLast = url
useCacheHash = 1
parameter.data = tsfe:id
additionalParams = &type=5
}
}

You would get something like this as link-URL:

SomePage.13+M5bd9214a8c2.0.html?&type=5

If a user clicks that link, he isn't forward to typeNum "5" as defined, but to the regular typeNum "0". So we would expect to have a link like the following one:

SomePage.13.5.html

The MD5-Part is missing here because it was used for the "&type=5" param only.

The attached patch file is exactly doing this by adding an additional check to tslib_cObj::typoLink.

It's not only a 4.1-beta1a issue. This exists since a long time... ;-)
(issue imported from #M4564)

patch_typolink.diff View (1.38 KB) Administrator Admin, 2006-11-27 10:35

4564_typolink_typeparam.diff View (851 Bytes) Administrator Admin, 2007-08-02 17:29


Related issues

Related to TYPO3 Core - Feature #16088: Adding propertie "class" for typolink Closed 2007-08-02

History

#1 Updated by Marc Bastian Heinrichs almost 13 years ago

I think this is no bug. The type can be included in the typolink.parameter property. Then simulateStatic should work correct - realurl does.
For your TS:

page.10 = TEXT
page.10 {
stdWrap = 1
stdWrap.typolink {
returnLast = url
useCacheHash = 1
parameter {
data = tsfe:id
wrap = |,5
}
}
}

#2 Updated by Oliver Hader almost 13 years ago

That's correct. But you're wrapping the parameter to set the type. My approach is setting - the type. So you're making a step around to do what could be done directly. Look at this as kind of HCI issue.

#3 Updated by Thorsten Kahler almost 13 years ago

The parameter "type" has a special meaning in TYPO3 and so it's handled special. It should always be set according to TSRef [1] else there are some other side effects, too.

[1] http://typo3.org/documentation/document-library/references/doc_core_tsref/4.0.0/view/5/8/

#4 Updated by Steffen Kamper over 12 years ago

as you can see in class.tslib_content.php in function typolink, the type get's his special part in $link_param, which takes data only from parameter:

unset($theTypeP);
$pairParts = t3lib_div::trimExplode(',',$link_param);
if (count($pairParts)>1) {
$link_param = $pairParts0;
$theTypeP = $pairParts1; // Overruling 'type'
}

So in my opinion this has to added by a special parameter, like this:

10.typolink.parameter = 7
10.typolink.type=150

with adding one line after above mentioned code:
if($conf['type']) $theTypeP =$conf['type'];

something like this would be my suggestion. I've tested and for me works perfect.

and then there is an easy way to overrule the type fom TS or php.

#5 Updated by Dmitry Dulepov over 12 years ago

parameter.dataWrap = {TSFE:id},5

#6 Updated by Mario Matzulla over 12 years ago

Hi guys!

You must be kidding ;)

"Now the input can be an alias or page-id. If the input is an integer it's a page-id, if it's two comma separated integers, it's a id/type pair, else it's an alias."

This is the only passage in the TSRef which shows how to handle the type parameter. I don't consider myself a good php programmer, but I do have some knowledge about "well written code" and this is definitely something underneath loooooow level. How can you combine a parameter with another one like that if you can use multiple parameters for a function call?
Why is function($address), where $address is a csv-list, dieing out? Because today you can write it better and more user-friendly: function($name, $street, $zip, $city).

So please, consider a change of code. I know that this is not a bug, but something that could make life a lot easier.

#7 Updated by Elmar Hinz about 12 years ago

I vote for Steffen Kamper's solution:

10.typolink.parameter = 7
10.typolink.type=150

@Thorsten Kahler

Where do you find something about side effects in TSRef [1] if the type is not set? Has it been removed from that page. For me the type still defaults to 1 of not set.

[1] http://typo3.org/documentation/document-library/references/doc_core_tsref/4.0.0/view/5/8/

#8 Updated by Dmitry Dulepov about 12 years ago

Well, while solution already exists (see my example with dataWrap), but I lik Steffen's solution too. Except that it has to be a proper patch to get into core (unified diff).

#9 Updated by Steffen Kamper about 12 years ago

ok, i uploaded the patch as diff.

The change is very small
unset($theTypeP);
was changed to
$theTypeP =$conf['type'];

Now the old way works as well, but type can be given with conf.
Example:

10 = TEXT
10.value = Standard Link
10.typolink.parameter=3,150

20 = TEXT
20.value = New Link
20.typolink.parameter = 3
20.typolink.type=150

Please check it out.

#10 Updated by Elmar Hinz about 12 years ago

To make the matter complete we should also think of the other values of parameter. At least the "class" attribute could be available as dedicated typolink property. The id attribute is also a candidate.

I don't want to hider the processing of this patch, so I made it an own feature request: http://bugs.typo3.org/view.php?id=6062

The other thingy is the JS popup. But that is more complex and less interesting.

#11 Updated by Dmitry Dulepov almost 8 years ago

  • Category deleted (Communication)
  • Status changed from New to Rejected
  • Target version deleted (0)
  • TYPO3 Version changed from 4.1beta1 to 4.7
  • PHP Version deleted (5)

The issue is too old. I do not think we ever will change that because lots of people use the syntax already.

Closing the issue.

Also available in: Atom PDF