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.
After writing my post about having fun with experience manager last year, I think it is time for a small update. This time I’ll keep it short, but we will have even more fun with XPM!
Today’s story about the People website publishing an obituary of Kirk Douglas death (he’s still very much alive) made me instantly think of two things:
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.
Today Bart Koopman from SDL and Mihai Cădariu from Mihai Consulting presented two really interesting topics at today’s November SDL Tridion Webinar:
- The Tridion Reference Implementation
- Cache implementation with and without DD4T
If you missed the webinar the resources are available after the jump.
The duplicate binary error on Tridion one is a common and often annoying issue. If you haven’t yet had the pleasure of running across it, Chris Summers discusses it at length here. Today I found a new (to me) twist on the issue.
We were trying to replace some old binaries, but kept getting this error. The reason was that even though we had unpublished the old binaries, Tridion was still showing them as published to a number of old, out of service publication targets. Unfortunately, the HTTPS upload URLs for these targets were shut down long ago, meaning Tridion could never successfully unpublish our binaries from these targets. Or could it?
Since the servers these targets point to no longer exist, it wasn’t important that Tridion actually remove the files, only that it thought it had. To trick Tridion into believing this we temporarily replaced the HTTPS upload URL with our current working URL (where the files were already unpublished) and added our current target type to each target. Now all we had to do was unpublish our binaries again and voila, Where Used shows Tridion has no references to binaries on old targets and we have no more duplicate binary error.
Of course, with new versions of Tridion the old publishing targets will no longer pose a problem thanks to the ability to decommission a publishing target, discussed by Bart Koopman here. For those still working with older versions this simple trick may be useful for when you need to unpublish from a dead publishing target.
The MVPs got to grips with the SDL Tridion Reference implementation (TRI ) while on the yearly retreat in Portugal a couple of weeks back. In between getting people up and running with this new SDL Tridion product, I knocked up a Controller implementation to pull content/data as JSON from the web application.