.png?width=667&height=667&ext=.png)
5 More Things to Check After Launching a New Kentico CMS Website
To date, the most visited post on my blog has been “7 Things You Might Want to Check After Launching a New Kentico CMS Website”. Based on that post’s success I have decided to create this follow up post. Below are 5 more items to add to your launch checklist.
1. Throttle back the default timing on some of the built in Scheduled Tasks
The default interval of many of the built in Scheduled Tasks comes preset at 1 minute. In my opinion, every minute is a little overkill when it comes to running the various scheduled tasks inside of Kentico.
Deleting old or Empty Shopping carts, cleaning up old attachments, and removing expired sessions probably don’t need to happen that fast. I normally set this to once a day or even slower depending on the task.
A slower frequency on some of the automated tasks will give your database a chance to breathe for a little while, at least until your next spike in traffic anyways.
2. Check your Email Settings in CMSSiteManager
If you think it’s correct, go double check it right now. Especially the various CMSSiteManager –> Settings –> Email SMTP settings as well as the BizForm Notification Email settings in the CMSDesk. There is nothing worse than having that nice new shiny contact us BizForm to let your readers and/or customers easily get in touch with you, than you not receiving the emails because the settings were not filled out or fat fingered.
Most administrators know that setting up mail gateways or searching for just the right SMTP settings can be a hassle. This is true with any program that integrates with email.
We recently launched a Kentico site and didn’t notice that our customer’s hosting provider had locked down the SMTP server to only send out from one email domain, and not the one that we were using. As a result, the first few hours of the launch were spent tracking down why emails were not being sent out. It does seem basic, but it’s worth double checking.
I also recommend using the e-mail queue system that Kentico provides. It will help out greatly when troubleshooting any email related issues.
3. Keep a close eye on your Event Log
At least for the first few weeks or so. I say this because Kentico’s Event Log administrative feature is one of the best built-in logging tools I have seen in a web application. It is very easy to get your hands on some stack traces to see exactly what is going on. Even if you are not that tech savy the error messages still make it fairly obvious if there are any problems that you have with your new Kentico site.
The Event Log may quickly reveal to you why a certain page is erroring or not showing the expected content. You might be surprised at what is actually going on, especially with a new site launch.
For example, you may have a mal formed transformation in one of your Document Types that only errors for a set of users or in a specific case that you don’t see when logged in as the administrator account. The Event Log will let you know right away if that is happening or not.
Another example of where the Event Log comes in handy is if you have an internal or external link to a page or URL that doesn’t exist. Again the Event Log will bring that right to your attention in a nice red highlighted row. This can help you realize you need to fix the link or make a 301 permanent redirect.
Speaking of which, the Kentico Marketplace has a nice Link Checker and Validation Module that allows you to check a chosen page in your Kentico CMS site for any broken links.
4. If you are using the Extensionless URLs feature and are linking to images or scripts without extensions, don’t.
Don’t get me wrong the Extensionless URL feature in Kentico is great, I use it all the time. However, if you are very observant you might notice that you will never see a 304 Not Modified response code for an image that is referenced without an extension. Hint, use the Firebug Net tab in Firefox to see what I’m talking about.
The reason for this is that the combination of the Kentico handler404.aspx page and IIS 7 basically doesn’t handle Extensionless URL requests all that well when it comes to caching. IIS7 wipes out the headers needed to identify the caching status, so that the system returns 200 OK responses every time (instead of 304 Not Modified).
To have the best of both worlds leave the Extensionless URL feature on, and if you know you want your images to cache just add a .aspx extension on the end of them. This will force the request to process through the normal URL handlers of IIS and Kentico and the requests will be correctly allowed to cache.
Small note here, it looks like this may have been resolved in this week's release of version 5.5 R2 and the introduction of a few new URL extension settings in the web.config file. I have not had time yet to test it out though.
5. Make sure your web site is being backed up.
I know this one may seem like a no brainer, but have you ever heard the phrase “Backups always work, and Restores always fail”? I can think of at least 3 or 4 people who have tweeted that recently or have said that to me over my career.
In fact maybe I should edit the title of this point to be: Make sure you have successfully tested your restore process of the Kentico files that reside on your web server and the SQL database that it is connected to.
Mark my words, someday you will have to grab something from a backup for someone, and if you aren’t testing your backup and restore process, this could really come back to hurt you.
Conclusion
So there you have it, 5 more things you might want to check after launching a new Kentico CMS website. I hope they are in some way a little bit of help to you.
