.NET, Architecture, publishing, Sitecore

Drawing the customization line

Sitecore is an extremely flexible system; in fact most of Sitecore is built with the extensibility and customization functionalities which is provided. This includes pipelines, events, commands, SheerUI, providers and more. All in all: there is not much which cannot be achieved in Sitecore and only the imagination of you and your client sets the limits of customizations – and believe me, in my work of helping out clients and Sitecore partners all over the world, I’ve seen Sitecore completely twisted in many ways. I’ve seen Sitecore’s entire layout engine replaced with an item based layout definition, with subitems representing placeholders and subitems representing presentation elements. I’ve seen publishing and item saved pipelines so crammed full of custom functionality that performance was non-existent and I’ve seen XSLT’s with one line of code: a call to an extension function which would return an entire HTML structure as a string.

So where do we draw the line in the holy name of bending functionality and giving the customer “what they want”? Remember:

  • Convincing the client to choose standard functionality is also an option.
  • Each change of standard Sitecore functionality is potentially expensive – for you and for the client.
  • If possible, do not replace Sitecore functionality, extend it.
  • Think about what you put into Sitecore: Content and functionality can be accessed through .NET code and does not necessarily need to be added to the Sitecore DB’s or in a pipeline.
  • Keep track of your customizations – source control it and document it.
  • Remember that your customizations will have to upgrade with Sitecore.
  • Stay true to yourself: If it feels wrong, don’t do it.

In short, just because you can does not mean that you should:-)

Standard
New releases, publishing, Sitecore, Uncategorized

Dedicated image server in Sitecore – part 2

I have earlier blogged about setting up a dedicated image server for Sitecore here. The implementation required some customization of the LinkProvider, but from Sitecore 6.3 it is possible to achieve the same just using configuration.

A dedicated media server can be used to serve media on a separate URL, so that you can optimize performance due to limitations on the amount of connections the browser can open to the domain, which I also described in the last post. Further it can be used to optimize your server for handling media and supporting a CDN.

As mentioned it is now possible to have a separate server for media by configuration. In this scenario you might have a dedicated publishing target for media, and this should just be a standard Sitecore installation, which then only handles media by directing the DNS for your image URL to this server. For instance I have setup three Sitecore installations – one as a content manager server, one as the dedicated image server and one as content delivery server. The domain for my content management server is http://sitecore63/, the one for my image server is http://sitecore63imageserver/ and the content delivery server has the domain http://sitecore63cd/. What I then want to achieve is:

  1. That my content management server serves images in the normal way, so that the editors can insert, alter and preview images without having to publish.
  2. On my content delivery servers I want my images to be served by the image server.

The first goal is easy. I just leave every configuration to the standard. This means that the content management server serves media itself.
The second goal requires some configuration changes. On the content delivery servers I must make all media references point to the image server. This can be done by setting the Media.MediaLinkPrefix in the web.config to the domain name of the image server plus the media prefix I want. For instance like this:

<setting name=”Media.MediaLinkPrefix” value=”http://sitecore63imageserver/~/media/” />

This means that all media items on the content delivery server(s) will be prefixed with the above url:

<img width=”128″ height=”128″ alt=”” src=”http://sitecore63imageserver/~/media/Images/user.ashx?w=128&amp;h=128&amp;as=1“>

So in this scenario the html is delivered by http://sitecore63cd and the image is served by http://sitecore63imageserver. In the content management environment, the media is served locally. Now this is a lot easier, than the customization you needed in older versions of Sitecore.

dedicated image server in sitecore

If you want another media prefix then the standard /~/media, you also need to make the media server handle these requests as media. This is done by adding the prefix to the <mediaPrefix> element in the web.config and add the prefix to the customHandlers section in the web.config.

Standard
publishing, Sitecore

Publishing strategies

Publishing can be quite an issue for content authors and make an impact on performance. However if you use the right strategy, there really isn’t any issues.

