Cannot use plugin vendor as top-level key in site config

[bezin]

Hi all,

I am not sure whether this is a bug or misusage or a known limitation. Please act as you see fit :-)

Description

Using a plugin vendor as top-level vendor key breaks option lookup from plugins.

I grouped some arbitrary config options for a project with our vendor presprog. I use this for some theme-related settings like switch ing some things in snippets on or off, basically.

// site/config.php

// …
'presprog' => [ 'some_theme_setting': false ]
// …

We also have some custom plugins that are named presprog/pluginname which also have some options:

// site/plugins/plugin/index.php

// …
App::plugin('presprog/pluginname), [
  'options' => [
    'nested_option' => [ 'some_plugin_setting': false ],
  ],
]);
// …

Expected behavior
I have the options only defined in my plugin index file. I have not set or overwritten any value from my site config. When I use the following in my plugin code, I expect $option = false

$option = option('presprog.pluginname.nested_option.some_plugin_setting')

However, the following happens: Kirby splits the dot-notated key and checks, if the first key (presprog) exists. It does, because I have my theme config grouped under this key. Hence, it does not try presprog.pluginname next, but checks for ['presprog']['pluginname']['nested_option']['some_plugin_setting'] in the config file, instead of ['presprog.pluginname']['nested_option']['some_plugin_setting'].

As this key does not exist, null is returned instead of false, hence the plugin default options do not work.

Now the obivious quick-fix is to use a nother top-level key like app or site. But I just wanted to leave this here to reason about how to deal with this in the long run.

Your setup

Kirby Version
4.1.0

[afbora]

We may be able to solve this issue in an easy way, but it will involve a big breaking change. I don't see an easy solution other than using another top level key as you have done as app, site.

[distantnative]

Maybe someone else from the team remembers why plugin options are added as ['namespace.pluginname']['optionname'] instead as ['namespace']['pluginname']['optionname']?