Hooking into Sitecore

Monday, December 07, 2015 @ 04:00

By: Corey Adler

The following problem, like so many others that I’ve written about, happened to me recently on a project that I was working on that was using Sitecore MVC 7.2 with Glass Mapper 3.0.12.24. During a regression test, one of the testers noticed something odd: Copy-pasting text to the template’s Heading field (which is a single line text field) from an HTML encoded source was adding the HTML markup as actual text into the Heading field upon save (see image below). To add further intrigue, this issue was only showing up in Edit mode. Both Preview and Normal modes were showing the Heading properly, without any HTML tags. The client declared this a defect, and wanted it removed.

Source Text

On the Page:

Heading Issue Part One

Heading Issue Part Two

So what was causing this lovely defect? I turned immediately to the page itself to see where it could be going wrong.

Editable

I found the line of code above that binds Glass to the Heading field, and then proceeded to look at the template itself.

Template

Wait a second… It’s supposed to be stripping out the HTML tags—hence the use of the Regex there! So why doesn’t this appear to be working? It turns out that it was actually—in Preview and Normal mode. Debugging this in those modes proved that, and answered the second part of the problem listed above. As far as Edit mode, though? It never hit the Regex call while debugging, which can only mean that, for some reason, Glass must be binding directly to the actual value in the Master database, and not to the getter shown above.

So if the Regex stripping wasn’t working when it was placed on the template, what is there to do to fix this?

The answer is actually simple, and highlights one of Sitecore’s coolest features—the ability to hook up events into Sitecore’s save pipeline. In this instance, we are interested in using the item:saving event to prevent saving the bad data into the Master database. Per John West (at http://bit.ly/1hohlzK), the item:saved event is useful in “that you can access the values from the item before the save, and the new values, and can prevent the user from saving their changes” In other words, if you know that you have the potential for saving some bad data (like HTML tags into a non-Rich Text field), you can edit the item in the event and have that data be saved automatically to the database. And by automatic, I mean it—there’s no need to create contexts (like in Entity Framework), or even to resort to Sitecore queries to save the data. Any adjustments made to the data in the method call will automatically persist to the database in question.

So here’s how I fixed it. I created the handler class, and made sure that it would only try to make adjustments whenever it was the correct template (thus not introducing unintended consequences with other templates in my solution). Note again that once I’ve adjusted the item (using the same Regex as was in the template code) I’m not doing anything to tell someone that there’s been an adjustment—it will automatically be persisted into the database. The method itself doesn’t have to be protected—I just wanted to make sure that no one else could use the method except for Sitecore’s save pipeline.

Handler

All that’s left to do now is to simply let Sitecore know that this event exists. You can do this by using a patch if you want to (which might end up being more preferable), but for this example I’ll show you where it would go in your project’s Web.config file. Just search for “item:saving”, and you should have no trouble finding it.

Web Config

And then we…build it and refresh the page! That’s really all that needs to be done, as shown:

Result

So there you have it: A simple fix for a nagging problem that makes the client happy. This shows one of the things that makes Sitecore so versatile—the large amount of ways that one can customize the Sitecore experience to one’s liking. There’s no need to just live with it, or to force the client to copy-paste into Notepad first. They can truly have their cake and eat it too. Until next time, I wish you good coding.