Backwards compatibility in Content Delivery

A list of changed behavior in Content Delivery.

Storage layer

Replacing the Content Broker configuration file is the Storage Layer configuration file, which configures how and where Content Delivery stores items. The layout of the Content Data Store database has also changed.

Content Delivery automatically transforms your existing Content Broker configuration into a Storage Layer configuration. In most cases, this results in a working Storage Layer configuration that works the same way as your Content Broker configuration. But in some cases, you may need to update the configuration manually. The documentation topics about upgrading Content Delivery explain how.

All binaries become Multimedia Components

Not all binary resources in the Content Manager exist as Multimedia Components. For example, an image embedded in a Format Area in a Component is not a Multimedia Component. However, as of SDL Tridion 2011, publishing an item that contains such a binary resource does result in the creation of a Multimedia Component in the Content Data Store.

In terms of backwards compatibility, this means that a Content Broker query that queries for Multimedia Components may now return more results than in older versions, even if the number of Multimedia Components on the Content Manager side has remained the same.

Change in format of published multivalue metadata fields

Before SDL Tridion 2011, a multivalue metadata field was published to the Content Data Store as a comma-separated string. For example, a multivalue metadata number field with the values 4, 8 and 15 would be stored as a string "4,8,15". As of SDL Tridion 2011, the field values are stored separately and in the correct data type. Following the example, the same field is now stored as three numbers: 4, 8 and 15.

If you are upgrading, this means that your existing multivalue metadata remains stored in its old, comma-separate format, until you republish it. However, any new items containing multivalue metadata that you publish (or old items you republish) will be stored in the new format. Note that the querying functionality has been updated to handle either format.

Custom Senders and Receivers

If you have implemented custom transport by implementing custom Sender and Receiver classes, note the following changes:

  • Receivers no longer exist as of SDL Tridion 2011. Your custom Receiver can no longer be configured in the Content Deployer configuration file, cd_deployer_conf.xml.
  • Senders no longer extend the com.tridion.transport.Sender class, but instead implement the com.tridion.transport.connection.TransportConnector interface.
  • As far as the default Senders are concerned, an XSLT stylesheet automatically changes the Class attributes of these elements in your existing cd_transport_conf.xml to reflect the change. You can also edit the Class attribute by hand to point to the new classes.
  • As far as your own custom Senders are concerned, however, you must reimplement such a Sender, so that it no longer extends com.tridion.transport.Sender, but instead implements com.tridion.transport.connection.TransportConnector.
Content Deployer configuration

The introduction of scalable deployment and the absence of Receivers causes the Content Deployer configuration to change.

Content Delivery automatically transforms your existing Content Deployer configuration into a new one. You can also update your configuration file yourself by hand by applying the XSLT. The documentation topics about upgrading Content Delivery explain how.

New logging framework affects proprietary logging
If you have created custom extensions for a previous version of SDL Tridion that log information to one of the Content Delivery logs, for example, the Content Deployer log, using proprietary logging, such logging will now no longer work, because the logging framework has changed. You will need to upgrade your logging. Refer to Changes to Content Delivery for more information.