Remember that time when developing for the Page Editor (now known as the Experience Editor or “EE” for short) was an afterthought or often just outright ignored? If you are like me, you’ve buried those memories hoping to forget those days even existed. Today, having a friendly Experience Editor… experience is one of the more important aspects of a successful Sitecore implementation. Whether the client has plans on using personalization, xMarketing, etc. or not, neglecting the EE is a huge mistake that’s still commonly made.

For a long time, I ignored the Page Editor. I admit it, albeit shamefully. My attention was elsewhere and some (unintentional) bad habits developed circa 2006 lasted longer than others. It wasn’t until I began my career at Paragon Consulting, Inc. in 2014 that I corrected those bad habits. I became fully aware of my sins against Sitecore’s standards and best practices and in the years since I’ve made the EE one of my main areas of focus.

At Paragon, one of the tools we use on every site is a popular ORM called Glass. After years of experience using Glass, I’ve come across a variety of “Glass Gotchas”. One of the more common and basic issues I see developers regularly make is placing Glass’s Editable method inside a paragraph tag.

This issue affects all page modes; however, it becomes a larger problem in the EE. When the Editable method is wrapped in a P tag, it causes the content and chrome to separate causing the existing content to become impossible to edit. Although it’s still possible to enter content, doing so will replace the existing content. The following is an example of this issue. <p>@Html.Glass().Editable(Model, x => x.Content)</p> renders out as:



This is an example of the RTE field rendering correctly in the EE.



The root cause of this problem, IMHO, usually begins with a front-end developer that may not fully understand the finer points to creating CMS friendly markup. They wrap editable content inside the paragraph tag without considering two important factors. First, what type of field controls this content and secondly, what content will the author place in that field. If the field ends up being Rich Text and the author inserts the content with paragraph tags, we now have an issue in the EE.

What are our options to remedy this situation? Short answer, there isn’t a sure-fire remedy. I’ll list a couple approaches that will work to a degree. Ultimately, the best remedy is to TRUST the author. Hopefully they were trained properly and they enter content correctly. If not, with luck the item has a proper workflow and the issue is caught before it’s approved.

Possible remedies:

Request the front-end dev change the tag to a different block element.

Utilize the renderField or saveRichTextContent pipeline as blogged about by Tech Musingz in 2014. It’s a good approach, but I would modify it to use regex to determine if it’s properly wrapped just in case the author places a class on the P tag.

Training. As I mentioned above, we need to make sure the client is made aware of the possible ramifications of going sans P tag. Clients/Content Authors are not always familiar with HTML and they don’t need to be. They just need to understand how to properly utilize the RTE so it produces the correct markup.

It’s a noble trait for a developer to feel the need to “client proof” every aspect on their site, but budgets and time are finite resources. We shouldn’t deplete it on miniscule issues like this one that can be solved with proper training. The time would be better served focused on other areas of greater importance.

I hope this long post for a relatively simple topic was entertaining and helpful. I apologize if this has been blogged about before. I felt the need to blog about it myself since I still see this issue happening and I hope to keep this issue fresh and avoid it from fading away for a while.

If you have a good solution to ‘Glass’s Editable method/P tag’ issue that I did not mention above, please leave your approach in the comment section below.

Update 6/9/17: “It’s not a Glass “issue”, but a general #Sitecore one. Wrapping an RTE field with <p> tags using the Sitecore API will lead to same issue. Issue is RTE adds <p> tags, and you can’t nest <p> tags, which the browser tries to compensate for by “prematurely” closing the tag” – Thanks to @jammykam