Jeremy Davis
Sitecore, C# and web development
It's Christmas, and I'm dreaming of a festive sherry, while I slog through my last working day of the year. So hopefully you can forgive me the flagrant clickbait headline... 😉
But you'd have to have your head in the sand not to have noticed that Oracle are changing the licensing terms for their builds of the Java runtime. They've decided that they want people and businesses to pay for the fastest access to support updates for Java. But as Sitecore developers, many of us make use of Solr – which relies on Java. So what can we do?
There are some things in Sitecore that you just take for granted will work. Loading items is a good example of this. I'll admit that user error can get in your way, but usually if you can see an item in the content tree, you can write code that will load it without issues. So I'll admit I was pretty confused when I came across a scenario recently where this did not appear to work correctly. In case anyone else hits this challenge, here's what happened:
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...
I did a talk about measuring site performance at Sitecore Symposium this year. It seemed to go pretty well, I think:
So Sitecore Sitecore Symposium**1 is very nearly upon us again. And this year (for the first time!) I'll be presenting a session. [Unless it gets moved again: Day 2 (Tuesday 9th), 16:15 in Swan 2 – "Measure if you want to go faster" – A developer's introduction to improving performance by measuring your code**2 ]
When this year's speakers first found out that their talk abstracts had been accepted, there was a bit of discussion on the Sitecore Slack about things speakers might want to know or do. And I've been meaning to write this up for a while, because there were quite a few things I saw that were worth sharing to help anyone else who's looking forward to their first opportunity to speak...
Here's a quick memory jogger for me: If you try to validate the AMP versions of blog pages, you may get this error from Google:
Invalid URL for HTML attribute 'href' in tag 'a'. What does it actually mean?
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.
