Experience Manager | Albertromkes's Weblog

NuGet Package for DD4T and Experience Manager

January 27, 2014

Today I released a NuGet package for Experience Manager and DD4T (.NET). It allows a developer to easily add the required MarkUp to his (View)Models to enable the inline editing features of the Experience Manager from SDL Tridion. Only use this package if you use the DD4T .NET framework!

Install the package using the package explorer:

     Install-Package DD4T.XPM

The installer automatically adds 2 files to the root of your MVC WebApplication: SiteEdit_config.xml and RegionConfiguration.xml
It also updates the web.config in the ‘Views’ folder to use the DD4T.XPM.XpmWebViewPage as pageBaseType and includes
the DD4T.XPM.HtmlHelpers namespace. After installing the package it’s recommended to restart Visual Studio.

How to use

1) Decorate your Models with the XPM Attributes:

2) Create your model and call the ‘MakeInlineEditable’ method

3) Use the DD4T.XPM helpers to write out the value in the View

That’s all.

Regions

Regions are configured in the file ‘RegionConfiguration.xml’ in the root of your webapplication. This file is added by the NuGet installer. In your view you can use the following call to writeout the region MarkUp:

@XPM.RegionMarkup("PageHeader")

PageHeader is the ID of the region as configured in the RegionConfiguration.

Final notes

The NuGet installer adds the ‘SiteEdit_config.xml’ file to the root of your project. If this file is present, the XPM helper methods will write out the MarkUp (If you called ‘MakeInlineEditable’). If this file is not present, the helpers don’t output the MarkUp. Just the value. Of course you want to control the call to ‘MakeInlineEditable’ based on the environment you’re in: only call this in staging!

This package is developed with .NET 4.5.1 and NuGet version 2.7. I did *not* test it with other .NET frameworks, but I assume it just works.

Happy coding and let me know if you run into issues

2 Comments | DD4T, Experience Manager, Tridion | Permalink
Posted by albertromkes

How to detect if you are in the Editor view in XPM (serverside)

November 22, 2013

While working on an Experience Manager implementation, you often find yourself (at least I do) in the position where you want to change/update the HTML that is generated to be able to edit the content nicely in Experience Manager.
XPM uses HTML-comments to ‘mark’ fields as being editable. The XPM JavaScript draws a border around such a field to highlight it, so the editor knows he can edit this field.
The JavaScript from XPM uses the nearest HTML container (<div>, <h1>, etc) to draw this border.

But often enough the HTML doesn’t fit XPM. The border is drawn to big, too small or doesn’t show up at all because there is no ‘fitting’ HTML element. Or your property doesn’t have a visual representation. Think for instance video parameters, or metadata. Ideally you want your editors to be able to edit these properties in the Experience Manager view.

The most ideal scenario is that the developer somehow can detect if the current page/dcp is rendered in the XPM editor view (and NOT just in the ‘normal’ staging website). Knowing that the current page is rendered in the XPM editor view, allows the developer to add additional HTML to create a more customized user experience for the editor.

There are several solutions to detect the state (in XPM editor view) clientside (using JavaScript), but I haven’t seen a solution for detecting it serverside. And because I needed it in my current project and saw that several people asked for it, I decided to try to build a solution and ‘put it out there’.

This is how it works in a nutshell

XPM loads the staging website in an <iframe>
A GUI extension (1 JavaScript with very few lines of code) is loaded
This JavaScript contains a method that runs just before the page is loaded into the iframe
It updates the <iframe> ‘src’ attribute and adds a querystring parameter calld ‘ActiveInXpm=true’
Another line of code takes care of the ‘Exit’ button functionality (makes sure that you are redirected back to the original URL with a querystring parameter ‘ExitXpmEditor=true’)

I know it’s a *very* simple extension, but for me it does the job. In my (DD4T .NET ) website I check this querystring parameter and that’s how I know that the current page is loaded in the XPM editor view. (Getting the Querystring parameter is a trivial task in every serverside language).

