The page about Plugin Registry is missing documentation on registering the following components:
Would be great to add these.
Thanks a lot,
Mo
I’ve added an issue on Github: https://github.com/getkirby/getkirby.com/issues/272
There is now more detailed documentation on the registry, see this commit. The new documentation will be live on the Kirby site soon.
One more important question: Is an option set through $kirby->set() in the registry permanent or only valid for in the scope of a plugin’s execution. If it’s global this might indeed rise some concern regarding both the loading order and compatibility of plugins making use of changing such global options.
As you can see in the registry class, the options are set directly on the Kirby object, so they are global and permanent. Do you have an example how that could break code?
Sure. I could just go for setting the date format to strftime to solve https://github.com/moritzz/Kirby-Blog/issues/1 and match the functions used in my templates, but this would break Kirby core’s and other plugins’ date output.
Yes, that’s definitely true. You shouldn’t set options that you don’t fully control. A good example would be setting the cache options in an advanced caching plugin, but setting the date format in a blog plugin is indeed not going to work.
I would recommend to use strftime directly in your plugin instead, then you are fully independent from Kirby’s options.
True, true. Or I will just come up with a solution that first checks for that setting and uses the appropriate date format argument.
Hey @lukasbestle and @texnixe. What about this solution? Cheers, M.
That looks good. However if a new date formatter option is introduced in the future, your code will break. So I think it would be easier to use strftime('%Y-%m-%dT%H:%M:%S', $this->date()) instead.
Your probably right. I just thought encouraging Kirby SDK use in my code. I’ll rewrite my model and release it later on with potential other fixes.