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 itSet 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...
Recently I needed to find all items that had $name in a field value after updating the standard value of that field on the template to be a $name
field token replacement.
I only wanted to find items under /sitecore/content though, i.e. items created before my template update.
Here's a gist:
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:
<!-- SERIALIZATION - SERIALIZATION FOLDER PATH MAX LENGTH
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:
- Navigate to your serialization folder.
- Backup any serialized data you have in it to somewhere else.
- Determine your serialization folder’s path length.
- 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.
- Regenerate you serialized data.
- 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.