Configuration issue with bootstrapping activated

[ravage84]

In our applications, we have a three level configuration system:

1. application wide default configuration (versioned, in appliation folder)
2. environment specific default configuration (versioned, in appliation folder)
3. enviornment specific "local" configuration (only on server, outside of appliation folder)

The latter merges with and overwrites the former.

We load these configuration settings during the application bootstrap process, before loading any plugins.
By the time we load the users plugin at the end of the application's bootstrap.php, we have loaded all configuration settings. That could include settings specific to plugins.

By loading the users plugin with bootstrapping activated as recommended in the documentation:

Plugin::load('CakeDC/Users', ['routes' => true, 'bootstrap' => true]);

It will also load a) the plugin default configuration and b) custom configuration files specified in the config key:

https://github.com/CakeDC/users/blob/8.0.3/config/bootstrap.php#L20-L23

This leads to our configuration settings being reset by the plugin's default configuration:

https://github.com/CakeDC/users/blob/master/config/users.php

I'm aware that there are currently two solutions for us:

1. manually botstrapping the users plugin https://github.com/CakeDC/users/blob/master/config/bootstrap.php#L25-L49
2. loading additional, local and non versioned configuration by utilizing one of the custom configuration files https://github.com/CakeDC/users/blob/master/config/bootstrap.php#L21-L23

Both solutions aren't very nice, though.

Could we extract the two lines loading the configuration from the current bootstrap.php to methods available through a class within the plugin? All the rest within this file stays the same.

https://github.com/CakeDC/users/blob/8.0.3/config/bootstrap.php#L20-L23

So loading the plugin, bootstrapping it and loading its configuration would become this:

Plugin::load('CakeDC/Users', ['routes' => true, 'bootstrap' => true]);
\CakeDC\Users\Configuration::loadDefaults();
\CakeDC\Users\Configuration::loadCustom();

Alternatively, we could use a new plugin specific key like config:

// Loads configuration by default
Plugin::load('CakeDC/Users', ['routes' => true, 'bootstrap' => true]);
// Does load configuration, explicitly
Plugin::load('CakeDC/Users', ['routes' => true, 'bootstrap' => true, 'config' => true]);
// Does not load configuration, explicitly
Plugin::load('CakeDC/Users', ['routes' => true, 'bootstrap' => true, 'config' => false]);

[rochamarcelo]

I don't think we need to create a Configuration class, we could place it at Plugin class. We could also use a normal check before loading the files at bootstrap.

if (Configure::read('Users.skipLoadConfiguration') !==  true ) {
        ......
}

@ravage84 when are you planning to send a pull request?

[ravage84]

@rochamarcelo something like this could work, too.
I wanted to wait for some feedback first, but yes either me or somebody from my team could create a PR.

[rochamarcelo]

It seems that with Application::pluginBootstrap you should be able to handle this fine. I would say we good to close this one, what do you think @ravage84 ?

[ravage84]

It seems that with Application::pluginBootstrap you should be able to handle this fine.

To be honest, I'm not quite sure what you mean by that.

Currently, the solution proposed at #753 (comment) seems to be the best.

[rochamarcelo]

You can load your configuration before or after plugin bootstrap

[ravage84]

Unfortunately, this is not really an option. This would mean our application(s) has to wrap around the way CakeDC users plugin wants to work. 😞

[rochamarcelo]

You can also manually bootstrap the plugin but the bootstrap logic only makes sense to be hooked for configurations setup. So for your case the bootstrap logic does not add much.

https://github.com/CakeDC/users/blob/master/config/bootstrap.php

[ravage84]

Was this or can this be improved in the newer version(s)?

I would appreciate if we wouldn't need to do a manual bootstrap or some workaround.

[ajibarra]

@rochamarcelo is this still valid? should we make a improvement here?