Migrating settings to BaseConfig and using custom configs

[BenParizek]

I'm migrating some module settings to use BaseConfig and realizing that things reconcile in a different way. Previously, we could check if a property existed in a file-based config and if it did not, assume that we could fallback to the default on the settings model property. Now, as both the file-based config and default settings properties are an object, all properties exist once the object is created and merging the two objects just results in the file-based config object overwriting everything on the default config.

It looks like Craft has a method to merge these objects for general and db configs using craft\services\getConfigSettings however, it's not clear to me how that method works for custom configs.

If we pass in the value 'custom' as the category as the method seems to want, the switch statement on line 135 works but the custom config file must be named custom and not one specific to our module, i.e my-custom-module.

cms/src/services/Config.php

Lines 130 to 147 in a935d09

	private function _createConfigObj(string $category): object
	{
	$config = $this->getConfigFromFile($category);
	switch ($category) {
	case self::CATEGORY_CUSTOM:
	return (object)$config;
	case self::CATEGORY_DB:
	$configClass = DbConfig::class;
	$envPrefix = 'CRAFT_DB_';
	break;
	case self::CATEGORY_GENERAL:
	$configClass = GeneralConfig::class;
	$envPrefix = 'CRAFT_';
	break;
	default:
	throw new InvalidArgumentException("Invalid config category: $category");
	}

Am I missing something here? Do all file-based config overrides need to use a custom config file now or can we have module specific overrides name after the module id?

I believe this method does what I need if I can target a custom config that is not named custom:

Craft::$app->getConfig()->getConfigSettings('my-custom-module');

And if the default case return the config that got created (which it currently does not):

  default:
    return $config;
    break;

Or am I misunderstanding how the new BaseConfig custom config stuff works now?

[BenParizek]

Or perhaps I'm mistaken about the default here. Perhaps what I actually want is that default to allow me to define my own config class:

  default
    $configClass = MyCustomModuleSettings::class;
    $envPrefix = '';
    break;

And that would allow me to also benefit from the rest of the method.

[BenParizek]

Ok, I was just told this isn't even supported for plugins yet so perhaps I'm jumping the gun. My use case is a module, and it's mostly working, but I'm struggling to get file-based overrides working without a ridiculous amount of overhead.

The issue I am seeing can be tested with the following:

• Create a module where you have two settings A and B
• Save setting A to the project config with a non-default setting.
• Override setting B in a file-based config with a non-default setting.
• Collect and merge both of those settings groups giving priority to file-based settings and unless you're doing something fancy my guess would be setting A will now be the default setting and setting B will be the expected override.

The difference in behavior from the array-based file config overrides is that objects return ALL values on their models with defaults, so, without something like a dirtyAttributes check on the model, it's not straightforward to know if a file-based setting takes precedence over a project-config based setting.

[khalwat]

For fluent configs to be supported in plugins, P&T would need to change a few lines in the Plugins service here:

https://github.com/craftcms/cms/blob/develop/src/services/Plugins.php#L932

Basically this:

            $settings = array_merge(
                $info['settings'] ?? [],
                Craft::$app->getConfig()->getConfigFromFile($handle)
            );

needs to be something like this:

            $pluginSettings = Craft::$app->getConfig()->getConfigFromFile($handle);
            if ($pluginSettings instanceof BaseConfig) {
                $pluginSettings = $pluginSettings->toArray();
            }
            $settings = array_merge(
                $info['settings'] ?? [],
                pluginSettings
            );

untested, but roughly something like that

[brandonkelly]

We’ve been down this road and it ends up being more involved than that. I have a bunch of notes jotted down on how we can add support for it in Craft 5, but can’t do it before then.

[khalwat]

The difference in behavior from the array-based file config overrides is that objects return ALL values on their models with defaults, so, without something like a dirtyAttributes check on the model, it's not straightforward to know if a file-based setting takes precedence over a project-config based setting.

What I would do in this instance, and perhaps P&T could implement it at a base layer for plugins at least, would be in the init() method for your base config, you read in the project config settings. Thus the base config is always populated with the user settings, and anything layered on top of that is coming from the config file.

Then to tell if a value is being overridden by a config file value (such as to display a warning in the CP to let the user know), you'd just compare the value from Project Config to the value from the config file

If they are different, then the value is being overridden by the config file

If the values are the same, then the value is not being overridden by the config file (even if technically it is). I think dirtyAttributes might be a little overkill here.

[BenParizek]

My concern in the implementation that you describe here is that even if I know the default user settings from the base config on the module, if the override is coming from a BaseConfig object I do not know if the value being overridden is a default value from the model or a default value that the user chose to set in the file-based overrides.

I'm not intending to express a view on how this is best implemented, but as a developer I'd just like to be able to call a method like ->getIntentionallyModifiedOverrideAttributes() and know the items the user intended to set overrides for.

Or a utility method that does that for us and maybe even helped merge and prioritize:

1. ENV overrides with our preferred prefix
2. File-based config overrides from our target config file
3. Project config overrides from our target project config key
4. Defaults from our Settings model

[brandonkelly]

We aren’t ready for plugins to start supporting fluent configs yet. It will be possible in Craft 5, though.

[acalvino4]

@brandonkelly In craft 5, will implementing fluent configs for plugins be a matter of extending from BaseConfig? I ask because I've run into a use case where it would be helpful for my Settings to extend another model, which would preclude the ability to extend from BaseConfig in the future. If so, I'm wondering how feasible it would be to implement BaseConfig as a trait to allow this flexibility.

[brandonkelly]

Perhaps!