Getting your Sitecore project right

Still a very relevant blogpost – from 2011


This post is for you clients who have already selected Sitecore as your new website platform and is starting up a new Sitecore project.
Here are a couple of my thoughts on how you can get your Sitecore project on the right track from the beginning, by setting the stage for a good collaboration with your implementation partner.

The website you a building today should also be the website for tomorrow and hence the website you are building should be extendable, flexible and scalable. It is absolutely possible to build a Sitecore web platform which will last many iterations – considering that you take this into account early in the process.

Select your implementation partner carefully

Your implementation partner is the single most important collaboration partner in your project. They bind everything together; requirement specifications, user experience design, hardware, software, domain knowledge and more, and is therefore crucial for the…

View original post 778 more words


“Estimate” – redefine or new term?

About once a year I have a big discussion with one of my colleagues about the concept of estimation. From a professional point of view, we come from different backgrounds. I am a developer and technical architect, and he comes from a background in project management and communication. This year we came to a conclusion that our disagreement is not in what the craft of estimation is or what an actual estimate is – but rather how to approach the common perception (or misperception) of an estimate.

Most people think of an estimate as the number of hours required to solve a given task. If we assume that this is the actual definition, we would have to assume that the task is well defined and completely fixed and this is always – yes, always – not the case. The Cone of Uncertainty (http://en.wikipedia.org/wiki/Cone_of_Uncertainty) states that an estimate is never precise (the uncertainty zero) until the task is complete – in other words: both the task at hand (scope, requirements, possibilities etc.) and the number of hours (or sum of money) required to solve it is nothing more than qualified guesswork. We all know this, right?

A fact of the matter is that quite a lot of our clients are not agile. In essence, they do not accept risk in an IT project, and trust us to carry that risk. This means that clients need to know the price of a given requirement before commencing on the work, which means that we have to estimate the “number of hours” required to solve “a given task” – and that the number of hours will not be flexible. Which bring me down to the greatest misconception of the above definition – that the “given task” is also not flexible.

For a great many years I have been one of the lucky developers attached to technical presales – and thereby responsible for estimation in the sales process. Now, if I had a penny for every receiving developer who has moaned about the “number of hours” on my estimate I would be a very rich man. In other words, it seems that many developers think that the “given task” is as fixed as the number of hours – why else would they moan about the hours instead of spending time on resolving how the solve the task within the timeframe? In these developers heads, there is only one solution to the task – and the problem is therefore the number of hours given to this solution. In my experience, there is never just one solution to a given task.

Coming back to my discussions with my colleague: What we agree, is that we need to emphasize – both to our developers and to our clients – is that in a fixed price project, the flexibility lies in the tasks, not in the number of hours. The disagreement is how we emphasize this to our clients and developers.

Call me an idealist or a dreamer, but I still think that key lies in communicating a broader definition of an “estimate”; something that makes it obvious that there is so much more to an estimate than a one-liner task description and a number.

I suggest the following definition of an estimate:

The assumed volume of a task with the knowledge of scope and value at a given time at with a given experience.

This definition emphasizes knowledge of scope and value, as well as context such as the time of estimation and the experience of the estimator. I know it’s not an easy definition, but I think the emphasis is important.

I know that I should probably back down and realize that the common misperception of an estimate is going to be dominating – but that would mean that I would have to let my colleague win the discussion. And I am just not ready for that…


Sitecore Symposium 2012 – Hopes and Expectations

Tomorrow is the Sitecore Symposium 2012 in Amsterdam. I am going and here are some of my hopes and expectations as a Sitecore technician and architect:

Wednesday 9:15, Keynote

First of all, Sitecore has been waving version 7 in our faces for a while. The last year’s conferences were full of promising new features – will this be the time when we hear something concrete?  I therefore hope (although not exactly expect) to hear a keynote with a working demo of Sitecore 7. Michael Seifert is growing into a fantastic speaker, so if he has the product, he will be able to deliver the wow factor.

Wednesday, 15:30: Developer Track, Multiple Ways to Multisite Solutions

One of the eye-catching sessions for me has got to be the multi-site session by Tim Ward. Over the years, we have pretty much delivered multi-site solutions to ALL our clients. I’ll be interesting to get the official Sitecore take on the problem. Furthermore I am very comforted by the fact that Sitecore actually has a take on it – given the problems we have faced historically with lack of multi-site support in some of the official modules.

Wednesday, 14:15: Sponsor Track, Preventing the Language Chaos
Thursday, 11:15: Sponsor Track, Sitecore Translation Strategies and Techniques: Which One Is Right for You?

During the conference, there are talks by two translation/localization vendors: Clay Tablet and Lionbridge. In the last years translation support is one of the key features our enterprise clients request, and it’ll be interesting to see if the vendors gives us some nice technical integration tips. Although I must say, I do expect sales pitches from both sessions.

Wednesday, 15:30: Sponsor Track, Best Practice for Performance Tests Within CMS Installations

The Sitecore Partner Apica has a session about performance testing and best practises. Seeing that this is a techie talk on the sponsor track (which in itself is a contradiction in terms) I’m hoping for a surprise wow experience.

Wednesday, 16:30, Product Track: Building, Connecting and Measuring Communities with Sitecore

Social media and social web features are seemingly always very important to our clients – and why?  “Well because everybody else has it”. In this light, I’m expecting John Field to give me some Sitecore recommendations on how to prove the value – or lack of same – to the clients. Secondly, Sitecore recently purchased a large share of the Danish Facebook integration company KOMFO – I’m hoping for the conference to shed some light on what this collaboration could mean.

Wednesday, 16:30, Sponsor Track: Sitecore and Salesforce – A Compelling Case for Unified Customer Engagement

During the last year, a number of our clients have shown a very keen interest in the CRM integration part of DMS – turning their website into a direct sales tool, integrated with their sales department’s weapon of choice. A nicely done Salesforce/Sitecore integration could give us an additional tool in our integration toolbox.

Thursday, 9:00, Developer Track: Breaking a Million with a Bucket of Items

Buckets are in my world, the next HUGE thing in Sitecore – and something which have been waved around our nose in years. I hope to see massive amounts of data, easily indexed and faceted AND extracted with a nice and neat API. And how does the bucket data tie in with the hierarchy that we know today? Furthermore I hope – well I might even venture an “expect” – to see the concrete implementation and a glimpse of Sitecore 7.

Thursday, 12:15, Product Track: Sitecore Roadmap – Where Are We Going with the Product

This I guess is always a conference must-see. This is where I expect more Azure integration, more social media stuff, more enterprise features, closer integration to ERP and CRM, more app center services from Sitecore etc. etc. Although I hope to see a glimpse of what’s beyond Sitecore 7 and, pretty please, some focus on integration and the development community – and not just new features.

Thursday, 14:00, Developer Track: Become the Marketer’s Best Friend ̶ Using the DMS API to Extremes

The DMS API has never really had any success with the developers within Pentia – and in my view for a good reason: It’s simply not good enough. It just doesn’t have the sleek interface and neatness that the core Sitecore API has. Therefore I’m hoping for an introduction to a clean DMS API in Sitecore 7, although I must admit that I’m expecting an attempt to woo us developers with some features in the current API.

What are your expectations? Hope to see you there!

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.


Hidden functionality: The XPath Builder

Maybe it is just me, who never found it, but after a support request I was made aware of a feature in Sitecore, I have missed for years. I thought I’d just share it, if there were any others like me, who wasn’t aware of the great Sitecore application XPath Builder.

Whenever I create a template which uses a Sitecore Query to populate a multilist field with items, I always spend a little too much time figuring out the correct syntax for the Sitecore Query. But no longer… now that I have found the XPath Builder!

The XPath Builder is triggered in the Developer Center through the Tools menu. The application helps you build the right query and shows the result of the query:

Sitecore XPath Builder

The XPath Builder in Sitecore

Yay! What a great tool!

New releases, Sitecore, Uncategorized

What TODO – in Sitecore 6.3

Sitecore 6.3 was recently released. A lot of great improvements was included in this version – for instance support for multiple backend web servers and Windows Azure support. Read more about it in Marco Tana’s blog post and read more about the event queue on Adam Conn’s blog.

Besides these new features  a huge amount of bug fixes has been included. Some of them quite important; some of them quite funny…

Almost two years ago I wrote the blog post What TODO? In short I described the somewhat weird way of marking TODO’s by the kernel develepors at Sitecore. Well guess what… In Sitecore 6.3 they thought they would finaly do something about it. It has now…. been marked as obsolete (?!).

“The Sitecore.Todo class has been marked as obsolete. (323278)”

I must admit it made me laugh again. Why not just remove it, when you decide to do something about it?

.NET, Architecture, Sitecore, Uncategorized

5 worst code smells in Sitecore

Last year I wrote a blog post on doing code reviews on Sitecore. While dealing with conceptual issues it doesn’t really say what to look for in code, when evaluating the quality or to evaluate if any wrong decisions have been made when developing the solution.  Therefore I wanted to wright a post about the top 5 code smells I look for, when I am trying to evaluate or trouble shoot a Sitecore solution. These code smells often indicate that the developers have gone down the wrong road and there is something fundamentally wrong in the architecture.

So here goes:

1) Using the descendant axes in xpath expressions:

