not difficult to make mistakes in how you set up your site that lead to difficult to diagnose failures in the WYSIWYG editor. I came across one such issue recently that seemed like just the sort of thing Google needs to know about to save future developers (and probably Future Me as well) from the pain of debugging it.
I was assigned two QA bug reports for a site I've been building. They were both related to one particular rendering – which allowed editors to pull in external content via
tags injected into the page:
Error Rendering View: /Views/PageLayout/66-33.cshtml: Error while rendering view: '/Views/PageLayout/66-33.cshtml' (model: 'Sitecore.Mvc.Presentation.RenderingModel, Sitecore.Mvc'). at Sitecore.Mvc.Presentation.ViewRenderer.Render(TextWriter writer) at Sitecore.Mvc.Pipelines.Response.RenderRendering.ExecuteRenderer.Render(Renderer renderer, TextWriter writer, RenderRenderingArgs args)
Inner Exception: Fields field cannot contain any of the following symbols: ():= at Sitecore.Diagnostics.Assert.IsFalse(Boolean condition, String message) at Sitecore.Pipelines.GetChromeData.GetChromeDataProcessor.GetFieldEditorButton(Item item) at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext() at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext() at System.Collections.Generic.List`1.InsertRange(Int32 index, IEnumerable`1 collection) at Sitecore.Pipelines.GetChromeData.GetRenderingChromeData.GetCustomButtons(RenderingItem renderingItem) at Sitecore.Pipelines.GetChromeData.GetRenderingChromeData.Process(GetChromeDataArgs args) at (Object , Object )
My initial reading of these issues made me think that the two bugs were probably related, and that giving editors the ability to use raw markup to add in
elements is a really good way of allowing them to accidentally break the page's markup in some way. I also noted that I could not reproduce the problems on my development instance. They only happened on QA. So that started me thinking that dodgy markup can cause issues in Experience Editor, because so much of its behaviour relies on being able to inject all the "chrome" that editors use to control renderings. So I went through some basic checks to try and spot any obvious errors:
None of those came up with anything looking wrong... And to be honest, that was not surprising, as the same code and content from the Master database was working without issues on my development machine.
Next stop on my debugging voyage was the old "pull it all appart and put bits back until it breaks" ploy. So:
With that in mind, I re-read the exception messages I'd been seeing, and noted two things: Firstly the stack trace included the type
so it had been giving me a hint about this all along, and secondly the main error was
Fields field cannot contain any of the following symbols: ():=
– which gave me a big hint.
So I switched over to the Core database, and drilled down to the custom Experience Editor Button definition that I'd added to my new Rendering. Looking through the fields I spotted:
Bingo: On the QA server, the field where you can specify what DataSource-Fields are edited by this button had acquired a rogue colon at the end of the name it was specifying. And the exception message did say that colons (as well as brackets and equals-signs) were not allowed. I'm guessing a copy/paste error was responsible for that.
Interestingly, I did not have the custom button item in Core on my dev machine (I'd not synched items in Core for a while, and hence didn't have other people's changes) and instead of failing with a "you are missing the item defining this button" error, my development instance was just carrying on happily anyway... Which explains why I could not reproduce the bug reports locally.
And once that colon was removed, and the item saved, everything went back to working properly on QA.