Configuration Files

Overview

This page will use the term "client configuration" often, this term refers to the configuration used by the Writer to figure out which plugins to load and in what order, what language to use for labels, and many other settings not covered here.

Naviga Writer has one or many client configuration files which are served to users when opening the Writer. There is also a server configuration file where devops can change a few select server settings per customer.

The configuration files are written in JSON, which is a fairly popular text-based data format. This means that the configuration files are portable and easily updated for administrators with access to them.

Client Configuration Files

When a user creates a new article or opens an existing one, one of the first things that happen is the Writer will load its client configuration to figure out which plugins to load. The client configuration received depends on the user's selected NavigaID unit and which version of the Writer is being used.

Client Configuration Example

org-name/7.0/client.json

{
    "language": "en_US",
    "labelLanguage": "en",
    "facebookAppId": "0000133700000042",
    "contentHost": {
        "protocol": "https://",
        "credentials": "include",
        "hostName": "editorial-oc.test.infomaker.io",
        "port": "5000",
        "healthPath": "/opencontent/health",
        "queryPath": "/opencontent/search",
        "objectPath": "/opencontent/objects"
    },
    "plugins": [
        {
            "id": "io.infomaker.myplugin",
            "name": "im-myplugin",
            "url": "https://plugins.writer.infomaker.io/v1/infomaker/im-myplugin/1.0.0/index.js",
            "style": "https://plugins.writer.infomaker.io/v1/infomaker/im-myplugin/1.0.0/style.css",
            "enabled": true,
            "data": {
                "apiKey": "abcd1234"
            }
        }
    ]
}

This is a very small example of a client configuration file containing the bare minimum of properties used to make a Writer be able to start.

This page will not deep dive and explain each property and its use, it will only focus on the "plugins" list, and how to separate client configuration depending on selected NavigaID unit.

Plugin Configuration per Unit

Normally a plugin block will be used by the entire Organisation, but sometimes specific Units in that organisation needs to have different configuration in a plugin's "data"-property, or a few plugins should be disabled/enabled for only one Unit.

Plugin Configuration with Units Example

{
    "plugins": [
        {
            "id": "io.infomaker.test",
            "name": "im-test",
            "url": "https://plugin.writer.io/index.js",
            "style": "https://plugin.writer.io/style.css",
            "enabled": true,
            "data": {
                "apiKey": "global-api-key"
            }
        },
        {
            "id": "io.infomaker.test",
            "name": "im-test",
            "url": "https://plugin.writer.io/index.js",
            "style": "https://plugin.writer.io/style.css",
            "units": ["imnews"],
            "enabled": true,
            "data": {
                "apiKey": "api-key-just-for-imnews"
            }
        },
        {
            "id": "io.infomaker.test",
            "name": "im-test",
            "url": "https://plugin.writer.io/index.js",
            "style": "https://plugin.writer.io/style.css",
            "units": ["naviganews"],
            "enabled": false
        }
    ]
}

In this example we have added "units"-property to the plugin configuration block.

Property	Description
"units"	A list of units that should use the configuration block.

In the example above, we can see three plugins configured with the same value for their "id"-property, "io.infomaker.test". Normally this will not work since "id" should be unique, but because we also include a "units"-property, when the user receives the client configuration for its unit, the "id" will be unique, since the other plugin blocks will be filtered out.

• The first plugin config block does not have a "units"-property, so this is used by the entire organisation

• The second plugin config block has "units"-property set to ["imnews"], indicating that this block should be used by imnews unit. It also has different values in its "data"-property from the organisation config

• The third plugin config block has "units"-property set to ["naviganews"], and also its "enabled"-property set to false. This indicates that the configuration block should be used by naviganews unit and that the plugin should not be loaded by the Writer.

If you made it this far, congratulations.

Client Configuration per Unit

When plugin configuration is not enough, and properties other than "plugins" need to be changed for a specific unit, such as setting different label language or if different generic properties should used, then it's possible to override an entire client configuration file for that unit.

Client configuration should really only be overridden if the Organisation-wide client.json becomes unmanageable because of unit-specific plugins-configuration, or the unit requires very specific settings

To override a client configuration file for a unit, simply create a new JSON file called unitx-client.json (where unitx is the name of the unit) and place it next to the regular client.json file.

For instance, creating a file called imnews-client.json will cause any user with the selected unit imnews to receive the contents of that file instead of the normal client.json.