Jeremy Davis
Sitecore, C# and web development
I was down at Sitecore's offices for a training course the other week and got shown how useful the URIs for Sitecore items can be to your code – something I'd managed to miss before. So in the spirit of sharing, if you've not thought about uses for URIs, have a think about this:
It's a fairly common scenario in Sitecore code: You need to pass details about a specific item between two bits of code, but due to some sort of process boundary you can't pass the specific
Item
object. Given that a specific bit of content in Sitecore is specified by its database, identifier, version and language, how can you pass all that data across a boundary easily?
In my last two posts [first part, second part] I've outlined the results of some research into an approach for how you can package Sitecore with NuGet. I presented this at a recent Sitecore Technical User Group, and am documenting it here with a bit of detail that didn't fit into the presentation. This week I'll finish off the set of posts with a few conclusions from this experiment.
Last week I started writing up the content from my Sitecore Technical User Group presentation on using NuGet for the easy creation of new development instances. This week I'm continuing that topic, with the next steps for package creation:
A couple of weeks ago I had the chance to speak at the Sitecore Technical User Group in Manchester. I gave a talk about experiments into how you can put Sitecore into a NuGet package in order to create low-effort developer instances. Due to time constraints I wasn't able to get all of the information I wanted into the presentation, so over the course of my next three posts I plan to write up the key info from the presentation with that extra detail.
Quick one today, as I need to spend time writing up my presentation from the Sitecore Technical User Group in Manchester last week. (Hopefully will have something done for next week's post)
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:
If any of you have children, you're probably well aware of their awesome ability to spread around every new variation of the common cold that appears. This week I've been mostly suffering under the latest of these "presents" from my son, and to be honest may not be doing my sharpest ever thinking...
Coincidentally it took me a bit of head-scratching to resolve a problem with an experimental instance of Sitecore 6.6 that I wanted to make use of the other day. Browsing to the public site appeared fine, but when I tried to load Content Editor I was greeted with an exception saying
Access to the path 'C:\inetpub\wwwroot\TEST\Data\viewstate\1\7\E' is denied.:
While working on the
logging configuration for sending messages via email last week, I realised that all the documentation I could find for the
So with a bit of research, I've dug out the important values that can be used in case anyone else needs to configure log messages in older versions of Sitecore:
Sitecore manages its logging through the Log4Net framework. Out of the box, this is configured to write log data to disk files for you to review. But sometimes you might want to receive your log messages in different ways. Commonly people do stuff like change this to record messages in databases, but when I was asked how to get exception messages via email in Sitecore 6.6 recently, I failed to find any helpful posts.
So if you want to receive log messages via emails, here's one way of setting it up:
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.
