Cloud Connected

Running Custom Scripts through Rules Test

You may want a complex action to occur in your project that is specific to your business requirements. We provide a number of out of the box actions that you can easily setup in a Content Rule, but sometimes the requirement goes beyond these functionalities. So, Cloud CMS allows you to write Javascript scripts that will run whenever a rule is triggered. In this example, we will be working with the following definition, call it custom:counter:

	"title": "counter",
	"type": "object",
	"properties": {
		"title": {
			"type": "string",
			"title": "Title"
		"count": {
			"type": "number",
			"title": "Count"
		"counting": {
			"type": "boolean",
			"title": "Counting"
	"_parent": "n:node"

The goal is to make it so every time this document is updated, the counter will be incremented, but only if the "counting" checkbox is checked. So, go to Rules from the left menu and create a new rule. Go to its Policies and add a policy binding. Set this to bind to all content of a single type, select the policy After a Node is Updated (p:afterUpdateNode), and then on the next screen select your content type to bind to. This will make it so the rule will trigger its actions whenever a node of your content type is updated. policy.jpg

Next, go to actions, add one, and select execute script. From within a script, there is a prepopulated model that allows you to access the platform, repository, branch, and node, accessing them and updating using bindings from the Javascript Driver. So, we can write the following script:

if (typeof( === 'undefined')
{ = 0;

var counting =;
if (counting)

This will need to be on one line in the action, and should look like this: script.jpg

Your rule is now all setup! So now everytime you modify a "counter" node, its count will increment by one.

Automatic Extraction from Attachments

When you upload files into Cloud CMS, all kinds of interesting things happen.

For example, Cloud CMS automatically indexes your files for full-text search. All of the textual content is discovered and made available so your editorial teams can instantly search and find things after uploading.

Did you know that Cloud CMS can also automatically extract metadata about uploaded files and make that information available? This is done via the Cloud CMS f:extractable feature.

When you upload files, Cloud CMS is able to automatically look at the kind of file it is. Based on the kind of file, Cloud CMS readies a small army of content extractors that will interrogate the file for header and tag information. In some cases, such as with XML and JSON, the document payloads are parsed and iterated over as well to pull out interesting information.

This information is then extracted and populated onto your JSON so that your applications have access to the information at runtime.

To use this, all you need to do is add the f:extractable feature to your content instance (or content types depending on how you prefer to do things).

Let's take a look at an example.

Extracting from an Image

Suppose I have an image file called ultima5.jpg (the cover art from one of the truly great games of years past). The file is 269 pixels in width and 371 pixels in height.


After I upload this image to Cloud CMS, I click into the Features section and add the f:extractable feature to it.


When I click save, the feature will reload with the following extracted properties:

    "extracted": {
        "default": {
            "imageHeight": "371",
            "imageWidth": "269"

As shown here:


All images support a few basic image-specific properties such as the ones shown above.

Cloud CMS knows how to extract from a wide variety of file types, including popular Office document formats, PDFs, text files, audio files, video files, image files and much, much more!

Different kinds of properties will be extracted depending on:

  • the type of file that is uploaded
  • the kinds of extractors that apply to that file type
  • the availability of properties within the file

By default, extraction is turned off for nodes. That is to say, the base n:node type does not have the f:extractable feature on it. This means that your content won't automatically extract as shown above - you'll have to add the f:extractable feature to your content instances directly or add them to your content types as you see fit.

For more information on extraction, please read up on the f:extractable feature here:

We hope you enjoy playing with extraction! We're always looking for feedback and ways to improve. If you discover any file types that you feel Cloud CMS really should extract from (but doesn't currently), let us know!

Precompile your Text fields with Markdown or Handlebars

One of the new features in Cloud CMS 3.2.41 is the f:precompile feature. This feature tells Cloud CMS to automatically precompile one or more fields on your content items whenever the content is saved.

With precompiling in place, you can now let your editors work in Markdown or use Handlebars tags in their content and then have that content automatically convert into HTML (or another output format) for use in your front-end applications.

An Example

Suppose, for example, that you defined an artcle with two fields (title and body). We define a third field (html) to store the precompiled text. The schema might look like this:

    "title": "my:article",
    "type: "object",
    "properties": {
        "title": {
            "type": "string",
            "title": "Title"
        "body": {
            "type": "string",
            "title": "Body"
        "html": {
            "type": "string",
            "title": "HTML"

Let's set up the body field to use Markdown. That way, our editors can write things using Markdown and avoid the torrid affair of dealing or modifying HTML directly. We can also make the html field hidden so that editors don't have to see that field and can instead just focus on what matters.

We can define a form like this:

    "fields": {
        "body": "markdown",
        "html": {
            "hidden": true

When editors use this form, it will look like this:


Awesome! Now let's add a mandatory feature to the my:article type so that any articles our editors create and work on will automatically have their html field updated. To do so, we modify the my:article schema and add the following to the end:

    "mandatoryFeatures": {
        "f:precompile": {
            "steps": [{
                "sourceProperty": "body",
                "targetProperty": "html",
                "processor": "markdown"

The f:precompile feature lets use define one or more steps that should execute upon save. In this case, we tell the feature to auto-convert the markdown from the body field and save it in the html field.

As an editor, we can now use a form to create an article. Let's say they fill in the following markdown:

# Milwaukee Brewers win World Series!
The [Milwaukee Brewers]( have made history, becoming the first MLB team to with 162 games straight and sweep the World Series in 4.

Here is what the creation form would look like:


The editor clicks Create. That's it, they're all done.

As a developer, if you were to now crack open the JSON for what they created, it'd look like this:

    "title": "Milwaukee Brewers win World Series!",
    "markdown": "# Milwaukee Brewers win World Series!\nThe [Milwaukee Brewers]( have made history, becoming the first MLB team to with 162 games straight and sweep the World Series in 4.\n",
    "html": "<h1>Milwaukee Brewers win World Series</h1><p>The <a href='' title='Milwaukee Brewers'>Milwaukee Brewers</a> have made history, becoming the first MLB team to with 162 games straight and sweep the World Series in 4."

The html field contains your precompiled HTML - ready to go and be used in your front-end web site or application.

Future Roadmap

We're very pleased to offer the f:precompile feature as it further delivers on our philosophy of having Cloud CMS "do things automatically" on behalf of your editors. Our vision, which is often state but bears repeating, is that we'd like editors to be able to "Click on Save and walk away". The system should do things automatically for them (by adding value, saving time and reducing error). It should perform these things and additionally normalize the expected results so that developers get precisely what they need.

In terms of the roadmap for this feature, some of the things we're thinking about include:

  1. Additional text processors
  2. More default, out-of-the-box Handlebars helpers
  3. Precompiling to additional output formats (such as PDF)
  4. Storing output onto attachments

We'd love to hear your feedback.

As always, let us know what we can do to make Cloud CMS a better product for you and your organization!

  • 1