Exciting developments with Sitecore 7

The developers behind Sitecore 7 have just treated us to an in-depth look at their new search API and other features and fixes coming in the next release. These changes mean it will be possible to manage a huge number of content items without experiencing performance issues — a big step forward. We were also excited to find that there’s new functionality throughout the UI that will enable editors to choose which content to display with powerful but easy to use search features. Naturally, our thoughts turned to what this will mean for our existing clients and sites.

For example, Oxfam needed a platform that would allow them to create new sections of the site and new types of content pages quickly without needing further development. We were able to provide them with this by building a toolset of components they could use to create pages to meet new requirements; they can select an appropriate layout, and use the page editor to add the most suitable components and content for their needs.

This has generally worked really well for them, allowing them to react quickly to change and communicate new messages to their users without having to go through a development cycle. However, this does mean the editors have to manage a large number of content items; at times, they’ve found it a challenge to keep them organised. They also need to be careful when moving content as this will break links (set in data sources as paths).

Will Sitecore 7 help?

Well, from what we’ve seen, yes!

The first big win for us is that data sources can now be linked by the item ID rather than by path, and are included in the links database. That means items can be moved and reorganised without breaking pages. (And if you read on, you’ll see this might not even be an issue anymore if you make use of the new features for managing content items.)

In Sitecore 7, you can manage large numbers of content items in ‘buckets’. Editors won’t need to organise them into a hierarchy any more or try to remember where they are; instead they can just add items, tag them if they want to, and then search for them when needed. It’s a bit like the revolutionary changes that Gmail brought to email — don’t organise, just search.

For component based sites like the one we built for Oxfam, you’ll be able to select a particular item of content to show when adding components to the page. And now, you can also use search. So if you have a carousel or a featured item list, you don’t need to preset the criteria for content to show (for example items in a particular folder); now, you can put that control in the hands of the editor, allowing them to build up a search for relevant items from page editor.

Where does that leave us?

The next step is to gain a greater understanding of what these changes might mean by building some prototypes in Sitecore 7 and seeing what we find. I’ve already started on a demo site with an initial release of Sitecore 7 (just for Sitecore MVP developers at the moment) and will report back on our findings soon, but all the signs certainly look positive.

One thing we also need to think about is what happens when a page is published. This content that is pulled in from a ID or a search will only show up on the live site if it has been published explicitly — this means the editor still needs to pay close attention to what content has been made live. The other option is to write a custom pipeline to publish the related items along with the page. This is something that we’ve done for the previous version, so we’ve already got some ideas on how to implement it differently with Sitecore 7.

So, in summary, we’re pretty excited about what Sitecore 7 can do, and even more excited to discover how we can use it to provide our clients with the solutions they need. Watch this space!