Chromes
Sitecore uses special markers – chromes – to tell apart placeholders, renderings, fields, and edit frames in the Page Editor. A chrome is server-generated and marks the beginning and the end of a potentially editable section. It also provides all the essential metadata for the client side scripts to rely on:
<code type='text/sitecore' chromeType='placeholder' kind='open'
id='Content_Main' key='Content Main' class='scpm' data-selectable='true'></code>
{
// JSON metadata
}
<code type='text/sitecore' chromeType='placeholder' kind='close'
hintName='Content Main' class='scpm'></code>
The metadata for the placeholder, for example, contains things like placeholder’s display name, its editable status, associated commands, allowed renderings, etc. The <code> markup and enclosed metadata is interpreted by the client side Sitecore.PageModes.ChromeManager and respective Sitecore.PageModes.ChromeTypes.* objects.
Chrome’s metadata for the editable elements is generated by the getChromeData pipeline. The <code> markup is inserted around the elements by the AddWrapper processors as part of respective render* pipelines – renderField, mvc.renderRendering, mvc.renderPlaceholder.
[su_note note_color=”#fafafa”]It was a very short introduction into the world of chromes. I should probably set some time aside and write a more comprehensive series about chromes and what you can do with them and why you might want do it but this short intro will do for what I will write about next. By the way, I have just submitted two papers for the upcoming Sitecore Symposium and, if I am lucky, I may end talking about some of it there on the Developer Track.
[/su_note]
Contract
COVID-19: Digital Insights For Enterprise Action
Access Perficient’s latest insights into how you can leverage digital technologies to not only respond to the pandemic, but drive your operations forward and deliver experiences your customers need.
The client side JavaScript makes certain assumptions about what it should receive from the server-side code. When it comes to chromes it’s fairly reasonable to expect that a section has an opening and a closing marker as otherwise it’s really hard to tell what is what.
I sympathize with the Sitecore.PageModes.ChromeTypes.Placeholder here and I would too expect both markers and would probably too throw something if I didn’t receive one or the other. The Placeholder class throws an error.
Accidentally breaking it
A simple controller rendering that returns an arbitrary string content that is not HTML markup will (accidentally) break something and breach the chrome markers contract:
public class MyTestController : SitecoreController
{
public ActionResult Test()
{
return Content("Sitecore");
}
}
This simple UI component, once inserted into a placeholder, will not render “Sitecore” and will instead write the following in red ink in the console window and break the rest of the client-side initialization logic:
[Uncaught] Loaded unexpected element while trying to get rendering html from server. Expecting last tag to be closing script marker
I looked a little bit into it and I can tell that the server side code only sent the opening marker. There’s no closing <code> and it very much upsets Placeholder‘s stomach.
The workaround is to enclose the content into a valid HTML markup – <span>Sitecore</span> will do just fine.
[su_divider][/su_divider]
@AlenPelin confirmed that it’s a defect (my support issue #410489 posted against 7.1 Update 1).
