Sometimes you may want to detect whether an EPiServer Block is being edited/previewed directly as opposed to just being rendered in a page that is being edited. For this purpose PageEditing.PageIsInEditMode is not enough.

My use case was rendering some editable properties in the block edit view outside of the rendered component, but not have those distort the layout when that block is rendered on a page being edited in a content area.

Here's what I want to achieve

Here's how to achieve it

Set up a base controller for all your preview controllers, in it set a ViewBag dynamic property of IsInBlockPreview (or similar) and then use this in your Block views to hide/show certain editor specific pieces.

Here's a gist...

The upgrade process is pretty simple but I had a few issues worth mentioning.

Issue 1
If you've upgraded to Sitecore 8.0 Initial, and try to hit the Content Editor before upgrading WFFMs too, you'll likely encounter an issue loading the Content Editor. Specifically, "
Could not load type 'Sitecore.Shell.Applications.WebEdit.Commands.WebEditCommand' from assembly 'Sitecore.Client, Version=, Culture=neutral, PublicKeyToken=null'."

I couldn't find any reference to that class in /sitecore/admin/ShowConfig.aspx or the Core DB, and it seemed weird that the version was being reported as when they should be 8.x. There wasn't much online, but the posts that did mention it talked of Sitecore 8 upgrades and WFFMs. Combined with the weird version being reported, I had a feeling I just needed to push forward and update WFFMs.

Sure enough, completing the install of the WFFMs .update package and updating the configs brought the Content Editor back to life.

Side note:
The Upgrade Guide doesn't mention it specifically as it probably assumes you're continuing after a Sitecore 8 upgrade, but if you're Forms configs aren't already disabled, do so before the package install to avoid another YSOD.

Issue 2
When following the Upgrade Guide, it means you may get some errors in the final report page. These will be in /sitecore/system/Modules/Web Forms for Marketers/Sample Forms/*. If you do, it mentions going through each of those (and I assume your own Form items) and making some manual corrections to the __Tracking field XML. But that's painful, so here's a gist of an ASHX that does this on load for you.


Syncing Sitecore items into TDS is pretty straightforward, except when it starts throwing exceptions about file paths being too long for Windows. The usual fix is moving your TDS project/s up a few directories, or use TDS’ “File System Aliasing” on particularly long part/s of the content tree.

With a few tweaks I had this in place but nonetheless I still kept seeing exceptions about file path lengths, even though I knew all my *.item files that TDS should be generating would be well under the ~250 char limit imposed by Windows.

After pulling my hair out for ages I finally found the root cause. Even though I’d been limiting the file paths of the TDS output TDS relies on Sitecore’s built-in serialization output which it then copies over for itself. Sitecore’s serialization outputs into a folder governed by the Serialization Folder Sitecore setting, by default “$(dataFolder)/serialization”.The file path limit I was hitting was in here.

Luckily there’s a Sitecore setting to solve the problem. It’s full description (albeit confusing) in the web.config is:

In Windows, there is 248 characters limit on the length of file system paths. To avoid exceeding the maximum path length, the serialization API will shorten long path names. This setting specifies the maximum length of the path to the data/serialization folder, which determines how long item paths can be before they are shortened.
Important: The value of this setting must be the same on all Sitecore instances accessing the serialized data.
Important: When changing this value, it's recommended to remove the contents of the serialization folder and serialize all items again. Otherwise duplicates of serialized items may appear in the serialization folder.
Example: A value of "90" for this setting will mean that item paths longer than 150 characters will be shortened, since Sitecore reserves 8 characters (and 248 - 8 - 90 = 150).
Default value: 90
<setting name="Serialization.SerializationFolderPathMaxLength"value="90" />

Long story short, the solution is as follows:

  1. Navigate to your serialization folder.
  2. Backup any serialized data you have in it to somewhere else.
  3. Determine your serialization folder’s path length.
  4. Increase the value of the “Serialization.SerializationFolderPathMaxLength” setting to be higher than yours. I’d recommend a patch file for abstraction from the web.config.
  5. Regenerate you serialized data.
  6. Ensure all Sitecore instances/environments get this setting update by adding the patch file to them.

Happy days :)


After updating to Chrome 37 today I noticed that modal dialogs in a Sitecore CMS 7.0 instance weren’t working. Turns out window.showModalDialog was deprecated in this release of Chrome, and it won’t be the only one:

“[…] the feature will be gone in Opera 24 and Chrome 37 […] Mozilla is looking to removeshowModalDialogas well, but […] probably not before Firefox 32.” [1]

What does this mean?

Clients using older versions of Sitecore (7.2 and 7.1 are okay, 7.0 isn’t) with modern browsers (Chrome 37/Opera 24/Firefox ~32 or higher) will have problems using Sitecore as modals won’t show; instead they’ll just get a greyed out screen overlay.

What’s the fix?

  • Stick to an older browser (but we don’t want this and it won’t stop those auto-updating browsers).
  • Re-enable the feature in Chrome as mentioned here with an Enterprise Policy setting to re-enable showModalDialog (Chrome only and only until “May 2015” when it’ll be completely deprecated).
  • Upgrade clients to the latest version of Sitecore (7.1+) which uses a different modal/dialog system

Additional reading

Update: Thanks to @timhacker for finding out that Sitecore 7.1 is also okay.