As many Europe-based businesses we had to comply with GDPR legislation, which requires us to not track analytical data from visitors without their consent. When it comes to Sitecore 8.x, this requires to implicitly stop the Sitecore Tracker from initializing unless the corresponding Conseny Cookie has been accepted:
You might get this error when setting up a new Sitecore instance somewhere. The item in question is a /sitecore/layout/Devices item that Sitecore needs in order to operate normally. There can be several reasons why this is happening: You are running Sitecore up to 9.x, and your master / web databases are
Many of us have been there: whether it’s a matter of containerizing an existing solution, moving an instance to a different machine, or even just setting up our local development environment, many Sitecore developers had to square off with a non-functional XConnect instance. Last week was the third time in
Problem This week I moved my local development Sitecore 10 instance to a new laptop running Windows 11; all seemed well, except for XConnect, that mysteriously only worked without HTTPS. I would constantly get ERR_CONNECTION_RESET, with nothing being recorded in either XConnect, IIS or Events log: All the while the
I was setting up my Sitecore instance(s) on a new laptop, when this error reared its ugly head and kept me stuck for a good hour. Looking online there are many reasons why this showed up, but in my case, all I had to do was adding this line under configuration/system.web/compilation/assemblies:
While decommissioning a section of a website in a language that we no longer support, I found myself in need of removing the language altogether; trying to delete the item, however, resulted in the following error: Could not parse the language Note that a custom language name must be on
Today I’ve been having this problem out of the blue: “The type initializer for ‘Sitecore.Install.Serialization.IOUtils’ threw an exception.” Searching for this error in relation to Sitecore usually points to Newtonsoft.Json.dll as the culprit, but in my case it was Mvp.Xml.dll, that some NuGet or somesuch upgraded to a higher version thus
My Sitecore 8.1 solution has a considerable number of Custom fields; after the upgrade to Sitecore 9.1 (and Solr 7.2.1), none of them worked the way they did, returning an “unknown field” error for any field that used a custom <dynamicField>. What I ended up doing, was adding
Just a very quick write-up on this as it kept me busy for a couple of hours looking for a solution. After upgrading a number of NuGet packages (Microsoft ASPNet WebApi 2.2 Core Libraries, Microsoft ASPNet MVC, HtmlAgilityPack), my perfectly working Sitecore local development setup stopped working, instead throwing the
We’re moving our server infrastructure to a new host, and as part of the new configuration the Mongo instance will have its own server, as opposed as living on the same server of the SQL database. I took this as an opportunity to set up proper security for it. IP
