March 06, 2013
For those who have experience implementing Sitecore, this post is not for you. Sitecore has been very busy evangelizing and "selling" Sitecore and we now have a vast community of new Sitecore developers and users. For those new to Sitecore, I’ve written out a list of some common mistakes to avoid. Just like riding a bike, once you learn these, they will come naturally.
Not changing the admin password before production
Duh! I don't think I need to go further on this.
Giving users the all powerful admin role
I guess this might be appropriate in certain situations, but there is the issue of too much power to consider. Too much power can lead to many “gotchas” such as changing settings, updating templates, etc. It allows the user to have more option to do things which leads to inconsistencies. Lastly, if everyone logs in with admin privileges, versioning needs to be manually done.
Not thinking about your authors
You should never consider a CMS as just a platform to develop the resulting website. Imagine you have to build the Admin UI so that your authors can update the site. I'm sure you've done something similar before. When you did that, didn't you have to consider how easy it would be for them to perform the task? Why not think the same way when building the site on Sitecore?
Using the web.config file for your own implementation
You may need to do this if you're upgrading or installing, but since Sitecore introduced external config files, there's really no need to update the web.config file anymore. If you've installed Sitecore modules, you'll notice that they normally include their own config files under the /App_Config/Include folder. As an ASP.NET developer, I know that you're used to using the web.config file for your applications, particularly the appSettings. But, if you use Sitecore's way instead, there are readily available APIs under the Sitecore.Configuration namepsace.
Translating a page comp to a content item
Beware of the trap that a design comp equals a data template. This is simply not the case. A web page is normally a collection of content items. Identifying the various types of content within that one page comp is crucial to having a flexible architecture (just don't over-architect it). This will also help you to enable support for Page Editor as well as reusing content on multiple places.
Getting hung up on whether to use sublayouts or XSLT
Just pick one or do it as a hybrid. There has been so much debate on this and I don't plan on getting in the middle of it. Besides the technical pros and cons, I would rather look at the business reasons as well as personal taste. By default, Sitecore developers are .NET developers, so it normally makes sense to stick with sub-layouts. But, in the end, you'll probably explore both for curiosity sake.
Not thinking about deployment
I mentioned this point in a previous post (Signs that Your Sitecore Project is in Trouble) and I want to mention it here again. Many new Sitecore developers are bound to their workstation and IT may not have been prepped yet for Sitecore. Although it doesn't take much to install Sitecore, there are IT considerations we need to plan for such as secured connections, DB inside the firewall, possibly an Active Directory connection, or a Web Form that gathers data on the site but the data needs to go to the Master DB. These are things you normally do not think about when coding in your workstation.
Turning on DMS Analytics from the start
This issue is important if you are building a site with really high traffic. With a project like this, you will probably need more help and may have experts around you. But, if you don’t, it is not recommended to have Analytics on without any prior planning on how you are going to use it. You could find yourself out of DB storage.
Forgetting about handling typical HTTP errors
Since Sitecore essentially traps every request on your IIS, you need to make sure that you address standard errors like 404, 301 redirects, and the dreaded system error. Make sure you know how to handle these and that you do so accordingly. Otherwise, users may see the typical Sitecore error pages, which is not always appropriate.
Not nesting data templates
This is one of the most powerful features of Sitecore and should be familiar to .NET developers. It almost mimics class inheritance and you should know how useful it is. In the past, you couldn’t do this; thus, a lot of the templates had fields that are essentially the same, like the Title and Body fields. Sometimes you can't refer to these fields with their ID as they may have different ones. Using nested templates allows us to organize content a lot better and also minimizes the number of templates needed.
As a new Sitecore developer, it can be overwhelming to see all of the options or even the openness of Sitecore. I hope this gives you some initial insight on how you should proceed with your first Sitecore project. These common mistakes to avoid should help you when developing your project plan.
comments powered by