While this works for the first page that is opened in the XPM Editor, it doesn’t work when the editor navigates to the following url while staying in the Experience Manager. This all happens within the <iframe> and I couldn’t find a reliable way to add the querystring parameter to each request. If you do, please let me know 🙂

I solved this by setting the ‘ActiveInXpm’ querystring parameter value in the session. And my code to check if I am in the Editor view, checks the session. If the user exits the XPM editor by clicking on the ‘Exit’ button, the session is emptied and the page looks exactly how it would look like on the live site. The session handling functionality is only added to the staging website, so the live website *never* has to deal with XPM stuff.

I build this for a DD4T .NET site. If you want the code for handling the session, drop me an email and I’ll send it to you.

I’ve uploaded the extension to GitHub.

Let me know what you think or if you have any problems with it.

Some useful links for more information about detecting the XPM state clientside:

1 Comment | Experience Manager, Tridion | Permalink
Posted by albertromkes

Troubleshooting the SDL Tridion Experience Manager with Session Preview

January 24, 2013

In the past week I had the opportunity to install the Experience Manager with Session Preview on a completely
DD4T and SDL Tridion driven website. Configuring the Experience Manager can be quite painful. Especially if you don’t know how Session Preview (exactly) works and if you have no clue where to start and where to look.

In this post I want to give you some hooks and pointers on where to look if things get interesting 🙂
In fact, if you are DESPERATE about why your Session Preview isn’t working, this post is aimed at you!

But first: thanks to Andrew Marchuk, Daniel and Likhan from SDL Tridion for helping me. Without their help I would still be staring at my screen 🙂

Well, let’s start!

(I’ll assume you have a basic understanding of SDL Tridion).

First, read this answer and the comments: http://stackoverflow.com/questions/10788508/continously-update-preview-alert-on-sdl-tridion-ui-2012/10802033#10802033

Meditate it, let it sink, adjust your setup and try again.

Now, if it still doesn’t work, read on:

First, turn of caching for your website. Just to be sure. After you got Session Preview working, turn on caching again and see what happens. But for troubleshooting the Session Preview I recommend to turn of caching completely. Just to be sure…

1. Do a basic sanity check and check the following for your staging website:

– Open the cd_storage_conf.xml from your staging website and ensure that:

The
```
<Wrapper> 
```
element exists! Like this:


<Wrappers>
				<Wrapper Name="SessionWrapper">
					<Timeout>120000</Timeout>
					<Storage Type="persistence" Id="db-session-webservice" dialect="MSSQL"
					Class="com.tridion.storage.persistence.JPADAOFactory">
					<Pool Type="jdbc" Size="5" MonitorInterval="60" 
					IdleTimeout="120" CheckoutTimeout="120" />
					<DataSource Class="com.microsoft.sqlserver.jdbc.SQLServerDataSource">
						<Property Name="serverName" Value="WIN-1CJUK3HE34H" />
						<Property Name="portNumber" Value="1433" />
						<Property Name="databaseName" Value="Tridion_SessionPreview" />
						<Property Name="user" Value="TridionBrokerUser" />
						<Property Name="password" Value="PassWord" />
					</DataSource>
					</Storage>
				</Wrapper>
			</Wrappers>

Of course it should point to your SESSION PREVIEW database! Not to your default, ordinary Broker database.

Check if at least the following StorageBinding is present in the cd_storage_conf.xml of your website:

<StorageBindings>			
                <Bundle src="preview_dao_bundle.xml"/>				          
            </StorageBindings>

Check if you added the AmbientData HttpModule (for .NET Sites!. For java it’s probably a filter) in the web.config of your website:

<add type="Tridion.ContentDelivery.AmbientData.HttpModule" name="AmbientFrameworkModule" preCondition="managedHandler" />

If you are on a website that is NOT COMPLETELY DYNAMIC (so on a website that’s NOT ON DD4T) check if you added the following module in the web.config of your staging website:

