If you go to the SDL Tridion dashboard and then choose the Settings, under Inline Editing you will find the Session Preview Settings. Here you can disable the Session preview, which will disable the Update preview button in the Experience Manager view.
I am going to answer my own question, as I got a lot of additional information from other sources and think its helpful to summarize it here.
It is not at all possible to use Session Preview without the Ambient Data Framework as key to this working is the ability for your web application to switch between getting content/data from the normal staging storage ...
Difficult question. In principle, in 2011 SP1 HR1: NO.
In certain cases it will work but what you need to do is to forward the XPM token from the staging site to the CD WebService and to have the Session preview claim processor activated on it.
Hope this helps.
There's a hotfix for that... (this is fixed in SP1).
If you're on SQL Server (I think with Oracle it is exactly the same fix), run this on the preview database:
IGNORE THIS, SEE UPDATE 2
Now that I think of it... run this on all your Content Delivery Databases...
Fixed with cumulative hotfix CD_2013.0.0.86156
Session Preview works off the Session Preview Broker DB and inherently through the Session Preview Odata service.
Despite your "code" components being regular CPs on a regular statically published page, when in Session Preview mode pages and CPs go to the session preview broker db and get served up via odata.
So you should check the mime type settings of ...
Looks like you did not configure your Publication Target for Session Preview. In the CME, open the publication target you're using for your preview site and:
Click the "Enable for inline editing" check box
Switch to the "Session Preview" tab
Enter the URL of your OData endpoint for session preview
Add the URL(s) of your preview website(s) to the list of ...
This should happen automatically if the staging site's app pool identity is setup correctly. In IIS you need to set the app pool identity to NETWORK SERVICE, and then give NETWORK SERVICE file system permissions to write and delete.
Assumes a dotnet implementation of XM but same concept applies for a jsp/Tomcat setup.
Both sites will need the Wrapper element in their cd_storage_conf.xml I believe.
Albert wrote a great guide to help here: http://albertromkes.com/2013/01/24/troubleshooting-the-sdl-tridion-experience-manager-with-session-preview/
The reason for it is something along the lines of both applications need to know the location of the session preview database, ...
If you are certain that your dynamic preview content is deployed to your preview database (and your list of steps suggests that you are) you will want to focus on the configuration of your staging web application:
wrapper and storage dao bundle configuration in cd_storage_conf
cartridges in cd_ambient_conf
preview and ambientdata filter in web.xml
You will ...
The preview cartridge (cd_preview_ambient.jar) manages your sessions -- ensuring that you have a valid token that hasn't expired, creating a new sessions as necessary, etc.
The footprint cartridge just adds some standard claims about the session. I think this one is mostly there for backwards-compatibility and to provide some claims out-of-the-box for the ...
You will need to configure the path to your site in the cd_dynamic_conf.xml file of your website.
<Host Domain="your-website.com" Port="80" Protocol="http" Path="/jp/ja" />
There is an excellent question on this by Dominic here:
What contribution does cd_dynamic_conf make to the workings of ...
As mentioned, yes, you do need the wrapper on both stacks, and here's the why.
If you look at the data flow (see the diagram at the bottom of this post), after you commit changes, the Content Manager will package and send the updates to the Content Delivery Web Service. The WebService will understand that this is temporary data, and store it in the database ...
On your first question I'm unsure, a resolver is called on publishing, but I'm unaware if a resolver is also called by the Session Preview/Fast Track Publishing indeed. That would be worth a test I'd say.
However your second question I can confirm, once you edit your DCP in XPM, its changes will already be published automatically once you check the ...
On the basis of the content of this question and answers, I think the answer is no. You need the Ambient Data Framework, and thus a web application server (Java/.NET/oData webservice) for session preview. I don't know if an AJAX approach could work, as session preview could alter the entire HTML of the published page (for example if you changed the page ...
Yes, you can configure how long these files remain in your webserver's file system, and it is the same setting.
If you are not seeing these files being removed it means that you forgot to set some cartridges in cd_ambient_conf.xml:
<Cartridge File="cd_webservice_preview_cartridge.xml" />
Here is the answer of the steps Experience Manager goes through so that you get a better idea of which modules to troubleshoot: https://stackoverflow.com/a/10802033/1284894.
The issue is usually due to a bad configuration of the Ambient Data Framework including the Request Filter and cd_ambient_conf.xml, or the cd_storage_conf.xml files on either the ...
Your question is:
Is there some setting that we am missing which would overcome the above scenario?
The answer to that simply is:
Yes you missed setting up Session Preview, i.e. you deliberately disabled it for whatever reason. Without a working Session Preview, you will not see the up to date content on a Page after its content has been changed, ...
In the 2013 Broker database there should be a table PUBLICATION_MAPPINGS, so maybe you don't have the correct Broker database? Check the TDS_DB_INFO table, that should have one record with the following data:
DB_VERSIONDESCRIPTION INSTALLATION_TYPE &...
From the follow-up discussion on your question it sounds to me like everything is working apart from the Ambient Data Framework of your actual web application.
I suspect you may have already tried these, but looking at previous answers around this topic suggests the following:
Check that you do not have <Cartridge File="cd_ambient_cartridge_conf.xml"/&...
You can have both in the same application. However you will need to configure both the CD Web Service (including session preview settings) and the application (including session preview settings).
You can find all of it documented here: Adding the Experience Manager Web site extension to a JSP Web site.
You can also verify the configs setting from below link for website, session webservice.
after verifying config, please also verify the JAR files using following link
Yes, and that's why in your cd_storage_conf.xml you'll find a section for the "WrapperDB". This is where you store the credentials for the session preview database.
<Storage Type="persistence" Id="sessionDb" dialect="MSSQL" Class="com.tridion.storage.persistence.JPADAOFactory">
The way XPM figures out the destination for publishing is by mapping the URL you are on to the URL settings for the Publication Target (not the ones for Session Preview but the ones specifically for republishing purposes). Please check that those are configured and it is possible to map one of the Targets to your URL.
It is (very briefly) described on a ...
On the subject of whether resolvers are triggered: the answer is No. From the online docs [login required]:
When Experience Manager users add or modify content, Experience
Manager uses a different mechanism than regular publishing to update
the content on the staging Web site.
This mechanism is called Session Preview. For performance optimization
I've seen this once recently and it was because the URL of the content manager that the "staging" website binds to for Experience Manager was still pointing to my other DTAP environment (deploy from dev->qa, publish, qa websites now connect to dev CM for Experience Manager).
The configuration for this is set as a template parameter on the template building ...
There's a lot of steps involved in Session Preview. Tackle them one-by-one and you will find the root cause.
Rendering of your template is executed in "Preview" mode. Try previewing your template and make sure your binaries are included as a result of this.
A POST is done to OData webservice. Go check the OData webservice logs for any error that may have ...
The answer depends on whether you're on .net or on java.
You can do this by configuring the folder which holds your (published) binaries separately from the main application.
Let's say your binaries are in the subfolder 'binaries'. The Web.config in the root of your site should NOT have the PreviewContentModule enabled. Just create a new ...
It was actually a DNS issue: the CM could not reach the session preview webservice because the host name could not be resolved. Once we fixed that and restarted the CM, the session preview cookie showed up in our web app.