The other day a colleague remarked on how much time was wasted navigating down to the search index rebuild options in the Sitecore 6.6 Control Panel. While there are a variety of other ways of triggering a search rebuild, (Sitecore Rocks for example) it was suggested that having a button on the Ribbon (as per Sitecore 7) would be helpful in this case. So here's a quick set of instructions for one way it can be added:
The idea that everything in your Sitecore content tree is "an item" is great once you understand how it works, but can be a bit confusing to people who are new to the software. It's a fairly common new-user mistake to set Layout Details on a Template item, rather than on the Standard Values item for the template. This leads to all sorts of "but why are my changes not visible on the website?" confusion.
Talking about this with a colleague a while back, I wondered if there was a way of trying to reduce the likelihood of this sort of mistake for new users. Here's a quick example of an idea I came up with:
A quick distraction from navigation patterns this week:
A while back I wrote a bit about issues with following the SDN instructions to create a new custom application on your Sitecore "start menu". Recently I responded to a Stack Overflow question about this issue, where after a bit of discussion I discovered that this didn't work quite the same way on Sitecore 7.5. So having investigated why, I figured I should write this up...
The other day I was having a conversation with a colleague who was bemoaning the lack of a fast way to paste a Sitecore item path into the UI and have the Content Editor change selection to that item. I suggested using the search box or the Navigate button, but apparently they weren't right. The person wanted to paste a link and have the content tree change without any other clicking about.
So, in the spirit of being a helpful co-worker, I hacked up a quick command extension to solve this problem. It's trivially simple, but I figured someone else might find it useful, or learn something that helps them...
Last week I talked about an approach to displaying template-related help fields in Content Editor. The last week has been a bit manic, so I've not managed to spend much time on extending these ideas, but I have a basic approach to displaying similar data in Page Editor. Quick one today...
One of the challenges of building sites with Sitecore can be making sure that your content editors understand the purpose of each template and what data they're supposed to be filling in for each field to build up their site. This can be a challenge for complex sites – the data model required for building a complex and feature packed site can sometimes be difficult to explain to non-technical editors.
Historically I've usually tackled this problem though documentation and training sessions – but it struck me the other day that Sitecore itself should be able to help too.
So I've been experimenting with the basics of a really simple prototype for explaining templates. I'll explain a what I was thinking about for Content Editor this week, and hopefully offer some ideas for adding similar behaviour to Page Editor next week.
There's quite a bit of material out on the internet about creating custom fields in Sitecore. But inevitably, when I found myself with a requirement to create one, I couldn't find anything particularly close to my needs. So here's another post about creating a custom field – maybe it'll be of help to someone...
I've talked previously about how you can improve your content editors' understanding of where things live inside your Sitecore content tree by making use of relative queries to specify where the editing UI finds things. You can do it Data Sources.
Logically, you'd assume that if a relative query works for a Multilist field in a normal template, it should work in a Parameter Template too? Well, if you set up something like this:
Last week I spoke at the London Sitecore Technical User Group, and discussed my experiences working on a project that had to provide a Faceted Search UI in Sitecore 6.6. As part of my example, I talked about how you can build Facets using Lucene when you don't have access to the newer search APIs available in Sitecore 7.x, and about how you can make your search UI configurable by editors to improve their user experience. And I said I'd post my example code and explanation. So here goes:
In these days of standards compliance, most of the time you want the mark-up stored in your Rich Text fields to be well formed XHTML – which is exactly what the editor for these fields should give you. But what can you do if you come across a scenario where you don't want the mark-up to be changed by the editor for some reason?