As a developer who is passionate about Kentico CMS I'm often asked by clients, fellow Kentico Developers and Partners to look over their sites and provide suggestions on improvements that could be made to their sites. These are the my 5 Best Practices to follow on every Kentico site.
Best practices are what people look for when starting any new project. Following what software manufactures recommend/suggest and what others have done or learned by doing, helps others in their development process.
1. Choose the development model for you
The development model for you is Portal. That's it. End of story.
All kiding aside now, Kentico offers four different development models:
- Portal
- ASPX
- ASPX + Portal
- MVC
To get the full description of each check out the Kentico Documentation. For simplicity sake, I'll focus on one, Portal. Using the Portal model you can take advantage of all the built-in API code as well as perform any kind of integration you need with ease. Kentico is ultimately a complex ASP.NET website. So adding references to web services or additional connection strings or anything else you'd normally do in an ASP.NET website you can do in Kentico. The key is to learn a how to develop in Kentico before just jumping in and starting to code.
Utilizing the Portal development model allows you several benefits over any of the other development models:
- Easier upgrade path
- Easier to apply hotfixes
- Gives end-user/editors the ability to use all of the features Kentico offers
- Faster development time
Kentico recommends Portal mode and I ALWAYS use Portal mode simply because I've found no other reason to use any of the other models. Carefully think through what your requirements are before choosing one model over the other. Choosing a development model other than Portal WILL make more work for you later on.
Just to clarify, there really is only one choice, Portal... :)
2. Choose YOUR SITE'S CODE NAME Wisely
This is important as most everything revolves around it, especially if you plan to build your website so it can be exported and imported into another Kentico instance. Even if you don't plan to do this, it's a good practice in the event you have a disaster and need to export it and import it. As you know Kentico can have multiple sites running on one code base or instance. So separating the code out as needed to your different site names allows you keep site specific code with the site.
In the
Kentico Documentation they specify here what is and isn't exported, what should and shouldn't be modified and what directories need to be created manually. The three main items I always keep the same as my sites code name are:
- The sites media folder which resides at the root of the website /<SiteCodename>
- The main theme of the site in the /App_Themes directory. This is created when you create your sites stylesheet. /App_Themes/<SiteCodeName>
- Code files specific to the site. /App_Code/<SiteCodeName>
3. don't brand your client's install with your name
Everyone wants to have a client for life and during the project they assume this is the case. Well I'm sure this isn't a news flash but things change and clients shop around. I've followed behind many developers who have created awesome Kentico based websites but during the creation of the site they internally branded Kentico with their name or acronym.
Unless you specifically have in your contract that all the code you create is yours (very uncommon), brand your install for your client. So when when, yes when, another developer comes in behind you, it is self explanatory. Here are a few examples:
- In Page Templates, create a category with your clients name and 16 x 16 icon (favicon works well).
- Webparts, create a category with your clients name.
- If you have custom settings, create a Module with your client's name. This would be if you didn't have any code or other classes that go along with it.
In the end, it's all about the client. If you're client is happy and they trust you and your work, you'll have a long term client. Return work and referals are your best friend.
4. Use the Tools Kentico Provides
Kentico has spent a lot of time and effort creating tools to make creating your website easier and faster, so get to know them and use them. If you find there are some missing features or would like some changes, feel free to request them on the
Kentico Ideas website. A few of my favorite tools are:
- Stylesheets. Using the CSS Stylesheet app allows you to create one or many database driven stylesheets and use them anywhere within your site with a single line of code.
- Javascript files. Kentico recommends placing your custom javascript files in /CMSScripts/Custom/<SiteCodeName> directory. This can be done using the JavaScript app. The only downfall of the JavaScript app is any changes you make are not recorded in versioning or Content Staging.
- Minimization of stylesheets and JavaScript files. These are simple checkboxes within Settings you set. If you're not utilizing these your loosing out. Minimization of the stylesheets will also tell you if there are compile errors within your stylesheet. To take advantage of the minimization of these resources, use the following lines of code:
<link href="/CMSPages/GetResource.ashx?stylesheetname=StylesheetCodeName" type="text/css" rel="stylesheet"/>
<script type="text/javascript" src="/CMSPages/GetResource.ashx?scriptfile=/CMSScripts/Custom/SiteCodeName/jquery.preloader.js"></script>
- Use Content Inheritance. Don't create new templates just becase you can, it makes more work when something changes.
5. don't code yourself into a hole
Nearly every application will have a use for some custom code. Whether it's something as simple as a
Custom Transformation Method or something as complex as using the
Integration Bus, always use the Kentico API. Don't try to come up with some weird workaround to get by or just get things done quickly.
Follow the examples provided. If there aren't any examples then ask on the
DevNet, check out the
Kentico MVP's blogs,
Google it, or ask
Kentico Support. If you have examples, I know the technical writers at Kentico are buried eyeballs deep in keeping the documentation current so post your example on the DevNet or even on the page you found the documentation on.
Here are a few of my favorite links for custom coding in Kentico:
Webpart Development
UniGrid Development
Global System Events
Custom Modules
Wrapin' It up
These are just a few items I can't stress enough when working on your Kentico project you should think hard about. Remember deviating from what's recommended will make more work for you and anyone else maintaining the project. I'm not saying don't ever do it but know what the consequences are prior to doing so. If you plan to deviate from the recommendations then ALWAYS, ALWAYS document what you did and possibly even a why you did it.
Best of luck and Happy Coding!