6

I am using Sitecore 8.2. The Experience Editor has a feature called as "Usage" which appears in the widget that shows when we select a component/rendering. The purpose of the usage functionality is to show the count and the list of webpages that use that component. This feature would fire a request to the server (like this: -/speak/request/v1/expeditor/ExperienceEditor.Datasources.GetDatasourceUsagesCount) whenever we click on a component. The response would be a JSON containing the Item IDs referencing the component.

The feature would make sense if it gets the usage data for datasources. But the problem with this feature is that it also gets the usage data even for the "renderings". Say, there is a "Header" rendering which is used across all page templates. This rendering does not use an external datasource because the model is the page item itself. But this feature does not understand that and gets the usage data either way. It returns ALL the pages which use the "Header" rendering which is pointless and time consuming.

What is frustrating is that the "Header" rendering is used in all the 5000 pages (and counting)! So, the usages count request takes several seconds to get the response. This causes the Experience Editor to freeze for that time which makes it unusable and unproductive. We have several renderings like this which are used across all the pages (footer, side nav, social, feedback section etc). The user clicks on a rendering innocently and it turns out to be a landmine! The user is stuck for several seconds (our average is 45 seconds).

Have you faced this issue? Is there a Sitecore config to turn this off or a setting at the rendering level to remove this feature? I looked and looked but could not find anything. I ended up customising at the server side by overriding the Sitecore's class but I want to get rid of the customisation if I can.

Thanks for the help.

Improve this question

3 Answers 3

Reset to default
6

I just put a ticket in with Sitecore for this last week. Here is the fix from Sitecore. The fix allows you to pick how long the call will wait before it return a *+ result with no count.

The behavior you reported was registered as a bug in our bug tracking system.

Please use the link below to download the patch fixing your issue: https://sitecore.box.com/s/kqnxaopuccbnbys6dn42eab8cu43zzc6

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/">
  <sitecore>
    <sitecore.experienceeditor.speak.requests>
      <request name="ExperienceEditor.Datasources.GetDatasourceUsagesCount">
        <patch:attribute name="type">Sitecore.Support.ExperienceEditor.Speak.Ribbon.Requests.DatasourceUsages.GetDatasourceUsagesCount,Sitecore.Support.171097</patch:attribute>
      </request>
    </sitecore.experienceeditor.speak.requests>
    <settings>
      <!-- MAXIMUM TIME TO GET A DATASOURCE USAGES IN THE EXPERIENCE EDITOR
              Retrieving many referrers of a datasource may block the Experience Editor while proccesing. This settings limits (seconds) the time of retrieving referrers.              
              Default value: 2
              Disable limits: 0
      -->
      <setting name="ExperienceEditor.GetDatasourceUsagesCount.MaxProcessTime" value="1" />
    </settings>
  </sitecore>
</configuration>
Improve this answer
2
  • 2
    Thanks @chris-auer for your solution. I will take this as an acceptable answer. I hope Sitecore 9 has this fixed.
    – Jay
    Commented Feb 11, 2018 at 1:42
  • We are using Sitecore 9.0.1 and are seeing this issue.
    – Calum
    Commented Mar 18, 2019 at 17:10
8

I agree with you, datasource count sometimes makes no sense.

But from what I know there is no config which you could use to hide this functionality.

You can remove this call by editing this file:

sitecore\shell\Applications\Page Modes\ChromeControls.js

Find function renderDatasourceUsagesCommand and replace it with:

renderDatasourceUsagesCommand: function () {
    return $sc("");
}
Improve this answer
2
  • Thanks @marek-musielak for your idea. Good to know that the client side allows us to disable this. I would see this also as a customisation. The server side customisation was an extension and this is a modification. Thanks for the idea though - appreciate it.
    – Jay
    Commented Feb 11, 2018 at 1:40
  • 1
    The best way to show your appreciation for a useful response is by voting, instead of commenting. This site reaches peak performance by rewarding the good content, leaving the questionable for reference and downvoting the bad.
    – Mark Cassidy ♦
    Commented Feb 12, 2018 at 11:42
0

Since this issue also happens to be in Sitecore 9.0.1, I opened a sitecore support ticket and below is the response.

The issue has been fixed in Sitecore 9.0 Update-2 so please consider an upgrade of your Sitecore version. If this not possible, you can try the patch: https://github.com/SitecoreSupport/Sitecore.Support.171097/releases/tag/9.0.1.0

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.