This one I especially look for, when I am looking at a site which doesn’t perform. It may be used in some cases, but very often I find that a developer has used this to generate relations between content and thereby iterating over the complete content tree. This works fine in development where there are a few hundred content items. However in production where thousands of items are created this simply breaks the performance of the site – especially after publishing which clears the HTML cache.

The descendants can be accessed in multiple ways. In XSLT it normally looks like this:
<xsl:for-each select=”$sc_currentitem/descendant-or-self::item”>
</xsl:for-each>Or like this:
<xsl:for-each select=”$sc_currentitem//item”>

In C# using the Sitecore API it is most often accessed like this:


2) XSLT Import:

This is related to a point in the post about code reviews on Sitecore, where I argue that overcomplicated functionality and logic in XSLTs, is a problem. If you need to do an import of another XSLT in your rendering, you probably do it to call a method or in another way try and reuse functionality. If you want to do this, don’t use XSLTs! XSLTs should only – if you really want to use them at all – hold simple presentations.
XSLTs can be imported like this:

<xsl:import href=”YourOtherXslt.xslt” />

3) Explicitly accessing the master database

Although this can be needed in some cases and especially in scheduled tasks or other backend functionality, most often it is because the developer haven’t thought the issue through or if they have made a wrong decision of how data entered by the user should be stored.
The master database is most often used like this in c#

Database masterDatabase = Database.GetDatabase(“master”);

If you see a call like this, your solution is most likely not ready for staging, where there is no access to the master database from the content delivery server. You should generally use something like this:

Database database = Sitecore.Context.Database ?? Sitecore.Context.ContentDatabase;

This means you operate on the context database and on the content delivery databases this will be the web database and in preview you will use the master database, which is probably what you want.
If you need to write something to the master database, you first need to decide if this is a good idea at all. If you write to the master database from your frontend, you make yourself vulnerable for malicious attack, as people from the outside can enter data into the master database. Normally we handle user entered data in a custom database or parse all user created content to ensure that the master database won’t be flooded with data.
If you really need to access the master database, you should create a service that handles access to the master database, so that your solution is ready for staged environments.

4) XSLT extension over 100 lines of code:

This point is closely related to point number 2, but I really see a lot of issues with XSLTs which have been used wrong and this creates a lot of issues later on in the project lifecycle. If you have an XSLT extension with over a hundred lines of code, chances are, that the developer made a wrong decision when creating the XSLT; instead he/she should have created a sublayout.
XSLT extensions are functional programming and you should use an object oriented approach, so my advice is not to use XSLTs at all, unless you are doing something really simple. Otherwise your solution will become harder and harder to maintain, as utility methods like the XSLT extensions are very hard to understand and couplings in the renderings themself are difficult to map.
You can find all registered XSLT extensions in the web.config under xslExtension and it looks something like this:

  <extension mode=”on” type=”MyNamespace.XslHelper, MyAssembly” namespace=”http://www.example.net/helper” singleInstance=”true”/>

5) Clearing of cache

This may seem obvious to some, but I have seen surprisingly many methods, which cleared the entire Sitecore cache including the data and item cache. If you see this in your code and it is needed, chances are, that you have an architectural issue in your solution. It should most rarely be needed to clear the cache, unless it is after a publish and Sitecore handles this automatically. I have heard many reasons for clearing the cache including an issue, where the developer argued that it was necessary, as he wrote directly to the Sitecore database with a SQL statement, and then Sitecores cache wasn’t updated.
If you experience something like this, the issue is of cause not the cache, but that you don’t use the Sitecore API to read and write data from the database.
The caching is most often cleared like this:


This is just some of the things I have seen many times, but I know there are many other bad code smells when developing Sitecore solution. Do you have any other code smells to share?


Sitecore MVP event at Dreamcore Europe 2010

Dreamcore Europe 2010 - Sitecore MVP event

Pentia Professional Services and the Sitecore MVP’s of Pentia, invites all Sitecore MVP’s to attend an evening event before the Dreamcore 2010 by Sitecore conference – and absolute free.

The purpose of the night is primarily networking and social get-together, but during the evening we will provide an opportunity for you to share your best case stories, as well as join in a roundtable discussion on the future of the Sitecore platform, e.g. covering topics such as: “In which direction do we want Sitecore to move“, “What are the successes and failures of the Sitecore platform today“.

The event will take place Tuesday the 18th of May at 5pm, the evening before the Dreamcore conference. It is hosted at Pentia’s charming domicile located a stone-throw from the Dreamcore venue, and is concluded by a dinner at Copenhagen’s premiere steak gourmet restaurant, MASH.
Sign up now for the Sitecore Dreamcore MVP event
If you are a Sitecore MVP, and want to get together with your peers and discuss the platform you love – Sitecore – then sign up now!

Read more on the agenda, venue and how to signup, at the Pentia website.


Content and presentation separated – part 2

Following up on my previous post about content and presentation separation , I realized that separating presentation and content is extremely important, if you want to utilize some of the new features in Sitecore such as the page editor and the new rule engine . These features let the end user meddle with the presentation which gives quite a few nice features. For instance an editor can add a rendering to a given page in a rich and intuitive GUI and set up rules for a visualization of a certain rendering.

The problem, as earlier discussed, is what to do with “presentation content”. With presentation content I mean settings or similar. For instance take a rendering where you want to present a list of news, which are all descendants of a specified root item. This rendering needs the following settings: How many news items to show, a root item, a read more link etc. Normally I would put these properties on a template as fields. However this would bind the presentation to content and the sublayout or rendering would only work on an item, which is derived from that template. As the end user can now meddle with the renderings and add or remove them at will, he will have to know the dependencies to different templates, which is practically impossible. 🙂


So what is the solution to this problem? Well as fare as I can figure out, you need to use the datasource and parameter properties on the rendering instead. However this introduces some issues when it comes to usability, as it is now the end user who needs to set these properties. Sitecore has a really rich and user friendly interface for altering content, but for some reason the UI for setting properties on a rendering/sublayout is rather hopeless. There is only one field type – a simple text field. So when you need to set an external or internal link you need to enter it as simple text. No lookups, nothing. Further there is no way, to my knowledge, to create validators for these fields, so you aren’t able to help the editor.

So for this to work Sitecore needs to implement a better UI or use the content editor to allow editors to configure renderings. I sort of figure it would be quite nifty, if there was created an item, whenever you add a rendering. The item should be based on a specific template for the rendering type, which would mean you could create different templates for different types of renderings and thereby control which parameters would be needed. This should be completely transparent for the editor, which wouldn’t notice that an actual item was created, except he would get the user friendly interface of the content editor.

This would give better usability and thereby allow a better separation of content and presentation (and the content needed by the presentation).


The end user issue doesn’t stand alone. Recently I implemented a sublayout, which should read some parameters. If I have done this in a best practice way, I must admit, that the API for reading parameters is completely hopeless. Check it out on SDN. What? Is this really the easiest way? Further the parameters data type is a concatenation of strings much like query parameters. This is quite frustrating as you have to parse the string or use the .net UrlString class to extract a specific parameter.