<add name="PreviewContentModule" type="Tridion.ContentDelivery.Preview.Web.PreviewContentModule" />

Again: this module is NOT, I repeat NOT necessary if your website is a completely dynamic website. (e.g. retrieves everything from the broker like DD4T). If you still use this module, you will see that clicking on ‘Update Preview’ will generate files on the filesystem! And it will not show you the updated preview!

Open the cd_ambient_conf.xml file of your Staging website and check if the following Cartridge is referenced:
```
<Cartridge File="cd_webservice_preview_cartridge.xml"/>
```

2. Check the following for your OData Webservice: (The one that is used by the Session Preview, so the one you configured as the ‘Content Delivery Endpoint Url’ on your Publication Target)

Copy/paste this ‘Content Delivery Endpoint Url’ and paste it into your browser. (Of course inside the company domain…) and see if it responds.

The url looks like this: http://localhost:73/odata.svc/
You should get a response with a listing of all collections that can be retrieved by this OData endpoint. Something along the lines of this:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<service xml:base="http://localhost:73/odata.svc/" xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
    <workspace>
        <atom:title>Default</atom:title>
        <collection href="Binaries">
            <atom:title>Binaries</atom:title>
        </collection>
        <collection href="BinaryVariants">
            <atom:title>BinaryVariants</atom:title>
        </collection>
  	....
	....
    </workspace>
</service>

Open the cd_storage_conf.xml of your OData webservice and ensure that:

The Wrapper tag is there and is pointing to your SESSION PREVIEW database. So not to your regular Broker Database!

The StorageBinding with the preview dao bundle is there. Like this:

<StorageBindings>			
                <Bundle src="preview_dao_bundle.xml"/>				          
            </StorageBindings>

Open the cd_ambient_conf of your OData webservice and verify that:
- The preview Cartridge is there. Like this:
```
<Cartridge File="cd_webservice_preview_cartridge.xml"/>
```

Now, do an IISReset on your website and for your OData webservice. This makes sure that your changes to the various configuration files are used when the Content Delivery Instance boots up the first time. DO NOT SKIP THIS STEP! In case you are still in doubt: DO NOT SKIP THIS STEP! (Sorry for shouting)

Now, hit ‘Update Preview’ again. If it is still not working for whatever reason keep reading:

1. Open the logback.xml file of your Staging website, and set the loglevel to ‘VERBOSE’.
2. Open the logback.xml file of your OData webservice and set the loglevel to ‘VERBOSE’.
3. Clear both logfiles! (So you have a fresh start)
4. Clear the ‘Tridion’, ‘Tridion Content Manager’ and ‘Application’ Windows Eventlogs on the Content Manager Server
5. Clear the ‘Application’ Windows Eventlog on the Staging WebSite server
6. Clear the ‘Application’ Windows Eventlog on the Odata webservice server

Do an IISReset (You edited the logback.xml file, so this is necessary!)

Now, hit ‘Update Preview’ again and check out the logfiles in this order:

cd_core.log of your Staging website
-> Anything unusual? Especially error’s and warnings with regard to the Ambient Data Framework are important! Take them seriously and double check the cd_ambient_conf.xml and the cd_storage_conf.xml of your staging Website. Also, check if all HttpModules and/filters are present in the Web.config of your website! (See above)
cd_core.log of your OData website. If this file is (almost) empty that means that the ‘Update Preview’ request NEVER reached the OData webservice. This could be due to:
– Network issues: are the IIS Bindings of the OData webservice correct?
– Can you connect to the OData webservice using your browser?
– Is your publication target pointing to the correct Content Delivery Endpoint Url (your OData webservice)?
If there is data in the cd_core.log of your OData webservice, check to see if there are error’s or unusual statements.
- If you search for your adjusted content do you see it? If so, this means that your changed content is correctly send to the OData webservice. If not, that means that your staging website cannot connect to the OData webservice. Again: Check IIS settings and network settings.
Open the Session Preview Database using SQL Server Management Studio, and open the table ‘Component Presentations’. After you hit ‘Update Preview’, you SHOULD see something added to this table. If not: check if you referenced the correct Session Preview Broker Database in BOTH of your Wrappers. (In the cd_storage_conf.xml of your Website and in the cd_storage_conf.xml of your OData webservice!)

