What’d be probably an interesting in-between is to push for more plugins to be part of the official getkirby plugins repository on Github.
I’m not so sure of this. I think it works fine with the inofficial
Kirby Plugins repo to find the plugins and the Kirby CLI to install them.
If I would have one of my plugins on getkirby plugins repo then I would feel guilty if not keeping the plugins up to date. I would love to be in places like Macotuts or Kosmos, but in the getkirby plugins repo, no thanks. I don’t want to have that responsibility.
It would be great to have small collection of plugins that kirby developers think, that should be in the core, but aren’t implemented the right way just yet.
That would be a great insight. Anyway, I think that the crew many times are focusing at things that can not be built as plugins and that’s even more important.
Minimizing the amount of plugins for one use case would be a good start to prevent multiple / outdated / unsupported plugins.
I really like that approach. One plugin, one task. That’s the way Gulp works.
Take my Kirby SEO for example. It’s ment for one thing and one thing only and that is to be able to write a title and meta description. It may look like two things but it’s the serp (search engine results page) part. Nothing else.
Compare that to any WordPress SEO plugin. It tries to do much much more things. It’s really popular as well, but I don’t like it. I think it’s kind of professional bloat. It contains, breadcrumbs, facebook tags, twitter tag, canonicals, sitemaps etc.
I was dependent of it for a period of time and needed to replace it. It was not easy but in the end I found about 5 different small plugins that did the trick. One sitemap plugin, one breadcrumb, one title+description etc. (that was before my Kirby time)
It also reminds me of life in general, to not be locked up to a large solution. To instead choose different small things to build something bigger.
I don’t agree kirby is just for developers. I am not a developer, but I love it.
I think it’s for the people who are not afraid of some code. But yes, the barrier is very low, else I would probably not have started with it.
I understand that plugins make it easy to grow the functionality quickly, but at the cost of quality.
I don’t agree that it has to be at the cost of quality. A plugin can be as well coded as the core. It depends on the developer. But yes, it’s always a bigger risk to add plugins in general than not adding them.