Jeremy Davis
Sitecore, C# and web development
The third part of this series is to look at how we can add images to our XML Sitemap files. We've looked at the configuration and the basic code to get entries into Sitemap files in the first two posts.
Getting images into the sitemap requires two things: First specifying some rules for what images to include, and secondly some code to extract those images from the content and write them into the index files. The code to deal with images that are specified in fields on the web page item is easy – but we also need to deal with the situation where the image is referred to by a component that has been dynamically bound to the page.
Last week we looked at the stuff to create in Sitecore to configure a custom sitemap generator. This week we'll carry on and look at the basic proof-of-concept code that can be used to process that configuration and generate a sitemaps and sitemap index files. It's another epic post...
Sitemap files are a requirement for most websites these days. They help SEO by ensuring that search engines index the files and images they might not otherwise find, and that you think are most important. Whilst there are assorted pre-built add-ons for Sitecore that can help with this, that's no fun. It's much more fun to build your own...
Real work is getting in the way of blogging time at the moment, so I'm going to break up my investigations into this into three posts. This week I'll look some requirements, core configuration and overall algorithm. The next part will look at the core code. And the final one will look at adding image data to the sitemap files.
Some time back I worked on a website which made extensive use of two bits of technology:
When the project was originally specified, these two things were thought of as individual aspects of the project and not much thought was put into the idea of bringing them together. But as the project progressed one of my colleagues realised that editors were basically being asked to enter the same data twice in some areas of the site. Once when they configured the metadata to drive the search facets, and once when they set up profile cards. We'd failed to spot the strong overlap between the data being entered in these two areas of the site.
As an experiment in "can it be done?" I tried to see if it was possible to index your DMS Profile Card data in Lucene, to allow it to be used as search facets. This never ended up in the actual project, but I thought it might be of interest in case anyone else finds themselves with a similar need.
There are quite a few ways to install Sitecore. You can run the .exe provided from SDN, use the Sitecore Instance Manager, or write your own scripts to automate configuring the bits in the official zip files. But, having done a bit of testing, it seems that you have to be careful about the security settings when you're using these different approaches. Whilst the .exe installer leaves you with a Sitecore instance that's relatively safe to expose to the internet, SIM does not seem to make all the same security settings. It's installs seem (by default) only suitable for private development instances. And the "roll it yourself" installs from Sitecore's ZIP packages are only ever as good as you make them – miss a step and you might open a security hole.
With that in mind, I've been thinking about install automation – can I solve the problem of getting an unattended install to work from the .exe file?
The projects I'm working on at the moment are largely stuck using older versions of Sitecore. Whilst our friends at Sitecore UK would love us to upgrade to new versions as soon as they appear, for some of my clients that is not practical for a variety of reasons. However some of the features in newer releases of Sitecore would still be useful in these projects – so recently I found myself quickly coding up a simple version of something like the dictionary domains functionality in SC6.6.
The behaviour I needed to enable was to be able to have separate dictionaries for different aspects of the site – to be able to move dictionary entries away from their standard location in
/sitecore/System/Dictionary. You can do this by providing a custom "translate" method that your code can call to turn a dictionary item path into some text.
Recently I looked at removing aliases when their owning items were deleted. I noted at the end of the post that the code ended up with some duplication in it. Duplication is generally a bad thing in code – copy/pastes of code tends to diverge over time and introduce bugs. So ideally we'd work out a way to get rid of the duplication, and reduce the set of methods our class needs.
Having been reading a bit on functional languages and F# in particular, I was thinking about how it can be done by passing code as parameters to more generic methods.
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?
Recently I attended the developer upgrade training course for Sitecore 7, which was an interesting (and busy!) day learning about what's been changing in Sitecore in recent releases. But in amongst all that information, there was an interesting admission – Sitecore's training has moved away from the "stick your Visual Studio Solution in the Sitecore website folder" model that had jarred with me when I first did their training.
I didn't really like this model when it was taught at the original Sitecore training I attended a few years back. Before Sitecore I had done all my development work with my solution folders outside of the IIS sites. So the model I adopted for development when I started my first real project made use of MSBuild instead. (Rather than the Visual Studio Publishing wizard that the latest training discusses) So I thought I'd write down a few of the things I'd tried for setting up solutions, in case these of use to anyone else...
Working on some components for a client's site recently, it struck me that there were circumstances where it would be helpful to editors to allow the "Select Associated Content" dialog to have multiple options without just showing the whole content tree. Scenarios like having both a global shared content folder and a sub-site specific shared content folder that editors could choose between, for example. Something that looked like this:
