Inherit settings from parent API keys

Having multiple websites covered with Flmngr causes having individual Flmngr API keys for each of them. Each API key refers to an isolated configuration that is applied to the file manager on the website you use the API key on.

However, often having a lot of similar websites nudges you to find a way to control their settings in a centralized way.

For example, you have the same file manager configuration for all your websites, the same image editor options your workers are familiar with and many other settings that are also identical across sites. This is the perfect case for making all your API keys inherit from a single one that will be a parent.

This inheritance can be configured in the Dashboard. Each parameter change on a parent API key immediately applies to the children.

Overriding configuration

Sometimes you might need to override some parameters of the child key.

You can do this using programmatic passing parameters. Just specify them in the Flmngr configuration and they will have higher priority than the configuration of the parent API key.

File manager overriding example:

import Flmngr from "flmngr";

Flmngr.open({
    apiKey: "child-flmngr-api-key",
    urlFileManager: 'https://child-website.com/flmngr/flmngr.php',
    urlFiles: 'https://child-website.com/files/',
    isMultiple: false,
    onFinish: (files) => {
        console.log("User picked:");
        console.log(files);
    }
});

import Flmngr from "@flmngr/flmngr-react";

Flmngr.open({
    apiKey: "child-flmngr-api-key",
    urlFileManager: 'https://child-website.com/flmngr/flmngr.php',
    urlFiles: 'https://child-website.com/files/',
    isMultiple: false,
    onFinish: (files) => {
        console.log("User picked:");
        console.log(files);
    }
});

<script src="https://unpkg.com/flmngr"></script>
<script>
    window.onFlmngrAPILoaded = function() {
        window.Flmngr.open({
            apiKey: "child-flmngr-api-key",
            urlFileManager: 'https://child-website.com/flmngr/flmngr.php',
            urlFiles: 'https://child-website.com/files/',
            isMultiple: false,
            onFinish: (files) => {
                console.log("User picked:");
                console.log(files);
            }
        });
    }
</script>

<textarea id="editor"></textarea>
<script>
    tinymce.init({
        selector: "#editor",
        plugins: "n1ed",
        Flmngr: {
            apiKey: "child-flmngr-api-key",
            urlFileManager: 'https://child-website.com/flmngr/flmngr.php',
            urlFiles: 'https://child-website.com/files/',
        }
    });
</script>

<textarea id="editor"></textarea>
<script>
    CKEDITOR.replace("#editor", {
        extraPlugins: "flmngr-editor",
        // Alternatively you can define these options inside 'config.js'
        // as config.Flmngr = { ... };
        Flmngr: {
            apiKey: "child-flmngr-api-key",
            urlFileManager: 'https://child-website.com/flmngr/flmngr.php',
            urlFiles: 'https://child-website.com/files/',
        }
    });
</script>

It's actually the same as you might do when assigning individual folders for app users/tenants.

What key to choose as a parent

There are two main approaches of building API key hierarchy:

1. To have an unused API key that only stores the base configuration. This is the easiest way. So you will use child keys only, that are linked to individual websites.
2. Use one of your websites as a parent, all others will be its children. This way may also be used.

Detaching from the parent

If you decide that one of your websites is really special, and you don't want to let the parent key change its configuration, you can easily detach this API key on the Settings tab in the Dashboard.

The API key configuration will be unlocked and you will be able to edit it. After detaching, the settings will revert to their state from before the key was attached; no parent parameters will be copied over.

Actually, attaching API keys to some so-called parent API key doesn't cause self-configuration overwriting: it will still be stored in the Dashboard, and you will see it as disabled. So you can always return to your previous configuration regardless of what happened, so the migration from a set of independent, standalone, keys to parent-children associations will be smooth and you can immediately revert everything in case of any issues.