Editorial Scripting in CMS

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.