You should upgrade your existing Default Templates by opening Template Builder, choosing Tools | Create Default Building Blocks from the menu, and selecting the parent folder for the "Default Templates" folder in the relevant parent Publication. For instance, if your default templates are in "Building Blocks\Templates\Default Templates", you need to choose "...
You could test for specific Schema's for example
if (c.Link.InternalLink.Schema.Title == "Multimedia Schema Title")
This would give you more control if the desired output is different based on Multimedia type (e.g. image, document, video, podcast, etc..)
You could also use
Have you applied the Cumulative Update and the latest hotfixes on top of the installation?
REL DCPs with ASP.NET website were causing issues. Before Web 8, the target language was controlled with the Publication Target and the deployer. In Web 8, publication targets vanished and you could only control the language via the Deployer.
To overcome this issue ...
It seems that the upgrade process does not upgrade the Tridion.SiteEdit.Templating TBB - this is needed for the new tags to be interpreted. You need to manually do this, by opening the TBB, and uploading the upgraded Tridion.SiteEdit.Templating.dll (which can be found in [tridioninstallroot]/bin
It appears the Deployer does not resolve tcdl tags inside out, which means it does not support nested tags unfortunately.
However when looking at your construct I would say that is sounds rather expensive to use a Dynamic Component Presentation, just for a single label value.
I would personally create a labels Component and publish that as a resource ...
Publication target language "REL" means that the deployer is expected not to convert the tcdl tags to JSP custom taglib directives; also see the SDL tridion 2013 online documentation.
Instead these get executed by the PageContentAssembler and the ComponentPresentationAssembler at request time; if you are publishing flat JSP pages from Tridion to your webapp ...
Of course. It's documented too, albeit as more of an outline than a complete walkthrough:
Creating custom TCDL tags
You can find more information in the Content Delivery API documentation, available on this page:
API reference documentation downloads
I am pretty sure you can publish whatever weird content you like and as long as it contains valid TCDL/REL it will be parsed by Content Delivery before returning it via the ComponentPresentationAssembler or Page equivalent. I think the output format of the dynamic template must still be REL though - its no good setting it to Text or XML, putting some TCDL ...
Welcome to Stack Exchange Arnaud.
This page on SDL Live Content (login required) shows the various options you have for linking.
You can achieve the functionality you want with something like this:
<input id="blahblah" rel="something" tridion:href="@@Field.theme.form@@" tridion:targetattribute="rel" />
As far as I have seen, most people place the snippet at the top of the Page Layouts. I understand the point you are making by not embedding the taglib - but out of the box this functionality doesn't exist. I would actually suggest writing a 'language agnostic' TBB that either checks the extension of the page being published, or the output type of the ...
I had the same issue, it didn't work because you need to start a field marker before you start a field value marker. Here a sample
I was following a sample with this content.
Implementation requires the following steps:
To start to create your own custom TCDL tags jar using Maven + IntelliJ IDEA Java development tools to create a Java class that implements the interface com.tridion.tcdl.TagRenderer.
Dependent SDL jar files from [Install-Media]\SDL Web 8.5\Content Delivery\roles\content\standalone\services\content-v2-service
The class com.tridion.tcdl.TagRenderer is available in the cd_dynamic.jar, and it can be found in your SDL Tridion 2013 SP1 installation media under Content Delivery\roles\api\java\lib.
Basically for we website you should have the following jars from the above mentioned location:
Be careful about using REL when publishing ASCX or Java Taglib markup. REL is meant to be used when storing content in the DB, however ASCX and Taglibs need to be published to the filesystem in order for the application server to execute them. Otherwise your ASCX/Taglib markup will simply be rendered as a non executed string of markup.
Also on the syntax ...
I believe this is added by the "Target Group Personalization" TBB, which is part of the Default Finish Actions. It's not meant for Mailings but rather for when you are publishing to the web.
The Mailer service will handle the Target Groups for you, so you can just remove the Default Finish Action from your template.
To my knowledge TCDL Transformers always have been a supported extension point, they came around in R5.3 I guess and were promoted in the beginning. Later the com.tridion.tcdl.TagHandler and com.tridion.tcdl.TagRenderer extension points were added and those appear to be promoted currently through the documentation.
In your case, you want to transform a tag ...
It's all just text. Tridion doesn't care whether it's emitting a head or a body. There's no reason why a component presentation can't be used in the head of a web page.
Regarding TCDL tags, it really doesn't matter whether these originate in the page or the page template, as long as they are correctly present in the output by the time the TCDL is ...
The likelihood of there being much benefit to be had from language-agnostic templates is almost certainly small. Most people would be OK with accepting some amount of language-specific things in their templates. So even if you can manage to achieve this technically (I'm sure you can.), it's probably still more effort than dropping these declarations into the ...
At the Content Delivery side, The page published had below Asp.net kind of Custom Server Control Tag:
ComponentUri="tcm:200-15439" TemplateUri=" tcm:200-78003-32" />
as also checked, the config file cd_deployer_conf.xml was having below properties
To answer my own question, Applying the Hotfix "CD_18.104.22.1686", fixed our <tcdl:comment> tags related and component link resolving issues.
I hope this helps for those who are upgrading from 2013 SP1 to Web 8.5. We need to install the CD_22.214.171.1246 Hotfix after the upgrade.
Schemas/Components with RTF fields should NOT be used for forms, that is not a correct way forward. Whatever you store in he CMS should be content, and a form is not content, it is HTML.
What would be a better solution is to define a Schema that lets you build a form, so that the XML (of the Component) would contain a description of the form so to speak. ...
So to answer my question, I have used approach as provided in Will's article:
So I extended TagRenderer class and provided implementation in doEndTag(). It works now.
public String doEndTag(Tag tag, StringBuffer stringBuffer, TransformContext transformContext, OutputDocument ...
Just to share my idea, In the past, I did implement using the following approach, the files to be served without extension using .NET ASPX website, you can do similar in java also I think.
Using Rewrite rule to remove the extension
Add the extension back to the server
Navigation XML published with URLs extensionless
For the ComponentLinks - created custom ...
I had similar issue in my OOTB setup, In order to fix this issue.
To add the below configuration in the cd_dynamic_conf.xml file in your content service.
Refer to the SDL documentation
I hope it will fix your issue.
If you've created your tcdl tag handlers as discussed in the comments, then make sure you're fetching the component presentations using the ComponentPresentationAssembler not the Factory. The CP Factory does not do any TCDL processing.
The other thing could be that if you are using the Assembler class, use the item ID part of the TCM URI only (middle number)...
If I understand your case correctly, the solution would be to publish the one component with the RTF field that was edited.
Tridion will then automatically publish all the 100 components that use it which in term may trigger publising of all the pages those 100 components may be included on. Or publishing of even more components if any of those 100 ...
Though you won't have access to the Request object itself, you should indeed look at the information available in the claimstore. There's a lot of info in there. As Nick suggests, if you have SDL Mobile then just read the device properties from the claims it populates.
Loads of info and examples if you google for "Ambient Data Framework".