Lately I’ve been working with a client using Tridion in an interesting way. This client manages websites for hundreds of customers, each site being virtually identical. Of course, information such as the customer name, contact info and store hours, along with dozens of other bits has to be customized for each site. One of the ways they manage this unique information led me to a useful discovery on how Template Builder handles large packages. Hopefully by sharing here I can save someone else going on the same wild goose chase I did. Continue reading
No its nothing to do with drugs, or the human genome, or even X-rays (in the context of Tridion at least) – its the marketing lingo for the SDL Tridion Reference Implementation (STRI or TRI) – The Digital Experience Accelerator. This week Bart and I presented a bootcamp on this subject, and all the presentations are publically available
My current project has the ambition to use almost every aspect of the SDL Web suite of products, from plain old Tridion through Audience Manager, SDL Mobile, SmartTarget and finally Campaign Manager – and of course all working via Experience Manager, to provide inline editing and contextual preview.
When looking at how these integrate, all roads lead to… The Ambient Data Framework. SDL provides a number of off-the-shelf cartridges which have varying degrees of mystery – this post aims to clear the mist and describe a little bit more than you get from the docs.
The whole idea of the reference implementation was to make your life (the life of a SDL Tridion developer) easier. But sometimes people make mistakes, and then the end result can be slightly more difficult than it was intended to be.
This blog post is not so much a confession of what I did wrong, but more intended to help you see how easy things can be changed when the tool you use was designed to be simple and modular.
By now I assume that everybody has had a little play with the SDL Tridion Reference Implementation, which means the questions are rising for sure. So let me start with spilling some of the guts of the HTML design and how that is build when you publish.
To start off, the HTML design is a responsive HTML5 design built Bootstrap, this means that you can adjust it to your own likings following the Bootstrap methodology. This includes building the HTML design with Node.js and Grunt, but let’s start off simple.
1. It’s amazing these websites have content like this backed-up and ready to go.
2. They should have been using Tridion, there’s a load of ways in which this could have been prevented.
So whilst I’d like to talk more about the content strategy around number 1 (it’s actually quite brilliant and I wonder who else is already written up), I’m going to be talking more how you can save yourself this embarrassment using SDL Tridion.
Here is a quick story with a lesson learnt: One of our clients was running Tridion 2011SP1 and installed Solr 4.8.1, and asked us to configure SI4T. We banged our heads against this thing until major head trauma occurred. The outcome was not successful. The lesson learnt is that Tridion 2011SP1 is compatible up to Solr 4.7 only. Starting with Solr 4.8 you’ll need to be running Tridion 2013 +. Read on for details…
We all have encountered a publish failure caused by the Tridion http deployer website throwing errors like ‘request entity too large’. Basically, it means that IIS does not accept the uploaded publish package because it’s simply too large.
Luckily, the solution is quite simple, but we recently discovered a small gotcha.
The SDL Tridion Reference Implementation (TRI) comes with out of the box controllers for loading and rendering pure content-based models. However, most web applications need to blend content with data from other sources before rendering. TRI is designed with this in mind, this post introduces the pattern for creating custom controllers which merge CMS managed content with external data.