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:Â
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.
Today I had to write a small piece of code to generate a local file system based on the structure of a given Tridion folder. Â It’s a throwaway bit of code but I thought it might be useful to someone out there at some point in their lives (or myself in the future), so i figured why not share it here?
About five years ago I wrote a blog entitled the “The Fifth SDL Tridion Environment†in which I explored the need for additional development environments. SDL solved my frustration in part, by creating the MVP program, which carries the great benefit of a special MVP license for Tridion. The license can be used for personal research etc., but not on customer or partner projects. So fast forwarding to 2014, independent Tridion developers are in much the same boat of needing to use a customer’s license installed on a customer’s server.
A lot has changed since 2009, and I am now on a project where we have a globally distributed army of developers (many of which have no knowledge of Tridion or any other CMS) working on a Tridion project from their own machines without the need to buy additional licenses or provide training to each developer. SDL may not like this idea (sorry SDL), but the approach I am about to share has drastically increased the productivity of our team, and has removed many of the ‘barriers to entry’ that so many of SDL’s customers and prospects have complained about in the past. I really believe that this is a model that could significantly increase the acceptance of Tridion to the broader developer community. Continue reading
One of the goals of the SDL Tridion Reference Implementation (TRI) is to provide an example web application for which ASP.NET MVC application developers can develop functionality without deep understanding of the underlying CMS. A key difference between a ‘classic’ MVC app and a CMS managed one is how URLs are managed and the impact this has on routing requests to controllers. In this article I dig into the mechanism used in the TRI to explain how it fits together.
In a DD4T website, you can serve images from the broker using the BinaryDistributionModule. This is a module that intercepts requests for any images, and then queries the broker for published images, and serves them (I will talk about this more in-depth in a future post).
However, this might give some problems if you also have static images.
Released last week – the first step on a path to lower the barriers (time, cost, knowledge, lack of standardization) of implementing SDL Tridion. In this post I aim to give a short introduction, by highlighting what you should and should not expect from the Reference Implementation.