EPiServer is a great CMS but like all platforms it has a number of traps for the unwary and inexperienced. The following are some of the more common mistakes made during EPiServer development projects.

Doing anything directly to the EPiServer database

Touching the EPiServer database can be so tempting sometimes. After all, just one little stored procedure can't do any real harm can it?  Believe me - it will end in tears somewhere down the line and you should only work through the API. The database is not for developers to touch and you'll  be completely on your own with any unexpected bugs created by your tampering.

Going Composer crazy

Composer can be a fabulous tool for delivering flexible page layouts but some solutions do go a little over-board. Too many Composer functions undermine page performance and can make life more difficult for content editors. You should consider your site in terms of a set of content types that are augmented by Composer. I have seen solutions get completely out of control requiring hellishly complex combinations of Composer functions to build a single page. Given that Composer layouts cannot be translated then multi-lingual sites can be particularly handicapped by Composer over-use.

Forgetting the editor

This is a common problem with CMS builds in general - we are so concerned with delivering value to the end user that we can forget about the poor old content editor. Improving editor productivity is often a driver for putting a new CMS in place but is something that can be fogotten once the "fog of war" descends onto a developnment project. When you're designing functionality you should always bear in mind that somebody may have to use this day-in and day-out.

Dynamic properties

Dynamic properties are anything but dynamic - the API has to wind up the content page tree to determine their values so they should be used sparingly if at all. EPiServer do warn you about this but it's suprising how often you see sites that are peppered with dynamic properties. There is almost always a better solution than reaching for a dynamic property.

The dynamic data store

Does a web content management system really need a "big table" implementation that stores its data in a relational database? It feels like an internal R&D exercise that should have stayed private. The danger is that developers will use it in lieu of good object design to create a big, anonymous bucket of stuff where you can only view the content via an API. Potentially quite dangerous.

FindPagesWithCriteria abuse

You should appreciate what goes on under the hood with FindPagesWithCriteria. It's just forming a bunch of SQL statements so the usual rules of recordset management should apply: don't make your queries too complex, don't return too many results and don't use it any more than you really have to.

The slowly strangled page tree

When you develop a site you should always bear in mind how much content is likely to be there after a few years. A slowly expanding site can create slow-burning problems that kill performance. News archives are a particular problem as the content tree can grinf to a halt while EPiServer loads the hundreds of child pages that you didn't plan for. Always plan for scale and organise your content accordingly.

Not using PageTypeBuilder

Anybody out there still hand-cranking their templates and accessing properties through magic strings? Really?

Memory complacency

EPiServer's performance depends on its ability to leverage memory. The page data cache is all-important so there is a tendency to assume that an EPiServer site will always consume a lot of memory. This can lead to a form of complacency where sites that are clearly in trouble are left to consume vast amounts of memory unchecked. As Svante Seleborg recently pointed out, 1GB ought to be enough for any EPiServer site and if your site uses more than this may be a symptom of a wider problem that needs to be investigated.

Filed under Architecture, CMS and Design patterns.