Sitecore’s media browser shows an annoying List View, rather than a Tree view by default. This is sad, ‘cos the Tree view is much more intuitive for users – they’re used a having a drive and folders.
Fortunately, you can make Sitecore use this. I think this tip came from Gert Gullentops originally, but I’m not sure. Continue reading “Make Media Browser show a Tree View, rather than List view”
I started getting this error this morning in my Sitecore logs:
System.InvalidOperationException: Ensure definition type did not complete successfully. StatusCode: 500, ReasonPhrase: ‘Internal Server Error’, Version: 1.1
I noticed this ‘cos analytics stopped working overnight:
We have a customer with Sitecore where Experience Editor is quite slow to open. They also spotted in their logs some warnings:
AccessResultCache cache is cleared by Sitecore.Caching.Generics.Cache … Cache running size was 9 MB.
Okay… whut? Continue reading “Improve Experience Editor Performance”
Sitecore lets you direct errors, such as page not found, to other pages within Sitecore. This is good – it lets you have an error page with all your dynamic content (navigation menus, account details, etc).
You can patch this in with something like:
<?xml version="1.0"?>
<configuration xmlns:x="http://www.sitecore.net/xmlconfig/">
<sitecore>
<settings>
<!-- Default: /sitecore/service/notfound.aspx -->
<setting name="ItemNotFoundUrl">
<x:attribute name="value" value="/errors/Item Not Found" />
</setting>
<!-- Default: /sitecore/service/nolayout.aspx -->
<setting name="LayoutNotFoundUrl">
<x:attribute name="value" value="/errors/Item Not Found" />
</setting>
<!-- Default: /sitecore/service/notfound.aspx -->
<setting name="LinkItemNotFoundUrl">
<x:attribute name="value" value="/errors/Item Not Found" />
</setting>
<!-- Default: /sitecore/service/noaccess.aspx -->
<setting name="NoAccessUrl">
<x:attribute name="value" value="/errors/No Access" />
</setting>
<!-- Default: /sitecore/service/error.aspx -->
<setting name="ErrorPage">
<x:attribute name="value" value="/errors/Error" />
</setting>
</settings>
</sitecore>
</configuration>
Great, job done, right?
Nope… Continue reading “Handling IIS Error pages in Sitecore”
When uninstalling Sitecore 9, sometimes you have to delete the services it creates in Windows by hand.
The command for this is:
sc delete [service name]
Service name can be found on the properties of the service. Don’t forget to delete them both.
So, I’ve blogged previously about my problems with the IClientApiService on a Content Management (CM) server. See https://andrewwburns.com/2018/08/15/unable-to-resolve-service-for-type-sitecore-emailcampaign-cd-services-iclientapiservice-while-attempting-to-activate/
Well, I asked Sitecore support about it, and they gave a really helpful response:
// This should be injected rather than calling the ServiceLocator
IMessageBus automatedMessageBus = ServiceLocator.ServiceProvider.GetService<IMessageBus>()
AutomatedMessage automatedMessage = new AutomatedMessage()
{
ContactIdentifier = contactIdentifier,
MessageId = emailCampaignId
};
automatedMessageBus.Send(automatedMessage);
Their reasoning for this was:
It is not recommended to add the configuration on CM since:
1) It is not enough to add only the <configurator> section, since it has dependencies on other configuration sections.
2) The CustomServiceConfigurator may change in the next release and the functionality will stop working.
Fair enough, seems sensible, though I’m now slightly at a loss for what the IClientApiService is actually for. I’ve tried the code they’ve send across, and it sends email correctly (and yes, I used DI, rather than a ServiceLocator).
I’ve tested this code locally, and it works nicely; I haven’t yet had a chance to try it on a scaled environment. I also decompiled the relevant assemblies, and yes, behind the IClientApiService implementations it seems to use a MessageBus<AutomatedMessage> object, so this should be equivalent.
I got this error while looking at a customer’s system, and weirdly, all renderings that used datasources had stopped working.
Sadly, I don’t still have the full stack trace, but it turns out the problem was a mis-configured URL for the SOLR service. Sitecore uses content search to find the datasource for a component.
This fact was a new one for me!
I think our URL lacked a /, or /#/. We corrected it, and the error went away – and our datasourced renderings started working again.
I found a reference on StackExchange after the fact.
