Jeremy Davis
Sitecore, C# and web development
This is one of those issues where I feel like I should have worked it out faster than I did. Computers are relentlessly logical. If you tell them to ignore something, they're going to ignore it, even if that does confuse your content editors...
There's been a bit of discussion (I might even go as far as to say ranting 😉 ) on the subject of not using "fast query" in your website code recently. I'm a supporter of this idea – but I came across an issue recently that points out why it's not always easy to be confident that you're not making use of it indirectly...
So, for the benefit of Google:
So while battling the jetlag that hit me pretty hard getting back from Sitecore Symposium, this issue came popped up in my bug queue last week. QA reported that a certain component on a test page was not allowing one field to be edited. It had worked in the past, but the behaviour suddenly changed so that one field no longer got the "you can edit this" overlay in Experience Editor. It took me longer than it should have to work out why...
not difficult to make mistakes in how you set up your site that lead to difficult to diagnose failures in the WYSIWYG editor. I came across one such issue recently that seemed like just the sort of thing Google needs to know about to save future developers (and probably Future Me as well) from the pain of debugging it.
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:
