It is not news to anyone that a content management system (CMS) offers significant advantages to anyone who is developing and maintaining a website. At the top of that list is the fact that they’re relatively easy to install, they offer users a wide array of out-of-the-box features, and the best of them make updates extremely easy.

CMSs that are the best choices for general use websites and web applications have several hallmarks, including:

  • Built-in layout or template system to facilitate consistency across the site
  • Access control so that content owners can be responsible for content updates, without adversely affecting the overall site operations or appearance
  • Content updates can be published more quickly, since they have reduced risk and do not require developer engagement
  • Many common site features are fully supported out-of-the-box (varies by CMS)
  • Most missing features can be easily implemented with plug-ins
  • Simplified SEO management (perma-links, alt tags, etc.)

Even with all of their power and freedom, CMSs still have limitations. Every CMS-based website I have ever worked on has required, or at least benefit from, some level of custom development. Most of that custom development has fallen into one of these patterns: 1) custom client scripting, 2) displaying custom data in a custom way or 3) collecting user input from a custom form.

Pull up your pants and put your hat on straight, because we are about to examine these three patterns in the context of two very common, but very different CMSs: WordPress and Sitecore.

WordPress is a blogging platform that has evolved into a full-fledged CMS. It is written in PHP, and therefore most plugins, templates, and custom development will also be in PHP.

Sitecore is an enterprise-level CMS that runs on ASP.NET, and therefore most plugins, templates, and other custom development will also be in .NET (VB.NET, C#, etc.).

These two content management systems showcase two very different paradigms for managing websites and website content, but you are about to see how these common custom development patterns apply to all CMS.


Custom Client Scripting

No website would be fully buzz-word compliant without HTML5 and a good Web 3.0 experience, and dynamic client content is almost always a part of modern website design. That is why client scripting has earned the first place on my list of custom development patterns for CMS-based websites.

When determining how to accomplish this, the right answer is almost always to include your scripts when developing the template for the site. This is the simplest answer, and you probably thought it before I wrote it down. The only problem is that this is not the end of the story.

WordPress comes bundled with a number of common JavaScript libraries (jQuery, SWFUpload, ThickBox, Underscore.js, Backbone.js, etc.). You just need to load up the ones you want with the wp_enqueue_script() function. This also means you need to be mindful that these libraries may be updated when you apply WordPress updates.

Sitecore gives the developers more complete control over the templates. As a result, there are no special helpers for JavaScript files. Simply follow your instincts as an experienced ASP.NET developer.


Custom Data in a Custom Way

All significant websites will have the need to define custom data types. If possible, these items should be created and maintained by the content authors and entered directly in the CMS. Otherwise, this data could be in an external system and pulled in from a web service or a shared database. Whatever the source, these items need to be displayed on the site in a custom way.

In WordPress, the best way to accomplish this is with a custom post type. This has the benefits of inheriting existing templates, permalinks, taxonomy and more. Except for some plugins that might facilitate it, this will be done by calling the WordPress API from a PHP file.

This is much more natural for Sitecore. All items in Sitecore inherit from data templates, and new data templates can be created and maintained by a system administrator without any development experience.

Now that we have some custom data, we need to show it to the user. When rendering custom data, you should always use templates. Every CMS has the concept of templates to control how data is displayed. The basic idea is that a single layout (e.g. HTML) is re-used for multiple sets of data. As long as that data has a similar structure, the same template can be re-used to render each.

In addition to its normal template support, WordPress has the ability to create a unique template that is just used to render specific post types, wherever it appears on the site. It uses a convention where the custom post type name is part of the template’s filename. The template developer can create these files as easily as they can create the default post templates.

The preferred Sitecore method is to use the built-in template designer and the Sitecore server controls to lay out the templates. If you need more precise control or complex logic, a Sitecore website can be more like a normal ASP.NET website. ASP.NET User Controls serve as your templates, and Sitecore sublayouts are used to load the user controls. An ASP.NET developer builds the user controls, and can load data into the pages directly from Sitecore content items, or from any other source.


Custom Forms

Custom forms have become so common that you can find hundreds of different ways to implement them. I’m not talking about your typical “Contact Us” or “feedback” forms. What I’m getting at here is one of those custom forms that we have all built a hundred times.

A user fills out and submits the form, and the form data is passed on to an external system, like a web service or database. The basic workflow is simple, but this is an extremely common custom development task. Every site will have differences in the data collected and where the data needs to go. In general, there is not much a CMS can do to help here. Some plug-ins can help build custom forms, but in my experience, there are few times that this is sufficient. More than once, I have found myself 80% done building a form with a plug-in, only to discover that it doesn’t support a custom validation that I need, or some dynamic client behavior. At that point I need to choose between writing a hack to work around the plugin or scrapping it and writing it from scratch. The latter has proven to be the better option almost every time.

If my own experience is representative, then the best solution is a fully-coded custom form, which can usually be built faster than learning a new plugin or template format.

As I mentioned earlier, there is not much a CMS can do in this case. To build this kind of form in WordPress, the best solution is a custom PHP file that will both display the form, and to handle the user input.

When using Sitecore, the fully-coded custom form takes the shape of a sublayout, which you know is simply an ASP.NET user control or MVC partial layout.

Content management systems are excellent tools for building manageable websites, but they can’t get you all the way there out-of-the-box. No two websites are the same in purpose, content, or function, and while a well-chosen CMS can probably get you the majority of the way to go-live with its out-of-the-box functionality, site owners and developers alike need to plan to go the extra mile to make it perform the way they need it to.

Leave a Reply to Matt Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


  • Matt


    9 years
    Mobile CMS is the new newsmaker in the digital world.
    • 9 years
      Matt, I agree that mobile web browsing and content access has permeated global internet use, but I am not exactly clear on what you mean by "Mobile CMS," or how you see them as newsmakers. The best practice and trend for mobile websites is currently responsive design. This is even Google's recommended approach. In this case, there does not seem to be anything about the cms that needs to be unique to mobile. I would love to hear more about your experience with Mobile CMS! Particularly the benefits you see for a website with a responsive layout.