Jeremy Davis
Sitecore, C# and web development
As time goes on, something I've noticed is that as Sitecore evolves it is taking a greater reliance on search integration – making things like Solr ever more important. And that leads to an exciting new set of issues you come across if, for some reason, your search service is not available.
I wasted some perfectly good development time recently when some of my renderings vanished from published pages, thanks to this.
Quick one today. I was writing some code for Sitecore Computed Index fields recently, and it took me more Google Effort than I felt it should have to work out how to write unit tests with FakeDB to verify the code worked. If you want to do that without spending a while searching, the answer is pleasingly simple:
Continuing my voyage of obscure-error-discovery around Sitecore 9, this week SIF has been putting a lot of red into console windows for me. I'm not sure how many people will have this scenario, but if you have multiple people who all need to install their own Sitecore 9 instance onto one machine, this may be of interest:
I'm working on my first proper Sitecore 9 project at the moment, and got bitten by an annoying bit of confusion while doing some configuration work. If you're tweaking how xConnect works take note, and hopefully you can avoid making the same mistake I did...
Every so often I run up against an issue that's right there in the docs, but somehow has passed me by. This week that issue was Sitecore's new V9 forms implementation, and it's relationship with languages...
Recently I wrote about an issue I encountered where a client's website was missing its GeoIP data (and the related back-end analytics data) entirely. While the changes discussed in that post solved the problem of there being no MongoDB data for GeoIP lookups at all, I continued to see odd issues with many users not being located after those fixes were made. Sorting this out seems to suggest that some of the "common wisdom" about configuring GeoIP for analytics isn't right – so here are my latest findings:
Recently a colleague of mine told me about a suggestion they'd been given about setting up an instance of Sitecore. They were told that you should put your license file into a subfolder of your data directory because the license check enumerates files and folders in the directory containing the file. So if the folder contained other things, this would slow down the check. This sounded odd to me as you have to specify the exact path of the license in your config, so I thought I'd do some investigating, and see if I could prove or disprove the suggestion.
So, putting on my best beret at a jaunty "for science!" angle, here's what I discovered:
I spent some time this week looking at a client site whose analytics data was missing GeoIP information. Since they had a valid license for Sitecore's GeoIP lookup service, this was a bit confusing. So, continuing my battle to write up all the unexpected scenarios...
I read a blog post earlier this week that talked about the benefits of compiling your View files to increase performance in Sitecore applications. Reading that post (which
I stupidly failed to keep track of the link to, so can't reference it now
the comments pointed me back to) reminded me of an interesting issue that came up on a project I was looking at recently. If you're interested in the raw performance of your Sitecore sites, you might want to consider this as well when you're planning your views:
A few weeks back I wrote about spotting site performance challenges in the patterns you might see in trace data. But over the years I've noticed another set of repeating patterns that can be relevant here: Those of how a development team can find itself thinking and acting in the run up to a project hitting problems.
If any of these resonate with you and your team, maybe it's time to take a step back and think about how you can improve things?
