DXA’s Golden Image Rule

DXA is a reference Tridion implementation that contains tons of pre-configured rules and automated features.  These features reduce the time to market for simple Tridion-backed websites.   However, there are a few “features” in DXA which are not defined in the documentation and may not be desirable for all sites.  One of these “features” is the fact that DXA will crop any image rendered in an RTF to the Golden Ratio of 1.62.

Some of you might have completed DXA implementations without even realizing that DXA does this, and indeed it took us months before anyone noticed that DXA forces a width/height ratio on images in RTF fields.  We recently attempted to render a tall image only to find that most of the image was cropped away.  We assumed it was a bug that we had introduced somehow but after some digging we found out that this is the desired default DXA behavior (as explained here by Will Price) https://tridion.stackexchange.com/questions/13643/applying-advanced-styles-to-embedded-rtf-images-in-dxa.  All images imbedded into RTF fields are automatically cropped to a ratio of 1.62 (the golden ratio) despite any attributes you give them in the RTF editor.  This was undesirable for our implementation so we decided to fix it.

Luckily, the fix is easy.  To fix this you will have to locate the BaseMediaHelper class within the DXA framework source code.Untitled2

After that, you will need to create a new project with a CustomizedBaseMediaHelper class.  You can then copy all of the guts for this class from the default DXA one but you will need to make one change: the DefaultMediaAspect variable should be set to 0 instead of 1.62.


Once you compile the new CustomBaseMediaHelper class and place your new DLL in the bin of your DXA webapp, you just have to point the app to it.

To have the app use your new CustomBaseMediaHelper class you will need to update the following in your Unity.config file:

  1. A reference to your new assembly and namespace needs to be added at the top of the config file.
  2. The <type> element with the attribute type=”IMediaHelper” should be changed to point to the name of your new class instead of the old one.

You may need to refresh your application pool to see the change take effect.  Once all of that is done, your images will be free to fill any dimensions that they please.

Web 8, SI4T and Storage Extensions

The release of SDL Web 8 has seen the biggest overhaul of the Content Delivery stack since Tridion 2011 and much of it has been applauded much, as the new Micro Services architecture and with it the ability to scale, deploy and be distributed in general, gives many more architectural options than just having an API in your web application connecting you to a database.

Building this while guaranteeing backward compatibility with the Tridion 2011/2013 CD stack is more than a major task and I for one am happy to see that that feat was pulled off really well. That is, unless you have overridden the default DAOFactory classes in your Deployer Storage Extensions, as is the case with the SI4T Storage Extensions. When testing SI4T with Web 8, it turned out that loading of the SI4T Storage Extension did not work in every scenario. This has to do with the subtler points of Spring Bean Class loading.

Continue reading

Pushing the limits on Template Builder’s estimates

­­­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

Whitespace in SDL Tridion SP1 XML

Before reading this, and getting too alarmed, this blog of caution really only applies to those who use XSLT templates (either using the XSLT Mediator or traditional XSLT Component Templates). Although it may have a wider impact that I am not aware of.

I just upgraded a client implementation to 2011 SP1, and mysteriously some of my components were failing to publish. At first this seemed to be a template issue, but on further inspection it became apparent that components that had been made before the SP1 upgrade were fine, and those create or edited after the upgrade were failing.

In one of our XSLT Template Building Blocks, we essentially copy the XML of the Component in order to make all the data available to the presentation code. In addition to copying the nodes, we also add some additional attributes.

    <image xlink:type="simple" xlink:href="tcm:0-114344" xlink:title="ross" xmlns:xlink="http://www.w3.org/1999/xlink"/>

Gets transformed by our template to

<image Orientation="portrait" Photographer="- Not applicable" Illustrator="">
    <caption>Some Caption</caption>
    <image type="pub148w" height="148" width="60" src="tcm:417-117248" uri="tcm:417-117248" /
    <image type="pubArticleFull" height="480" width="640" src="tcm:417-117248" uri="tcm:417-117248"/>

This was working perfectly from version 5.3 up until 2011 GA. However we discover that the XML of components saved using SDL Tridion 2011 had changed


<image><image xlink:type="simple" xlink:href="tcm:0-114344" xlink:title="ross" xmlns:xlink="http://www.w3.org/1999/xlink" /></image>

<image>       <image xlink:type="simple" xlink:href="tcm:0-114344" xlink:title="ross" xmlns:xlink="http://www.w3.org/1999/xlink" />       </image>

The additional whitespace was being added to the image node by my XSLT template, and it was preventing me from adding the Orientation, Photographer and Illustrator attributes to the element (you can not add attributes with XSLT to a node after adding text, whitespace or nodes)

To get around this I have added <xsl:strip-space elements=”*”/> to the top of my XSLT which fixes our problem, but it does mean we now need to validate the output of all our templates to make sure we are not stripping out any whitespace that we actually need.

Lesson of the day: Never write an XSLT thinking whitespace is irrelevant.

You decide whether you think this is a bug or not, but in the meantime, I hope this post might help you debug any XML related woes you stumble upon after upgrading to SP1.

Fixing GUI issues after upgrading to SDL Tridion 2011 SP1

I have just finished upgrading a client’s SDL Tridion 2011 GA instance to SP1, and on the whole the experience was fairly painless with the exception of my post on publishing permissions and some minor issues with the Content Manager Explorer (CME).

I believe my client was one of the earlier adopters of SDL Tridion 2011 GA, and we applied a number of early hotfixes to the GA instances. My guess is that we may have installed some “unapproved” hot fixes which we not versioned correctly or that in a debugging effort I accidentally saved some files whilst hunting for a problem.

This appears to be the root of the latest problems we have seen. In an effort to not mess up any customized code or configurations, the SP1 installer does not update any files with unknown versions. In our case this meant that several files were not updated, and the CME was not functioning correctly (several items were not loading or saving, and various JS errors were appearing) even though the installer appeared to have completed successfully.

Continue reading