One of the issues with publishing can be performance. When you publish one or more items the HTML cache is cleared, which means that if you have some performance heavy presentations, it will increase the loading time of the page, until the cache has been rebuild. Further if you use the staging module and it is configured to it, all the data caches are cleared as well. This can cause the site to take up to 30 seconds to reload your pages – especially if they are data heavy. You can read more about Sitecore Caching here and read about the issues with cache and the staging module here.

Note that Sitecore recently released a staging module which supports partial item caching, but the HTML cache is still cleared. You can read more about the new module on Alex Shybas blog.

I don’t know if performance impact when publishing is specific to Sitecore or is generally a problem in most CMS’, but I reckon it is the later. However Sitecore has a special problem with regards to caching. As Sitecore isn’t page based as many other CMS’ (this is also one of its biggest advantages), it makes it difficult to have a partial cache clearing – especially with regards to HTML cache. A page can be constructed by several content items, and there are no immediate binding between a page and the items, which it is constructed of, so all HTML caches needs to be cleared even though you just publish one item.

Another issue is the usability for content authors. Some of our clients were complaining about being queued all the time when they initiated a publish and it could take a very long time before they got their content published. What often happened was that when they initiated a publish, the modal dialog reported, that they were queued. Instead of waiting for it, they closed the window and continued editing. A few minutes later they would initiate another publish, but was once again told that they were queued. When this process repeated itself for the 50 active content authors, you can imagine the queue could get quite big.

Another thing we stumbled upon was, that some content authors used publishing instead of preview. Every time they wanted to view their work in progress to check if it looked alright frontend-wise, they published the item and viewed the page as if it was already completed and ready for actual publish.
I know we are not the only Sitecore partner experiencing this, as I have talked to other implementation partners and received questions about it on Learn Sitecore.

So why do I suggest it isn’t a problem? Well… we aren’t really experience any issues with our clients or with performance issues caused by publishing anymore. This is a result of more than one thing, but the primary solution was to use scheduled publish.

I don’t know why, but using this publishing strategy this can be a really big issue for clients. We often heard remarks like: “We need to publish content immediately”… But common! I really haven’t worked with many organizations, where this is an actual issue. What content do these organizations have, which is so important, that they can’t wait 15 minutes (at tops) to be published? I have consulted clients with huge sites, which is absolutely critical to the business and the funny part is that these companies rarely have a need to have immediate publishing. They are normally used to having a longer waiting period for the rest of their web services due to replications tasks between 100s of servers and rebuilding of caching. So why do the smaller companies have a bigger need for immediate publishing? The short answer – they don’t!

So what do we do to convince our client to use scheduled publish? We do more than one thing: First of all we explain to them, what impact publishing has. Then we allow a single or a few admins to have publish rights, so that they can have immediate publishing. Further we set the “do not publish” mark on all newly created items, so that they won’t be accidently published while they’re not finished. The authors will have to unclick the setting, when they think the item is ready for publishing.

Finally we have developed something, which in my opinion is rather cool! We acknowledged that people respond best to waiting time, if they have an indication of when the waiting will come to an end. This fact is also one of the reasons why they have timers on traffic lights in Copenhagen:

Traffic light with timer

7 seconds to green light 🙂

We decided to use the same strategy for scheduled publishing. If the content authors would know, when the next scheduled publish is due, they would be much more satisfied with the idea of not having immediate publishing. So we – in Pentia – developed a timer which is shown in the task bar in Sitecore: 

scheduled publish timer

The scheduled publish timer in action

The “Trinvis udgivelse” is Danish and mean incremental publish. So this timer tells the content author, that there is 12 minutes and 48 seconds to the next incremental publish. The functionality also supports multiple timers, so on some solutions we also use it to indicate, when an import from an external database is due and so forth. Cool, right?

These things combined we really don’t have any issues, with convincing our clients to use scheduled publishing.

Standard