Sitecore RTE broken - h is not a constructor

Sitecore - Telerik RTE broken

Recently we installed the Sitecore Security Bulletin SC2025-004 on a project that is deployed on Azure as a PAAS solution. The project includes SXA, so we also installed the Cumulative hotfix for SXA 10.2.0 and Sitecore XP 10.2 as was mentioned in the security bulletin (for sites running on 10.2 - there are different versions for the other Sitecore releases).

At first everything seemed fine, but then we noticed the Telerik Rich Text Editor (RTE) wasn't working anymore. Or at least, the display of it was completely wrong:

In the meantime we learned the this is not related to the patch install, that it was just a coincident although it is weird that it only happened on the environments where those patches got installed. Also worth mentioned we could not reproduce it locally (although we also installed the whole patch there).

Sitecore StackExchange

I started searching for a solution and while doing that bumped into someone on Sitecore StackExchange who seems to have faced the same issue: both the PAAS environment and the error. Anyways, after finding a fix I also posted it there so I hope he reads it someday and can fix his issue as well. You can check the post on https://sitecore.stackexchange.com/a/39965/237. 

The error - h is not a constructor

Our main starting point to solving the issue was the error above that we got in the browser. I found my way to a Telerik knowledge-base article that mentions the error: TypeError: h is not a constructor at Sys.Component.create.

As you probably know, the Rich Text Editor in Sitecore XM/XP is from Telerik, and although the error message stack trace was not completely the same as mine, the solution was worth a shot as it was close enough.

Solution ?

The solution they propose is adding a setting in the appSettings part of the web.config. Note that many solutions (including ours) rip this part from the actual web.config to place it in a separate file. The section should already contain some keys related to the Telerik editor. Add this: 

<configuration>

  <appSettings>

<add key="ValidationSettings:UnobtrusiveValidationMode" value="None" />

Once this was added, the Telerik editor was working fine again on our development environment. We deployed the same fix our test environment and there it didn't fix the issue...

User & role manager

So back to the research table. I found something very weird. Actually the trigger was that the user and role manager also started to act weird - displaying a white screen. This led me to the finding that the WebResource.axd calls were giving wrong results - in fact, they all gave the same result. Which of course broke several other javascript calls.

This smelled like caching so I checked with our networking guys and they told me the Front Door which was in front of the PAAS systems (and not local of course) was caching some routes. So my assumption is that is caches those axd calls without taking the full querystring into account. 

The real solution

After disabling that caching in Azure Front Door everything started working again. And hopefully it stays that way. And if not, you will read about it here...

As at least one other person encountered this I thought there might be more so it was worth sharing. If you have it as well, I hope this fixes it for you as well.

How to kill your Sitecore editor with one slash

 Is your page opening really slow in the Sitecore Content Editor?

I recently had an issue where one page (the homepage) of a site opened really slow in the Sitecore Content Editor. All other pages went very smooth, so it was clearly something particular to that page. And when I mean slow, I mean you click on the item and it takes one coffee for the editor to react. On the published site, there was no issue.

At first this was just annoying, but after a while you curious and annoyed and you want this fixed.

Debugging

The editor is pure Sitecore coding so how to start... one way is to enable the timing level for all events.

You will find this setting in the Sitecore.config file and if this is just for temporary debugging on a local instance you can alter it there. 

<!-- EVENT MAPS
      events.timingLevel =
        none   - No timing information is logged for any of the events (no matter what their local settings are)
        low    - Start/end timing is logged for events with handlers. Local settings override.
        medium - Start/end timing is logged for all events. Local settings override.
        high   - Start/end timing is logged for all events. Also, start/end for each handler is logged. Local settings override.
        custom - Only local settings apply. Events without settings are not logged.
    -->
  <events timingLevel="custom">

So we will change the timingLevel for all events to "high" instead of custom and restart the site.

Now let's keep an eye on the logs while we go back to the editor and open our homepage item. And bingo.. we get a lot of information in the logs but what was really interesting were the lines that said "Long running operation".

Long running operation

20204 11:29:46 DEBUG Long running operation: renderContentEditor pipeline[id={98E57B60-071A-44D1-A763-B6C1BCE0C630}]
20204 11:29:48 DEBUG Long running operation: getLookupSourceItems pipeline[item=/sitecore/templates/Feature/.../CtaRenderingParameters/__Standard Values, source=query:/$site/Data/.../*]
20204 11:29:50 DEBUG Long running operation: getLookupSourceItems pipeline[item=/sitecore/templates/Feature/.../CtaRenderingParameters/__Standard Values, source=query:/$site/Data/.../*]
20204 .....
20204 11:30:19 DEBUG Long running operation: getLookupSourceItems pipeline[item=/sitecore/templates/Feature/.../CtaRenderingParameters/__Standard Values, source=query:/$site/Data/.../*]
20204 11:30:19 DEBUG Long running operation: Running Validation Rules

Apparently we have a long running operation getLookupSourceItems and we are not doing this once, but a dozen times on the home page.  This is our cause - and ok, I exaggerated when I said a coffee but even a minute feels long to open an item.

So, we now now that the CtaRenderingParameters are doing something very slow and it is caused by the source for a field.

In that template I found (even two) droplist fields that use the same source: 

query:/$site/Data/Link Types/*

I am not writing Sitecore queries every day so I admit it took me a few minutes to figure out what was wrong with this thing. It looks like a normal query that fetches all items in a certain path. And it's just a small detail, but a significant one: the first slash should not be there 

query:$site/Data/Link Types/*

This works much smoother and the issue was fixed.

$site

We are using a resolveToken in the source. In the Sitecore docs you will find the list of available tokens and we are using $site here to get the path to the current site. 

But that path will already start with a slash. So although you (probably) want your query to start with a slash, you do not want it to start with two. As described in the query axes, one slash will give you the children (and will form one path) but two will give all descendants. And that is in most cases a very costly operation.

Conclusion

Be careful when putting sources - especially when using tokens. You might not notice anything bad or slow when just one component is added, but it can add up to a really slow item. Use the events timing level to get debugging information.