Upgrading from SiteEdit to Experience Manager

During a recent upgrade project, we were in the situation where we had to upgrade several existing Tridion implementations that made use of SiteEdit and had to move over to Experience Manager. In this post I will try to summarize my experiences.

As with most Tridion version upgrades, the client expects the Template implementation to remain working as is, as long as the API remains backwards compatible with the version already in use. However, XPM is basically a completely new product, and using its full powerful potential means that additional implementation steps have to be performed. More specifically, if you want to use “Session Preview” in XPM, be prepared for additional implementation in your Staging website application.

Upgrading vbScript Templates.

First of all, script is deprecated. This should be the ultimate time to move over to a more recent technology and methodology. My advice will always be: stop using vbScript Templates!
However, companies may have hundreds of vbScript Templates that have never been touched since creation, and “just work”. Reimplementing them, just because one wants to move to XPM, will make the transition quite a costly one. Yes, of course there are many more benefits that will be enjoyed by moving away from vbScript Templates, but when dealing with a limited upgrade budget some companies will choose to leave the Template implementation as much as-is as possible. Running existing vbScript implementations on SDL Tridion 2013 SP1 with the legacy pack enabled can be challenging though. More about that in a future post.

vbScript Templates and SiteEdit 1.3

For a minimal upgrade as-is approach, leave the ComponentTemplates untouched, and only change the PageTemplates (or TemplateBuildingBlocks) where the SiteEdit Finalization call is located. SiteEdit 1.3 code to enable SiteEdit on the Page can best be replaced for SiteEdit 2 (2009 etc) code, as this will limit the unwanted settings meant for SiteEdit 1.3 which are now managed in the CMS GUI for use with XPM. Finish by writing out the bootstrap.js URL for your CMS.

<!-- Old SiteEdit 1.3 code -->
[%
   Call SiteEdit.Init(CMS_HOST_NAME, Page, TargetTypeID)
   WriteOut SiteEdit.Finalize()
%]
<!-- New code using SiteEdit2 -->
[%
   SiteEdit2.PageID = Page.ID
   SiteEdit2.PageVersion = Page.Info.Version
   SiteEdit2.TargetTypeID = TargetTypeID
   WriteOut SiteEdit2.Finalize()
%]
<!-- Activate XPM Button -->
<script src="http://[% WriteOut CMS_HOST_NAME %]/WebUI/Editors/SiteEdit/Views/Bootstrap/Bootstrap.aspx?mode=js" type="text/javascript" language="javascript" defer="defer" id="tridion.siteedit">
</script>

Note that SiteEdit 1.3 output for inline editing is not compliant with W3C standards (invalid use of HTML attributes), so it would make sense to upgrade the ComponentTemplates too.

vbScript Templates and SiteEdit 2

For a minimal upgrade as-is approach, leave the ComponentTemplates untouched, and only change the PageTemplates (or TemplateBuildingBlocks) where the SiteEdit Finalization call is located: add the bootstrap.js URL for your CMS.

<!-- SiteEdit2 -->
[%
   SiteEdit2.PageID = Page.ID
   SiteEdit2.PageVersion = Page.Info.Version
   SiteEdit2.TargetTypeID = TargetTypeID
   WriteOut SiteEdit2.Finalize()
%]
<!-- Activate XPM Button -->
<script src="http://[% WriteOut CMS_HOST_NAME %]/WebUI/Editors/SiteEdit/Views/Bootstrap/Bootstrap.aspx?mode=js" type="text/javascript" language="javascript" defer="defer" id="tridion.siteedit">
</script>

Upgrading Compound Templates with SiteEdit2

Upgrading a SiteEdit2 Compound Template implementation is easy when standard SiteEdit2 Compound TemplateBuildingBlocks have been used:

  1. Import new XPM TemplateBuildingBlocks using TemplateBuilder
  2. Create a Compound TBB for “Enable Inline Editing for Page” and one for “Enable Inline Editing for Content”: Set the configuration options in the parameter settings, and reuse them for all your Compound Templates. These TBB’s use the XPM TBB’s that were imported in the previous step
  3. Replace your SiteEdit2 TBB’s by the Compound TBB’s created in step 2, you can do this in TemplateBuilder if you want, when dealing with a lot of Templates, you might want to use webdav and some tools for “global search & replace”
  4. Enable inline editing for each Field in the corresponding Content Schema in the CMS
  5. Enable inline Editing for your Staging PublicationTarget in the CMS GUI
  6. Add your Staging url(s) to your Staging PublicationTarget in the CMS GUI

Dreamweaver TemplateBuildingBlocks

Optionally, modify your Dreamweaver Templates for full support for MultiValue Fields in the XPM GUI:

@@FieldStartMarker("BusinessPartners")@@
  <!-- TemplateBeginRepeat name="BusinessPartners.Fields" -->
    @@FieldValueStartMarker(TemplateRepeatIndex)@@
      @@GetFieldValue("BusinessPartners", TemplateRepeatIndex)@@
    @@FieldValueEndMarker()@@
  <!-- TemplateEndRepeat -->
@@FieldEndMarker()@@

See more examples

Razor TemplateBuildingBlocks

Optionally, modify your Razor Templates for full support for MultiValue Fields in the XPM GUI. The new syntax is not supported yet, but can easily be added by a custom helper TBB.

Content Delivery Environment implementation

Preventing 404 in XPM GUI

You may encounter 404 errors in the XPM GUI, when trying to edit a field of a Component. This can be solved by creating a static file named se_blank.html in the document root of your Staging website/application.

Ambient Data Framework

One of the great new features of XPM is “Session Preview”, which basically allows you to see your changes on Staging, without the need to publish to Staging. To have this enabled for your existing Staging website/application, you will need to start using the SDL Tridion Ambient Data Framework (ADF) in your Staging web application. This means that Staging must run on an Application Server, be aware of this if your current Staging sites (partly) run on webservers.

When implementing the ADF, it will only be implemented on the Staging target, not on live. This could result in 2 distinct applications (or branches), one with and one without the ADF implemented. Introducing the ADF to your Java application will also introduce dependencies to the frameworks (and versions) used by the Tridion CDE jars, for instance Spring and Hibernate: be aware of potential version conflicts when introducing ADF to your existing Java applications.

When your web application does some routing/redirecting magic, the ADF framework may be unable to map URLs to Pages in the broker. This is for instance the case when sub-domains are used. In that case additional implementation is required: a custom ADF Claim processor may be needed to map Staging urls to the urls that are known by the broker (see: Customized Experience Manager Web site extension). This is comparable to implementing a PublicationResolver to deal with url routing in DD4T (see: dd4t.web publication resolving).

How about no Session Preview?

Well, it is possible of course. What will remain is SiteEdit functionality in a new XPM GUI. The Content Editor will have to commit changes to the CMS, and they will be published to Staging. You may want to disable the “Update Preview” button in the GUI, it can be done in the CMS GUI, Settings section.
(see also: What needs to be configured (on CM) when removing session preview for Experience Manager?)

Posted in SDL Tridion Tagged with: , ,