If you see an HTTP error 400 BAD REQUEST after you click on ‘Update Preview’ check the following:

Open the Windows EventLog ‘Tridion Content Manager’ on the Content Manager server and check if you see the same error here.

If so, try the following:

Stop the TcmServiceHost windows service on the Content Manager Server. (Be careful, The SDL Tridion Content Manager stops working now!)
Next, browse to the SDL Tridion install directory\bin with the command prompt and start the TcmServiceHost.exe with the -debug command. Like this:

TcmServiceHost.exe -debug

Now, open Fiddler on the Content Manager server, apply a filter to show only traffic from the TcmServiceHost and hit ‘Update Preview’ again. Now you have the request and you can inspect it to see if there’s anything unusual. E.g. the Content-Lenght is 0. That’s weird, because that means no data was send!

The last resort consist of tracing everything related to the OData webservice. If everything above failed, do the following:

Open the Web.config of the OData webservice and add the following code:

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.ServiceModel" switchValue="All">
        <listeners>
          <add name="TraceListeners" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\Temp\trace.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>

Adjust the ‘initializeData’ path to a path of your choosing.

Now, hit ‘Update Preview’ again, and after it’s finished, open the trace by double-clicking on it. (If you don’t have the tracetool, download it here)

Find he first red colored entry, and inspect the error message. In my case the ‘maxReceivedMessageSize’ of the OData webservice was too small.

You can adjust this setting in the Web.config of the OData webservice. Here is an example of the updated part of the Web.config:

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="True" />
    <behaviors>
      <endpointBehaviors>
        <behavior name="webHttp" >
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
	  <!-- HTTP support. In case of HTTPS these services have to be commented. -->	
      <service name="Tridion.ContentDelivery.Webservice.ODataService">
        <endpoint  behaviorConfiguration="webHttp" binding="webHttpBinding" bindingConfiguration="AdustedBindingConfiguration" contract="Tridion.ContentDelivery.Webservice.IODataService" />
      </service>
      <service name="Tridion.ContentDelivery.Webservice.LinkingService">
        <endpoint behaviorConfiguration="webHttp" binding="webHttpBinding" contract="Tridion.ContentDelivery.Webservice.Ilinking" />
      </service>
	  <service name="Tridion.ContentDelivery.Webservice.AccessTokenService">
		<endpoint behaviorConfiguration="webHttp" binding="webHttpBinding" contract="Tridion.ContentDelivery.Webservice.IOAuth2AccessToken" />
	  </service>
    </services>
	<!-- In case of HTTPS support uncomment this block.
	-->
	<bindings>     	  
		<webHttpBinding>      
			<binding name="AdustedBindingConfiguration" maxReceivedMessageSize="2097152000" maxBufferSize="2097152000">
				<readerQuotas maxArrayLength="81920" maxBytesPerRead="5120" maxDepth="32" maxNameTableCharCount="81920" maxStringContentLength="2097152" />
			</binding>
	    </webHttpBinding>
    </bindings>
	
	
  </system.serviceModel>

Note that ‘maxReceivedMessageSize’ and ‘maxBufferSize’ should be the same!

Don’t forget to remove this settings once you resolved all your issues!

Phew! I *really* hope your Session Preview service is now working properly.
If this isn’t the case consider asking it on StackOverflow (and while you’re there, consider committing to the SDL Tridion Exchange Proposal)
The community is really helpful and very knowledgeable. Of course you can also open a support ticket with Customer Support.

Have fun!

3 Comments | Content Delivery, DD4T, Experience Manager, MVC3, Tridion | Permalink
Posted by albertromkes

Albertromkes's Weblog