Documentation Center

Backwards compatibility in Content Manager

The following is a list of changed behavior in Content Manager.

Workflow

In the past, if an item to be previewed or published was in workflow and had not yet obtained minimum approval status, the last checked-in version of the item would be shown in preview or published, regardless of that version's approval status. As of SDL Tridion 2013 SP1, the last checked-in version must have minimum approval status, and Content Manager throws an exception if this is not the case.

Conceivably, the setup that gives rise to this exception may exist in your implementation. If this is the case, we recommend that you revise your Workflow Process Definitions to ensure that items have a minimum approval status by the time the Workflow Process finishes. Alternatively, if you have a pressing reason to do so, you can instruct Content Manager to continue disregarding the approval status of the last checked-in version, like it did before, by doing the following:
  1. On the Content Manager server, go to %TRIDION_HOME%\config\.
  2. Open the Content Manager configuration file Tridion.ContentManager.config for editing.
  3. In the file, find the element called rendering.
  4. Add a new attribute legacyApprovalStatusCheck to the element, and set this attribute to true.
  5. Save and close Tridion.ContentManager.config.
TOM API and TOM-based Event System

It is not possible to use data in .NET that was obtained using MS XML (which is the case when using the TOM API or the old TOM-based Event System). Microsoft Knowledge Base article 815112 explains this issue: http://support.microsoft.com/default.aspx?kbid=815112

Core Service API
Service contract version numberSupports endpoints introduced inIntroduced in
2010SDL Tridion 2011SDL Tridion 2011
2011SDL Tridion 2011, SDL Tridion 2011 SP1SDL Tridion 2011 SP1
2012SDL Tridion 2011 SP1, SDL Tridion 2013SDL Tridion 2013
2013SDL Tridion 2011 SP1, SDL Tridion 2013, SDL Tridion 2013 SP1SDL Tridion 2013 SP1

The new Core Service API introduced in the 2013 release has the following impact on existing users:

  • The Core Service endpoint for SDL Tridion 2011 (which is identified as the 2010 endpoint) has been dropped. As of SDL Tridion 2013, the only old Core Service endpoints supported are the 2011 endpoint (for SDL Tridion 2011 SP1) and the 2012 endpoint (for SDL Tridion 2013).
  • If you were using the 2010 endpoint, you must update and recompile your code, preferably to call the new 2012 endpoint.
  • Your existing calls to the 2011 Core Service endpoint, using the 2011 SP1 API, will still work and behave as before in SDL Tridion 2013, but to benefit from the functionality introduced in SDL Tridion 2013 and later releases, you must of course update and recompile your code to call the new 2012 endpoint.
TOM.NET API

Compared to the 2009 SP1 TOM.NET API, the new TOM.NET API introduced in the 2011 release is different in the following ways (these changes also impact TOM and the Core Service):

Failed impersonation now throws exception

Previously, if a user who was not configured as an impersonation user tried to impersonate another user, the user would fall back to itself. As of the 2011 release, this scenario results in an exception being thrown.

Trusted read-only mode during rendering and publishing

The new TOM.NET API is still functionally a read-only interface during rendering and publishing. That is, you cannot create, update or delete Content Manager items while your Template is executing. This behavior also applies to the now deprecated TOM API, meaning that if you have Templates that use the TOM API and perform write actions, these Templates will now fail.

If you do want your old TOM templates to be able to write to the Content Manager, you can configure the Content Manager to allow writing during rendering and publishing. SDL strongly recommends against this practice as it compromises your security. You enable Templates to write to the Content Manager as by opening the Tridion Content Manager configuration file Tridion.ContentManager.config (located in the config subfolder of the Tridion Content Manager root location), and adding an attribute allowWriteOperationsInTemplates, set to true, to the element called tridion.contentmanager.security.

XML validation

Earlier releases validated Tridion objects against the system schema, resulting in a single error code 0x80040327 (TcmErrorInvalidXML) if validation went wrong. In the new release, old XML is converted to the SDL Tridion 2011 format using an XSLT stylesheet, deserialized and run against a number of business rules. As a result, both the error code returned will be different and the error message will be much more specific.

API delta

In addition, the TOM.NET API classes and methods that were already present in the 2009 and 2009 SP1 releases have changed. Refer to TOM.NET API delta compared to SDL Tridion 2009 (SP1) for details.

New LDAP implementation

The new implementation of LDAP integration in the Content Manager involves the following changes:

  • The ISAPI filter is no longer needed and therefore no longer configurable in the MMC Snap-in.
  • It is now possible to configure multiple Directory Services. The default Directory Service (used as a fallback for unqualified users) is the first one configured.
  • It is now possible to specify the domain separator character.
  • Empty passwords are no longer supported
  • An Active Directory can no longer be configured in the MMC Snap-in separately. To add an Active Directory, simply add a Directory Service, because the Content Manager considers them the same.
  • There is also no longer an option to enable Directory Services; Directory Services are automatically enabled as soon as one or more are configured.
Combined LDAP and Active Directory authentication

SDL strongly recommends against authentication through LDAP and through Active Directory using a single machine. If you currently have such a setup running, submit a support ticket to SDL Customer Support.

Changes in default Workflow Process Definitions

In previous releases of SDL Tridion, any new Publication you created included the default Workflow Process Definitions "Page Process" and "Component Process".

This is now no longer the case: new Publications do not get a default "Page Process" or "Component Process". In addition, both existing Publications and new Publications get a new default Process Definition called "Task Process".

Your existing Page Process or Component Process items that are already in use continue working, but if you are upgrading from a release that is earlier than SDL Tridion 2011, you still need to make a change to these default Process Definitions.

Security for workflow tightened

Because of a more stringent way of applying security to workflow, you might find that some workflow operations now require additional security clearance.

Existing Publications do not automatically get new Default Template items

As part of the deprecation of old VBScript/JScript templating in favor of new Compound Templating, new Publications created in the Content Manager no longer contain a Default Component Template, Default Page Template and Default Template Building Block, written in VBScript, in the Building Blocks folder. Instead, a new Publication contains a Folder Building Blocks\Default Templates\, containing a minimal set of the default modular templating items that SDL Tridion ships with.

For existing Publications, however, neither the Folder nor the items are added during upgrade. This is because such actions could create a conflict. As a result, if you intend to start using modular templating in an existing Publication, you must first create these default items from Template Builder.

New search engine

The new search engine, based on Lucene technology, may result in different search results to your search queriers than the old search engine. Specifically, operator precedence (in search queries such as a AND b OR c) is different in Lucene than in the old Verity search engine. You can work around the problem by using brackets to indicate precedence.

Preservation of whitespace in XML

In various instances in Content Manager, the processing of XML was changed to preserve whitespace where previously, Content Manager removed it. Whitespace is now preserved as text nodes. This means that your code might break if it expected to find no text nodes, only XML elements. To fix this, rewrite your code to check which XML children are elements and which are text nodes, and only process elements.

For example, if your breaking code looped through all child nodes using the following foreach command:

foreach (XmlNode childNode in node.ChildNodes)

Replace this code to select only child elements from the child nodes:

foreach (XmlElement childElement in node.SelectNodes("*"))