Suggestions for Kirby options

Kirby 2 Suggestions đź’ˇ
1

We are using the same options that Kirby does in the core. That can be a problem. The options are increasing with every version. Now there are about 50 “protected” options in there.

If I make a plugin today with options, who knows if Kirby takes that “key” in the next version?

https://getkirby.com/docs/cheatsheet#options

Suggestions for a solution

  1. Use something else for built in options, like k::get('a.kirby.option');
  2. Use something else for user options, like u::get('user.option')
  3. Prefix built in options like c::get('kirby.cache')

The second one are backward compatible.

2

I would say there is rather the need for plugin developers to really use specific names for their options. And looking at the upcoming registry, that allows plugins to register blueprints, templates, snippets etc. this becomes even more important.

3

I agree! We already talked about a developer guideline internally and this should be part of it, together with naming convetions for classes, helper functions, etc.

3 Likes
4

@distantnative

Somehow I knew that you was going to say that.

Maybe I’m over analyzing stuff but maybe I create a plugin called tinyurl. Therefor that would be my prefix of all my options.

Then my options would be like:

tinyurl.controller
tinyurl.folder

Oops! tinyurl.folder is already taken by the Kirby core. If the Kirby core option would have been named kirby.tinyurl.folder the problem would have never existed.

@bastianallgeier

Would be nice to have something to grab on to. Else it’s hard to know. Can I use the option seo.controller.path even in future versions of Kirby? How can I be sure? Right now I can’t be, but I simply need to calculate the risk of that just that option key is taken or not.

5

I agree with @distantnative on this.

Even if there was a separate user configuration object, how could you be sure that no other plugin developer uses the same option as you?
A separate user configuration would therefore only add complexity (“wait, does this plugin require c::set or u::set?”), create bugs because of that and wouldn’t even really solve the problem.

My advice: Use namespaced config options like myplugin.something and if you see that there is a conflict, update your plugin with a non-conflicting version. The chance of this happening is so slim that any extra effort on either side is not worth it.

1 Like
6

I totally agree, that was my first thought as well.

7

Downvoted by the whole crew. I’m feeling that I’m going uphill now. :wink:

A similar issue I had recently was when I created a field and needed to have some kind of “form field type element” in the blueprint.

I know that type is already taken and probably field too so I tried element and that gave me strange html. Maybe that’s taken as well.

Helper

I understand the reasons for not changing the c::get and all the Kirby options.

What about creating a helper function for it, like this (in a panel field):

print_r( $this->methods() );

Return an array containing what is already taken by the core:

[
'label',
'type',
'element'
];
  • Fast way for a developer to see what’s already taken.
  • It’s faster than browsing to the Kirby docs.
  • Everything might not be in the docs.

This feature could be used to more things than just a panel field, like:

print_r( c::get('methods') );
8

If we implemented that at runtime, people would start to dynamically change their option names, which also doesn’t make sense.

My approach when developing plugins is: Always namespace, and if even that doesn’t work while testing, I quickly see that something else is in the way. Let’s not make Kirby more complex here. :slight_smile:

9

That hill just gets steeper. I think I’ll give up on this one.

10

Don’t do that. :slight_smile:
Maybe we can find a great solution for this.

11

I’d recommend having a developer guide with conventions. Nothing enforced in code but some good recommendations.

For instance plugins could try to use a config prefix like "plugin.mypluginname.". Of course there could still be collisions between plugins (two plugins picking the same name), but that would avoid collisions with core features ("featurename." prefix) or older plugins (often using “pluginname.” prefixes).

The “this wouldn’t prevent collisions between plugins” objection is basically the same as saying “you have 2 problems, and if you can’t fix both you should’nt fix any!”. :wink: I say a recommendation that avoids collisions with Kirby core is quite good enough, especially as collisions between plugins are not as critical as collisions with Kirby core.

For PHP classes, maybe using a Kirby\Plugin\MyPlugin namespace?
This kinda requires you to spam use statements (or do stuff like class MyComponent extends \Kirby\Component\Something {}), but that’s an okay cost IMO and nobody would be forced to follow this recommendation anyway.

1 Like
12

I agree with you. Some “standard” plugin conventions would be great.

  • Prefix for options, like plugin. or whatever it might be.
  • Something for classes, namespace or prefix.

Now I got some distance to this issue and can see it more clear. A plugin convention guide might be the only good approach here.