Editorial Scripting in CMS

By Deane Barker on January 29, 2015

For years, I’ve been quite interested in the idea of scripting within a CMS.  By “within,” I mean scripting inside of managed content.  So, using some taught language or declarative syntax to get the CMS to perform actions to publish content.

This clearly sounds weird, so here’s an example —

Say we have an editor who wants to display a dynamic table of data on a page.  This is data that comes from some DB-ish datasource outside the CMS.  Perhaps a list of locations, or something else.

Conventional practice gives us two options: we could (1) bring this data into the CMS itself, as managed content; or (2) we could leave the data where it is, and create custom code that connected to the database at the CMS level, retrieved and formatted the information.  Of course, either way will require us to do the dreaded “custom development” on our CMS implementation.

But is there perhaps another way?

Could we perhaps create a content type called “SQL Recordset” which contains an editor-controlled SQL query.  When this content renders, the SQL query is executed against a datasource, and the results are displayed as content.  The end consumer doesn’t know the actual “content” is the SQL query that generated it, but that’s not important.  Sure, our editor would have to understand basic SQL (only as it relates to this problem) and the structure of the datasource, but let’s pretend this is feasible.

Could we take this a step further by allowing the editor to supply a template, which is HTML with templating controls (a la Smarty, or Twig, or DotLiquid, something) and apply that template to the recordset.  Or return the SQL results as XML, and transform it with XSL (ewwwww, I know…but it works). The resulting HTML might not even look like a SQL recordset – hell, a competent editor might make it come out as a blog.  Essentially, they’re content-managing scripts, which are executed at request time.

Now, before you freak out (it’s probably too late), let me explain the reasons why this interests me —

First, there are different types of editors.  There are “normal” editors that just want to create content by filling out forms, and then there are “power editors,” who want as much control as they can get.  They’re not full-blown developers, but they have some concept of programming principles, enough that you could teach them a simple language and have them get results without them tying up a developer with a bunch of requests.

Second, there are different types of content problems. There are problems so foundational that you need a developer to solve them. But there are other problems which are just not that complicated, very idiosyncratic to the editor/content (meaning you’re not going to need to solve the same problem every day), and perhaps you just don’t need to re-build and re-deploy your CMS implementation to solve them.

You want to display the weather in Moscow on your intranet page?  Well, this is not a common request, so I’m not going to build a framework for it, and you’re just some random dude in the organization, so you don’t have the right to tell me to develop this and re-deploy the app.  But what if there was a simple scripting language inside your CMS which would enable you to make a call to the Open Weather Map API, extract the data you want, format the results and inject it into a content-managed page?  Would that work?

Third, even if I’m a trained developer, some problems are so simple that perhaps we should solve them at a level that doesn’t require us to mess with the “foundational” code of the implementation.  What if we split our implementation into “foundational” and “editorial” layers, and decided that we could solve some problems in the editorial layer?

For a highly dynamic implementation (think intranet), perhaps the core CMS implementation itself is more of a framework, and we have an embedded scripting container to solve highly specific, one-off problems at the content/editorial level, rather than the code level.  Perhaps there can be another category of lightweight developer that can solve simple problems that editors have without having to escalate to a “full” developer?

Yes, there are numerous issues here, and the idea of editors have access to a programming environment is a little scary, but I’m curious to see how viable this is.  To what extent could editors be trained on, understand, and use some simple scripting tool?

Lately, I’ve been playing with some ideas.

  • The first one is a “text filter pipeline” (it really needs a better name) which grew out of the development of a simple file include-ish feature for EPiServer.  An early version is on GitHub. The idea is an extremely simple scripting-ish language that editors can use to inject external data into managed content.  I’ve kept the language as simple as possible, while still making it fairly powerful and extensible.  It’s still very much in development, but take a look at the README for an example of what I’m talking about (and a working example of the “weather” scenario I mentioned above).
  • The second one is straight up server-side JavaScript injection.  I’m playing around with Jurassic, and I have a prototype of server-side JavaScript executed at request time within EPiServer HTML content (technically, in a SCRIPT tag with a “type” of “text/server-js”).  The difficulty is exposing a read-only EPiServer API to the JavaScript, but I’m getting there.  It’s quite possible, and ECMAScript 3 would give an editor an essentially Turing-complete language in which to do…stuff.
