Effort to clean up the panel by adding more functionality (...)

Kirby 2 Suggestions 💡
21

hi thiousi and thanks for your feedback.

[quote=“Thiousi, post:19, topic:5113”]
See from my point of view, Kirby targets developers that build websites for themselves and for clients.
[/quote] I don’t agree kirby is just for developers. I am not a developer, but I love it. Having a web frontend for everything doesn’t make a CMS easy. Even with Wordpress we used to fiddle around with database queries (and there are several dozen each page call and no one knows what they are doing). Only plain text files. This is what I can understand.
I think it is very elitarian to think only coders can handle kirby. This will lead to nothing.

I understand that plugins make it easy to grow the functionality quickly, but at the cost of quality. It is the easiest way of contributing to a software project. It is an easy way to distribute work to periphery developers. Plugins are not bad in general, especially for seldomly applied purposes. They can be good to see if something is useful. If like 50% of the installations use it, why not make it core?

22

I’m not so sure this is a good way to go. The “official” plugin that existed before the move to the new one, also included several plugins by other developers, which then at one point in time were outdated. I think an official repo should only contain plugins developed by the team, or plugins the team is willing to maintain in the future if they are abandoned by their developers, or plugins that could eventually become part of the core.

Having said that, not all plugins should be made part of the core, because they are not needed by everyone, e.g. something like the patterns plugin is great as a plugin but no need to include it in the core.

2 Likes
23

I don’t think it is elitarian. There is simply no way today in Kirby to customize the look and feel of a standard installation without having a tiny bitty knowledge of code. If you’re fiddling with database queries, you’re not like 95% of wordpress users that have never seen a line of code and never will.

There’s nothing wrong about choosing a target clientele and serving it well. If Kirby was targeting all types of users from your granny that has never seen a line of code to power users, it’d slide slowly towards becoming Wordpress. That’s my opinion. I don’t think my opinion is elitarian. I think anybody that wants to take the time to learn Kirby can. But they’ll become a form of developer. I’ve pushed one of my clients who loved Kirby and read through the code I wrote for him to try adding a blog to his site. I gave him some example codes from themes I built and he’s having a blast learning and trying. He’s not a developer at heart. But what he’s doing is development.

4 Likes
24

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.

1 Like
25

[quote=“Thiousi, post:23, topic:5113”]I don’t think it is elitarian. There is simply no way today in Kirby to customize the look and feel of a standard installation without having a tiny bitty knowledge of code.
[/quote]

I agree with @Thiousi on that one. It’s not elitist to have a target group, it’s even necessary to have a target group. While we try our best to make Kirby as understandable as possible by providing extensive documentation, and example code and use cases in the cookbook, you won’t be able to do a lot with Kirby if you don’t want to touch any code.

If anyone is willing to go down that road, and learn to code on the way, that’s absolutely excellent :slight_smile:

3 Likes
26

That is exactly the point. There are many tab’s plugins, a few multi language plugins a few xy plugins. Many of these were created by dev’s who needed them for one or many of their own projects. I am greatful that they offer their code on github since it enables me to focus on other important development tasks.
The problem is: they are not guaranteed to be maintained, kept up-to-date, documented and functional for multiple versions. It is my understanding that the inofficial Kirby Plugins repo doesn’t guarantee this either.

Furthermore, there are two kinds of plugins, such plugins that enable front-end capabilities .e.g. a breadcrumb or seo plugin and then they are those which have to be integrated more deeply, like tabs or multi-language plugins (these are the ones that are also a lot of work to maintain and keep up to date).

When thinking about multi-language capabilities (more than we have right now, e.g. deleting a translation - is there a solution yet?, view untranslated pages…(e.g.) )i am sure some of us can get wet dreams, since that is a feature most of us would gladly have right now. Like permissions. It’s nice and satisfying to know that the kirby team is working on that. But while this is the case, it sucks that we have multiple versions that integrate the same functionality in different ways just because we can :stuck_out_tongue:

Maybe, it was not the right thing, to call it ‘official kirby plugin repository’ because that sounds like the stuff has to maintain it. But ‘official kirby community repository’ with some guidance from the stuff, to develop such plugins the kirby way, maybe with input and guidance for the ui as well - maybe with the goal to even use some of that code in the kirby core that we use anyway. If i find the exact same features / functionality of a community maintained plugin in the kirby core i would personally not mind.

just some of my thoughts on possibilities to create less ‘throw-away’ code and keep plugins maintained after someone lost interest in his plugins because it was a one time solution…

27

See this is one instance where I don’t have any problems with the current way Kirby works. Multi-language has worked fine for me and I’ve never felt the need to delete one instance of a page in a specific language. Maybe that’s a feature that some people want, but if it doesn’t serve a purpose for the majority, it’s best as a plugin I think.

28

Deleting translations is something that is probably not needed by many people and can easily be solved with a filter field, I think, if this functionality is really needed.

2 Likes
29

It is my understanding that the inofficial Kirby Plugins repo doesn’t guarantee this either.

Yes, there is no guarantee there. In fact, it’s kind of a minefield. If a plugin on Github is hacked for example we need user input through the comments to close the issue.

I’ve never seen a malware plugin but the risk exists and some plugins are in beta or even mindfield version. That’s also our goal, to provide everything without judging.

multi-language […] permissions

These things are often hard to handle with a plugin. Parts of it yes but not the whole thing. Therefor I hope that most of the important stuff goes into the core.

I often see plugins as “proof of concept” to prove that something is possible. WordPress has a “plugin first” approach that I like and I use that approach quite often myself. I try to see if something is possible with a plugin. Then I hope at some point that some of the more core-like features will be implemented some way in the core. It has not happened yet tho. :slight_smile:

But ‘official kirby community repository’ with some guidance from the stuff

I don’t know if that’s good for the motivation. I like to feel that what I built is mine, even if I at some point give the whole repo away. Else authority is lost. What I do want is more people to add issues, pull requests etc to the plugins but not many people do that.

Deleting translations is something that is probably not needed by many people and can easily be solved with a filter field, I think, if this functionality is really needed.

Agree. This requires some screen space as well, a button. I think the core should be a little bit harder on stuff that requires UI addition than just in the code. If it’s in the code it’s never in the way.

30

I think I understand now what you mean by “focusing on developers”. It just means that it is not hiding complexity, where it does not make sense. I can totally agree on that one. I am absolutely happy how kirby works and quite confident it will do so for a long time. I wanted to share some of my experience. I understand there are “official” and “non official” plugins. I think this is already a good approach and points out which plugins can be trusted, as they are widespread and well tested.

1 Like
31

I think this is already a good approach and points out which plugins can be trusted, as they are widespread and well tested.

Yes but there are some really popular plugins out there made by users so I would not narrow down to just use the Kirby crew plugins. Then you will probably miss a lot.

Take this for example:

It has very many Github votes, very popular, even more votes than the Kirby Panel. Now it’s a little bit miss leading because I think people need the panel more and the builder is dependent on the panel.

Anyway, what I try to say is, don’t miss out on the good stuff. :slight_smile:

32

This feature is already implemented in the develop branch of my translations plugin and may be pushed to the master soon … Don’t be confused by the screenshot, it’ not up to date. And of course, feel free to test it :wink:

33

Very interesting discussion! I just want to add what has already been said:
Making all popular plugins official means that we will have to maintain all those plugins. Integrating those features into the core is even worse as the core will become bigger and bigger. That’s why it makes sense to have those plugins maintained by the community. In case some of those plugins will stop working and the original author doesn’t have time to fix them, we can try our best to help. :slight_smile:

1 Like