The Magic of Self-Erasing Files: A Clever Fix for Some Common Decoupled CMS Woes

July 21, 2011 | John Berndt

Decoupled CMS products (those that push website files out to a separate server, independent from the CMS itself) have many virtues, but they sometimes have the habit of creating extraneous files on a Web server that don’t get perfectly cleaned up when they’re done being useful. These files are usually innocuous, but when one of our clients is running a time-limited production, a trail of these files later on can create problems if someone were to access them and, for example, expect to receive some time dependant promotion long past. This happens because even the best of the decoupled products tend to err on the side of leaving rather than deleting files, based on their algorithms figuring out what files are still relevant. The end result is the published site may contain “debris”—isolated, unlinked pages that are out of date but may still be known to search engines from previous indexing.

There is a simple and elegant fix for this, however: “self-destruct dates.” These self-destruct dates are dates that the content manager chooses in the content entry interface, after which the published form itself will no longer work.

This example is given for a C# ASP.NET website published by CrownPeak CMS (a decoupled SaaS system), but the general idea can apply to most other systems and technologies. (Note that using CrownPeak as an example is not meant to imply anything about the quality of CrownPeak’s publishing engine—it is great software!)

Step 1: Setting up the required fields in the CMS.

All we need to provide in the CMS is a content field to hold the date after which the form should no longer work. CrownPeak has a calendar picker field type, so we use that.

Of course, because this is somewhat non-standard behavior, we include some descriptive text explaining what the field will do. This is one of the great capabilities of CrownPeak: the content entry forms are HTML that developers create.

Step 2: Rigging the form to blow.

The form itself is an ASP.NET page, which means that it’s built out of ASP.NET components. In this case, the form is contained in a .NET panel called “FormPanel”. It’s just a few short lines of code in the output template that drops the date entered into the C# code, which then compares the current date to the self-destruct date, and turns off the panel if it’s after the date specified.

Note how, even though this is inside a script tag, we have the ASP tags (<% %>). These are simply telling the CMS to insert that content value in that location when the page is generated at publication time. We could, of course, get even more creative with this, and set an additional message to display if the promotional period has passed so that users wouldn’t be confused if they see a blank page.

The basic idea here is that by making the output of your coupled CMS an executable ASP.NET page, a developer is able to exercise a great deal of programmatic freedom that can fix issues that are inherent to decoupled CMS, and work around the limitations of any product. This can be done in dramatic ways (for instance adding personalization to a published site) or it can be used in more subtle ways, as we’ve described, to get around one of the more vexing issues that comes along with decoupled publishing.

About the Author

John Berndt

I'm CEO of TBG and I've been thinking about the Web in creative ways since the year it began.

Leave A Reply

comments powered by Disqus