[TYPO3-dam] DAM, RTE, <media> and ts_links

[Thomas Oppelt]

here it happens:
$linktxt = $this->cObj->stdWrap($conf['tag.']['value'], $conf['tag.']);

$linktxt contains then link to the page and after that you get in
return $this->cObj->wrap($res.$linktxt.'</a>', $conf['wrap']);
a nested link to the page wrapped by the correct file link.

simply debug $linktxt and $conf in tx_dam_tsfemediatag->main and you see 
what i mean.

Thomas Oppelt schrieb:
> debug addinfo: typoLink within class.tx_dam_tsfemediatag.php returns the 
> the file links correctly, so there seems to be an conflict after that 
> processing.
> 
> regards
> tom
> 
> 
> Thomas Oppelt schrieb:
>> Forgot the settings of course:
>>
>> NO realurl!
>> T3 4.1finalcore
>> DAM beta5
>>
>> cheers
>> tom
>>
>>
>> Thomas Oppelt schrieb:
>>> Hi Ben, hi René,
>>>
>>> i don't think this behaviour is a realUrl related bug; i don't no 
>>> what happens but here is a way to reproduce:
>>> if you link to a tx_dam record from tt_content rte field and the uid 
>>> of the tx_dam records is the same as of an existing page, the link in 
>>> FE gets a link to that page not to the tx_dam related file.
>>>
>>> If u could confirm this, i can add it to bugtracker.
>>>
>>> cheers
>>> tom
>>>
>>>
>>>
>>>
>>> ben van 't ende [netcreators] schrieb:
>>>> Hi,
>>>>
>>>> This feature works really great with the nice title attribute 
>>>> showing details of
>>>> the file. I do not know where the <media> tag fits in here. I do not 
>>>> see a
>>>> <media> tag anywhere.
>>>>
>>>> Anyway i found a strange bug with realurl. If you link to a dam 
>>>> record that has
>>>> the same id as an existing page the link to the file is interpreted 
>>>> as a link to
>>>> the page with that id and not to the file itself. So an image would 
>>>> for instance
>>>> link to my graffity page instead of to that file. this has something 
>>>> to do with
>>>> realurl
>>>>
>>>> you can see this here: http://ben.vantende.net/t3/dam/
>>>>
>>>> the first link is a link to an image, but is actually converted to a 
>>>> page link.
>>>> the second one is ok.
>>>>
>>>> weird isn't it?
>>>>
>>>> gRTz
>>>>
>>>> ben
>>>>
>>>>
>>>>
>>>>
>>>> René Fritz wrote:
>>>>> I would like to discuss the RTE linking solution included in 
>>>>> 1.1beta05.
>>>>>
>>>>> This seems to be one of the most wanted features, so I would like 
>>>>> to get some feedback if it's working as expected.
>>>>>
>>>>> For detailed information have a look in the manual of the dam 
>>>>> extension, section "RTE and <media> tag".
>>>>>
>>>>>
>>>>> What is it all about?
>>>>>
>>>>> The RTE just generates <a> tags with a reference to a linked file. 
>>>>> To make use of DAM features, this tag needs to be converted when 
>>>>> saving the content to the database. (Such things are configured 
>>>>> with TSconfig 'RTE.default.proc...')
>>>>> In FE that special tag needs to be rendered as an <a> tag like 
>>>>> TYPO3 does with <link> tags.
>>>>>
>>>>>
>>>>> <media> vs <link>
>>>>>
>>>>> First some background information:
>>>>> I thought a good solution would be to use the known <link> tag 
>>>>> which would look like that for a link to a dam asset:
>>>>> <link dam:243>Link text</link>
>>>>>
>>>>> The main disadvantage would have been that the RTE processing rule 
>>>>> "ts_links" needs to be overridden with an own version. ts_links is 
>>>>> called when the shortcut ts_css is used for example:
>>>>> RTE.default.proc.overruleMode = ts_css
>>>>>
>>>>> So I decided to use a new tag <media>. For FE rendering an own 
>>>>> .tags.media parseFunc can be registered and for RTE processing the 
>>>>> system rule ts_links does not need to be overridden.
>>>>>
>>>>> The problem is that the RTE generates <a> tags and however both 
>>>>> ts_links and the <media> processing does not work at the same time. 
>>>>> In the end I had to override ts_links (what I wanted to avoid) to 
>>>>> make <a> to <media> tag processing work.
>>>>>
>>>>> The conclusion is, in principle the format <link dam:243> could be 
>>>>> implemented because I override ts_links anyway. But I think the new 
>>>>> <media> tag might be more flexible in the future.
>>>>>
>>>>>
>>>>> <media> parameters
>>>>>
>>>>> The media tag use the same parameters as the link tag. The question 
>>>>> is, is that a good decision, or should another scheme be used for 
>>>>> the media tag? The disadvantage of the link tag is that parameters 
>>>>> have to be in the right order. A naming scheme for the paramters 
>>>>> might be more flexible.
>>>>>
>>>>>
>>>>> What do you think
>>>>>
>>>>> René
>>>>>
>>>>
>>>>