Over the years, I have worked on some really good projects and I’ve also worked on what could have gone a lot better. Hindsight is a beautiful thing to have, but without learning from mistakes, you’ll never design world class solutions. With that in mind, in today’s guide, I’m going to cover some common mistakes I see on projects.
Modifying The Episerver Database
Thankfully, I haven’t come across anyone doing this in a number of years… although I have heard people entertain this thought in muttered mumbles around the coffee machine. My number one tip when it comes to changing the database.. if you think you need to do it.. the architecture of your design is wrong. Take a step back, breath and think about the different options available to you. You must ONLY work through the API. If you need something custom then use your own database, but the Episerver database is not for developers to touch.
Forgetting Content Editors
This is a common issue I have seen in pretty much any CMS project I have worked on. Everyone is so focused on shipping they do not give the poor content editor a second thought. As a business solution, if the people who will be using Episerver all day, every day, hate it.. then your project can never be considered a success. There are a number of things you can do to improve content editors lives. I’ve talked previously about things like, How To Sort The Tab Order In Your Episerver Pages Or Blocks, How To Return Different Validation Warnings To Content Editors When Publishing In Episerver and Defining The Available Page Types Allowed To Be Created Under a Page in Episerver to name a few.
Having an unmanageable page tree
When you develop a new project, you may only be working with a few pages, but, after a number of months and years, content gets added and the page tree grows to unmanageable length. People can’t find content, some things might be duplicated, in some extreme cases your site might even slow down to unusable levels. Things like blogs or new sections are prime candidates for these types of evil issues to raise their heads.
The best tip I can give you is to create a custom container page type in your project and force content editors to use them, via restricting the child page types. More information about how to do this can be found here.
I have talked previously about the dangers of FindPagesWithCriteria. Under the hood, FindPagesWithCriteria builds a bunch of SQL statements that query the database directly. There is NO caching when you use this. When you use FindPagesWithCriteria, you need to be careful that you don’t overuse it. If you are using this a lot, consider using a third party cache provider, like InProc, or, Redis to help take the load off of your database.
For more advice, I recommend reading this article.
Organising Your Blocks and Media Gallery
This issue is also very similar to the issues you may encounter with an unmanageable page tree. The more content you add, the harder it will be to manage unless you have a basic system in place to manage content. Some of the different ways I’ve seen people organise their folders include:
- Alphabetic and numeric folder structure
- Grouping the content into folders by language
- Grouping the content into folders by departments, brands or products
- Date, usually Year and subsets containing the 12 months
- Grouping by usage (Buttons, Authentication, News, Blog etc..)
So, there you have it. Delivering a successful project is not just about hitting a date, or, making a slick looking frontend. Building a product that is well made, that people want to use that also helps a business to align with their goals has a lot more considerations than you might think about.
A lot of the things listed in this article are things developers might not consider important but, content editors of the marketing department would consider essential to delivering a successful project. Before you say your projects done, skim through this list and if you can make improvements, do it now before it becomes too unmanageable.