codeflood logo

Multiple sites and the Preview Interface

I experienced a very weird issue the other day that was to do with the preview interface. When I set a publish restriction by date on a particular item for a future date, although the preview interface respected the date restriction, when I changed the preview date it's as if the interface ignored the date. No matter what I changed the preview date to, the interface wouldn't show me my item. Now, this is the whole point of the preview interface; to show me how the site should look taking into account workflow and publishing restrictions for a given date and time. So this was a very weird issue that shouldn't be happening.

But the issue wasn't contained to a single item. I tried a number of different items based on a number of different templates. I also tried with and without workflow. All exhibited the same behavior. Now I knew the preview interface definitely did work as I've used it with the Nicam demo site many times before. In fact, in trying to diagnose the issue I had the Nicam demo site open which was being hosted from the same computer.

But if I launched the preview interface from inside the content editor, it did work. Now this was getting really weird.

I eventually got closer to the metal and started looking at query string values and cookies. The way in which Sitecore starts the preview interface is by setting some query string values. Also, the difference between logging directly into the preview interface and launching from the content editor is that the content editor was supplying an sc_item query string value which is used to set which item you wish to preview.

Eventually I found that the sc_date cookie, which is what sets the date to preview at, was only being set for the default "website" site and not the custom site I'd created in web.config (which I was accessing the site through). The Sitecore install I was playing with was running multiple sites that were differentiated by hostName.

I tried removing the custom site I'd created in web.config and applied the settings of that site to website, and lo and behold, preview started to work. So it looks like there may exist a small issue with preview not applying the restrictions unless you're previewing from the website site.

And if you're playing at home, here's the steps to reproduce the issue.

  1. Open the web.config for an existing Sitecore install.
  2. Locate the website site definition. Copy and paste above the website definition.
  3. Change the sitename to "MyWebsite" and add the hostName attribute and set it to something which will resolve to this application (add to hosts file and add to host headers in IIS).
  4. Log into the Sitecore desktop through the hostName for MyWebsite: http://mywebsite_hostName/sitecore
  5. Launch the content editor.
  6. Navigate to an item and apply a publishing restriction to the item for tomorrow.
  7. Log out of Sitecore
  8. Log into the preview interface.
  9. Verify you cannot see the item in question as the publishing restriction is in affect.
  10. Change the preview date to tomorrow.
  11. Note you can't see the item. This is the bug. The preview date is after the publishing restriction date but the item can't be viewed.

So what can we do to get around this issue?

The easiest option is to log into the Sitecore desktop using a domain that would fall through to the website site, then launching the preview interface from inside the desktop. So if my custom site is using hostName "custom_site_domain", then don't use that domain, use one that falls through the website like "localhost".

You could also bind your custom site to a virtual folder instead of a hostName in your site definition. So instead of accessing the login page using http://custom_site_domain/sitecore, I'll use http://website_domain/custom_site_preview/sitecore.

I hope that saves some frustration for you when you're demonstrating Sitecore. This has been logged with Sitecore support and they hope to have this fixed in an upcoming release.

Comments

Excellent :D
I have this exact issue with another client, but I never had (or took) the time to investigate it to this detail level to actually get something decent back from Support.

My brother would be amazed this blog post. We were not too long ago speaking about this. lol

Leave a comment

All fields are required.