Yeah, yeah – a lot of you are freaking out right now.  I get it, and I’m not saying this isn’t fraught with potential security, training, and governance issues.  But it’s interesting as hell, and I’m determined to see just how viable it is from a practical standpoint.

Also, I know that this isn’t new.  I have seen things like this before (DekiScript for MindTouch, for instance).  I don’t think I’ve seen it done really well, and perhaps there’s a reason for that.

Even if this doesn’t work out how I hope it will, I stand to learn a lot about the average CMS editor, what they want, and where their threshold of complexity lies.

Stay tuned.



  1. Great ideas Deane. While not for everyone, as you mention, these capabilities would be very beneficial for knowledge workers who need to publish content internally or externally, and are the best ones to know what specific content is most appropriate. I’ve worked in the past with a large international organization comprised of economists who would love the ability to incorporate more live data into their online content.

  2. This sounds so much like a scenario underlying Textpattern (textpattern.com) and it’s community. Textpattern has been around since 2003, but it’s community and user base is still very small compared to other systems that also started about that time. But most users of Textpattern could easily be described as this quasi editor-developer type of person you describe. Likewise, Textpattern itself has a very small core footprint, that allows editors/site owners to layer on whatever degree of functionality they want.

    Of course, we often talk about this functionality in terms of plugins, and that’s the same with Textpattern, but there are a couple worth mentioning here for comparison with your third-party content idea and how it’s pulled in:

    • smd_xml
    • smd_macro

    (Both are prefixed “smd_” because that’s the developer that created them — Stef “Mephistopheles” Dawson — currently one of the core Textpattern developers.)

    smd_xml allows you to take the xml feed of any third-party site, strip out the data components from the prefabricated feed file, recombine them however you want to define a new content type structure for embedding into your own (Textpattern-driven) site, and apply your own CSS styling on the result. So if you think about things like Twitter feeds, Google calendars, Delicious link lists … whatever has an XML source, it can be re-vamped in a Textpattern site as a content type without being stuck with the complete source set, structure, and presentation.

    smd_macro allows an editor to create pre-fabricated chunks of code (called “macros”) that can then be inserted into a page via a single custom tag (the name for which is defined in the macro). A macro can be composed of HTML tags, PHP, XML, or whatever, all combined, so what you end up with is a complex chunk of code having dynamic “pieces” that are run at time of page load. The possibilities here are endless, but the point is that it’s an easy way to reuse frequently needed blocks of code by way of a simple, short tag.

    So now you have these two things you can combine. First you can use smd_xml to create a custom block of code (say a redesigned data set from an aggregated external source), package it up as a macro, and output it in your Textpattern site by way of a single, short tag.

    Pretty cool stuff.

    But the other point here is that it’s not something just anybody is going to be able to do; it requires the type of editor you’re talking about, who can look at an XML feed, for example, take it apart, rebuild it, add in some HTML and presentation hooks, maybe pepper it with some PHP functions, whatever. The content person who is useless without a WYSIWYG UI won’t be able to cope here.

  3. How is what you describe different from just using a general-purpose programming language (which already exists on the server as part of the CMS)? Is it just a matter of having a simplified syntax or Domain Specific Language (DSL) that is custom-tailored to this task?

    I remember back in the day I had to build a system that generated HTML emails by combining client-supplied data with a template. At the time, the prevailing wisdom was “use XSL — that’s exactly what it’s for!”, so I went ahead and that’s what I did. What resulted was an unmaintainable mess of procedural code (for presentation logic) shoehorned into a declarative language… in hindsight it would have been much faster to just use a scripting language (php, python, whatever) to generate the html. And it’s not like the “simplicity” of XSL would have been easier for a non-programmer to learn… it was just a different form of difficulty.

    Not sure if my analogy fits your use-case, but it might be beneficial to think about how this might be easier to achieve (and yield better results) with just some domain-specific functions or libraries that are purpose-built for the task at hand, which would run in a common and full-featured language (e.g. javascript).


Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.