Web Content Management

Whether to support dynamic loading of web pages from Cloud CMS. This enables the Cloud CMS web content management solution.

Here is what a full configuration set looks like:

{
    "wcm": {
        "enabled": true,
        "cache": true,
        "cacheKey": {
            "params": {
                "includes": [],
                "excludes": [],
                "excludeAll": false
            }
        },
        "pageCacheTTL": (24 * 60 * 60) * 1000, // 24 hours
        "pageCacheRetryTimeout": 30 * 1000, // 30 seconds
        "matchCase": false
    }
}

enabled

This indicates whether the WCM middleware should be included in your application. If enabled, the WCM middleware will intercept and then handle requests that have URIs that match one of your Cloud CMS application's web pages. Web pages are loaded in the background and the incoming request URI is matched to find the most suitable page. The page is then dispatched and served back to the caller.

If a page cannot be found, the middleware simply passes on the request to the next handler in the middleware chain. By default, this includes middleware that serves from local disk.

cache

This indicates whether WCM web pages should cache their resulting HTML to disk. Cached HTML files are reused on subsequent requests resulting in near web server speed. The Dust processor only needs to process the first request and all subsequent requests serve back from disk until the cache is invalidated.

cacheKey

Allows you to control the generation of the cache key which serves as a primary key for the cached HTML file on disk. The cache key provides a unique identifier for your cached page. By default it is comprised of the URI path, any query string parameters and other page attributes. The cache key is then hashed to form the primary key for the cache on disk.

At times, you may want to limit or specify example which query string parameters are used to calculate this key. You might, for example, have a portion of your query string that is fully dynamic and that you would not want to consider part of the cache key. If you did, it would result in a cache key that is constantly changing even though the generated page doesn't change. And this would therefore mean a cache miss on every request.

You can use the excludes array to identify query string parameter names to exclude (with the assumption that otherwise ALL are included). Similarly, you can use the includes array to force certain query string parameters to be included (with the assumption that otherwise ALL are excluded).

The aforementioned assumption (that ALL are included) can be controlled using the excludeAll setting. If this is set to true, then the assumption is inverted and ALL parameters are assumed to be excluded (or ALL are NOT included). You can then use the includes array to pick at specific parameters to include.

pageCacheTTL

This specifies the amount of time that the WCM page URI lookup cache is kept around in the cache before it is automatically flushed and re-retrieved from Cloud CMS. Initially, upon first page hit, the WCM middleware will fetch a full copy of the WCM page instances and populate the lookup cache. This configuration setting can be used to specify how long the cache should live (at which time the page cache is fully reloaded from Cloud CMS).

In development mode, this defaults to 60 seconds. This means that every 60 seconds, the WCM middleware will reload the full index from Cloud CMS.

In production mode, this defaults to 24 hours.

pageCacheRetryTimeout

When the WCM middleware goes back to Cloud CMS to reload the WCM page URI lookup cache, there is always a chance that the lookup may fail due to network connectivity reasons. If that happens, the WCM middleware will continue to use it's existing index and will go back to reload at a future point in time. This setting lets you specify how long WCM will wait before going back and reloading again.

The reload timeout defaults to 30 seconds. This means that if the WCM middleware fails to load the index, it will re-attempt after 30 seconds.

matchCase

When matching incoming requests, should the case be significant or ignored. The default is true (case sensitive URL matching).