Adding all this together and adding different validation of the parameters made my class turn into one long unreadable mess.


The conclusion? If you want to separate content and presentation you lower the capabilities and usability for the editor and make your code one big mess. Either that or I am doing something completely wrong.

If Sitecore really wants the editors to meddle with presentation, they should really improve the UI and API for sublayout parameters and similar.


Sitecore Continuous Integration Continued

Here’s an update on the post I wrote a year ago on our Continuous Integration project here at Pentia.
To put it short: it’s turned out to be one of the most successful internal projects in our company. In the last year we’ve added 20+ new projects into the system, and we are in the process of moving our old projects from SourceSafe to SVN, and creating build files for them.
Our setup is not a conventional build setup with specifically designed build scripts for a major project, it’s more of a build framework for the many Sitecore project passing through Pentia. We’ve designed our setup around our naming and location best practises, so in order to add a project to the build system, we only need to create a single file with about 10 lines of XML specifically for the project.

Our entire setup consist of:

1: nAnt build framework
This is a set of approx. 30 nAnt scripts which is shared across all our projects. The scripts handles everything from SVN, MSBuild, FxCop, deployment, zipped releases, automatic versioning and much more. The files are versioned so that changes and new features will not influence the older projects and break the builds. In the last year we have released 5 versions of the nAnt scripts.

2: Subversion version control
In my approx. 15 years of programming I’ve only worked with Visual SourceSafe as version control (and as those of you who knows the product knows, is hasn’t changed for 15 years either :-), so the switch to SVN has been a daunting task for me. After a year, my only recommendation for those of you who consider it is to go for it! Subversion is easy to install and maintain (I recommend VisualSVN Server), easy to use (TortoiseSVN) and the integration into Visual Studio (VisualSVN) is perfect. Naturally the integration with nAnt is nice too as. E.g. it made it possible for us to automatically version our projects when releasing, by extracting the latest revision from SVN.

3: CruiseControl.NET
The hardest part to integrate into the company has been the CruiseControl.NET server. It’s not difficult to explain its purpose to the developers (to continuously check the projects on commits in SVN and build nightly releases), but the benefits of the other parts of the setup, for the individual developer has just been so much more evident. But still, its running, checking our builds and keeping our internal testing environment updated, by releasing each night.

4: Module library
The module library is a really neat feature of our build system. In short, it allows us to only maintain our own codebase in a project in version control and still allows developers to get quickly up and running, not making it necessary to install Sitecore version and thirdparty tools on their local machines. In the last year we’ve added 12 versions of Sitecore, 16 Sitecore modules (with 3+ versions each), 10+ third party modules like PDF, FTP and unit testing, and much more. The library allows us not only to add our old projects to the build system, but the cool thing is that when e.g. a new update to Sitecore is released, all our projects can be upgraded by changing a single line in the project build files.

5: Configuration merging
Both Sitecore and Microsoft has acknowledged the problem of mainting large configuration files. And the both have features which allows config changes to be merged from external files. The only thing they do not make easy, is to have different configurations for the different environments. For this we’ve developed a nAnt extension which allows the developers to create configuration merge files (configmerge files) which can be varied according to the environment we are building to. This has made a huge difference as opposed to juggling different configuration files for production/test/training/development environments for frontend and backend servers (6-7 web.configs!).

6: GUI tools.
We have lazy developers in Pentia 🙂 Joke aside, we quickly acknowledged that in order to successfully get the system to the developers, we had to provide them with better tools than the nAnt command-line and CruiseControl xml files. So we created a nice GUI for our nAnt scripts and for editing our CruiseControl server.

As you can hear, I am still pretty excited by the accomplishments we’ve made in the last year – and we have a lot of cool features waiting. Our next release will incorporate generation of SQL scripts for mounting Sitecore databases and setting up database access and automatic IIS setup. We also want to automate our releases even more, by generating batch files for folder security and automated FTP upload to the production servers.

I’ll still be happy to hear from anyone with experience or ideas – or you can give me or Pentia a shout if you want to hear more about our setup.