You're probably missing the tagbundle configuration in the cd_deployer_conf.xml
You need to add the following to the <TCDLEngine> section of the deployer:
<TagBundle Resource="com/tridion/smarttarget/tcdl/tagbundle.xml" />
More information here.
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 ...
Just checking and comparing with my (working) ST box.
Do you have a Processors configured in the deployer's cd_deployer_conf.xml?
<Processor Action="Deploy" Class="com.tridion.deployer.Processor" Phase="post-transaction">
<Module Type="SmartTargetDeploy" Class="com.tridion.smarttarget.deployer.FredhopperDeployerModule">
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
As mentioned above, The
registers handlers for the smarttarget tcdl tags in the deployer, without it the deployer will ignore the 'unknown' tags
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
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 ...
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" />
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.
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 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.
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:
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 ...
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 ...
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. ...
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 ...
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.
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
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 ...