Wakefly Kentico Settings Module

Posted: 10/9/2018 12:18:32 PM by Chris Bass | with 0 comments
Filed under: Analysis, API, KInspector, Performance, Process

One thing about working at an agency with a lot of Kentico developers is, you need to have a process for making sure that when one developer builds a site, it comes out as good as if another developer made it. Good process documentation, developer trainings, and oversight can help, but there are a lot of 'little things' in Kentico that can be overlooked if you aren't paying attention. Things like Event log sizes, passwords, Online Marketing contact deletion, media file storage, and the like, can be overlooked but have a major impact on a site.

So KInspector now is a separate tool that uses SQL to modify the site, but it used to be an internal tool that was usable within the Kentico interface by Kentico Support. Taking some cues off of that, I wanted to build a module that would show an interface in Kentico, and had these ideas in mind:

  • I wanted to allow adding a set of 'rules' that would be checked, compared against some approval/rejection criteria, and ideally have a quick way to set the site to a 'correct' state if it was wrong. 
  • I knew I wouldn't be building all the rules myself, so I wanted it to be easy for other developers to build their own rules and add them quickly. 
  • I wanted the framework itself to be separate from the rules, so that changes to the underlying base wouldn't force rewriting of all of the rules.
  • I wanted the rules to be able to individually contain their own validation, depending on whether the site was beginning development or being made ready for deployment - You don't want debugging on in production, but it's good to have in development, for example.
    • And I wanted the rules to be also checked at the global level, and per-site, if that specific rule applied per-site (like checking Kentico settings)
  • I wanted rules to be turned on and off in code, so that rules under development could be written  and committed to the repo, without being 'on-site' before ready.

With all that in mind, I built a central controller that would search the codebase for any items with the 'WakeflySettingUserControl' interface, with the 'WakeflySettingAttribute' setting (which also tells the code whether the setting is shown on the global or site level, or both). That interface defines a set of overrideable methods, that define the setting's name, how to check whether the website is in a valid state, how to tell the user what the 'current' and  'valid' states even are, and optionally, how to change the state of the settings. Each of these is configured at the site/global level, and configured for initial dev/pre-production.

Some of the settings we've been able to build so far using this code:

  • Checking the debug state, including the web.config
  • Ensuring that if Online Marketing or Web Analytics are on, that the relevant data is being trimmed (Contact deletion and the Analytics cleanup task)
  • Making sure a client email (rather than a developer's) is set up for any email templates, kentico settings, newsletters, etc
  • Making sure no users have blank passwords and that password policy has been set
  • Testing that the filesystem is modifiable in the right places (similar to the System - Files test, but in various spots across the site)
  • Ensuring that any error pages and such are actually returning the correct HTTP status codes

Each with the goal of leading developers to double-check any 'suboptimal' settings. As we build out more of these, we can reduce our QA burden by just going down the line and double-checking that everything's marked 'ok', or being able to justify any that aren't.

A tool like this is fundamentally linked to the Kentico version, so we have a separate build of the main tool per Kentico version, and so far all of the settings have been pretty easy to keep updated.

If you'd like to see it in action, here's the link to the K11 version of the export package. You'll have to write your own settings - you'll have different rules about how to build your sites than we did, after all, but I've included an empty example in /AppCode/CMSModules/WakeflySettingsModule/Settings  so you can at least see how the interface works.


Blog post currently doesn't have any comments.
 Security code