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

[philipp]

Problem:

Using kirbys integrated features sometimes lacks functionality and results in cluttered und unfunctional UI. This in turn leads to the use of plugins. Plugins are not necessarily ‘paid’ and therefore well maintained. This can lead to kirby installations that can’t be updated properly to negate security issues.

To name two examples that would make a great addition to the kirby core and that are not necessarily bloat on top of a slim fine awesome CMS:

• Tabs plugin
• Translation Plugin

Why would these two plugins be a great addition to the core?

• Tabs plugin:
  Sections already are a great way of structuring content, but they make forms really long and hard to keep track of. With tabs, or an Anchored Navigation at the top (Maybe Mockup later here). The UI could be improved. Additionally this would allow users to create a ‘META TAB’ With Information about: POST / DRAFT Status or Expiration and Publish Date and or SEO Information. In short: Stuff that isn’t really content but has to added anyway. This is currently really bad in Kirby. IMHO.

• Translation Plugin:
  Either you want a multi-language site or you don’t. For the users that wont multi-language sites a lot of features have ben added in kirby 2.3 like the new blueprint fields and more functions. Now it should be time to update the kirby UI. It has to be more evident which translation is being worked on, which pages are translated and which are not and maybe it should even be possible to delete some translations or specify which pages are to be shown and which are not.
  Adding these features by hand or with a plugin again leads to a larger code base, more stuff to configure and maintain and to larger forms.

Conclusion:

It would be great to put some love and maybe color into the panel, since this is where our CLIENTS spend a lot of time editing and curating their content. I, as a developer love kirby a lot and i am not missing many features. The images field was a great addition to the increasingly larger feature list. Occasionally i am missing a list field, but w/e Lets make Kirby great for our clients too and improve the panel

Thanks for your attention

EDIT: Updated links to the plugins…

[Thiousi]

Hi Philipp,
I suggest that you write individual feature requests for each of the struggle points you’re having.
In an effort to make those feature requests as useful as can be, try to do the following:

1. One request per request (yes this sounds weird): If you have several features you’d like to see implemented / fixed, list them one by one in separate feature requests.

2. Provide details for the problem you’re trying to solve instead of a specific solution to that problem that you’re looking for

3. Follow a simple explanation format:
   a. brief explanation of request
   b. what’s the current situation
   c. what is the desired outcome
   d. what is the benefit of this change
   e. what is the inconvenience of this change

4. Be ready to implement it yourself and submit it to the core. Only do this after creating a feature request first as mentioned above. If you can, create a branch of the core and implement the feature request yourself. Submit a pull request that “fixes” your feature request. Don’t expect all pull requests to be merged though.

@philipp

It would be great to put some love and maybe color into the panel,

Putting some “love” and “color” is typically the kind of client feedback you’d see on sites like “customers from hell”. The panel’s css is available for anyone to modify. You can create your own version of the css that corresponds better to your taste but don’t expect everyone to have the same taste. I don’t want Kirby to start getting bloated away by options such as the color of the navbar in the panel. If I want a red panel, I’ll make a red panel myself.

I’m sorry if my reply sounds rough. I really think that there’s some great ideas in what you’re suggesting but I don’t see how a post with a couple ideas tossed together will help.

This brings us to a broader topic: Kirby is not your typical open-source project with many contributors and clear contribution guidelines. Maybe this could change. I’d love to know @bastianallgeier 's opinion on contributing to getkirby.

[philipp]

Hey @Thiousi while i think it is a good idea to seperate feature requests, this is barely a suggestion at this point and a topic to talk about. I would rather have this a one topic where everyone can comment and add their opinion.

When it comes down to the feature requests, tickets should be created in git. One for each feature or set of features that is worth implementing ( which i think we should talk about ) for now this is just a suggestion to improve some parts of the panel.

I bet some users and plugin developers that already have come up with great ideas can improve my ideas, so that they become valid feature requests.

@Thiousi

Putting some “love” and “color” is typically the kind of client feedback you’d see on sites like “customers from hell”.

Sorry. Will be more specific next time.

@Thiousi

The panel’s css is available for anyone to modify. You can create your own version of the css that corresponds better to your taste but don’t expect everyone to have the same taste. I don’t want Kirby to start getting bloated away by options such as the color of the navbar in the panel. If I want a red panel, I’ll make a red panel myself.

Thats pretty specific. I am referring to features that a lot of us use, but that aren’t maintained by @bastianallgeier and stuff. Like for example tabs, which imho don’t add much bloat and improve the ui. I guess the question is: which features are necessary and which are not, sure there are projects that don’t need tabs and where a form is enough, but sometimes it’s nice to have them… But personally, i’d rather have tabs then sections ;D

@Thiousi

This brings us to a broader topic: Kirby is not your typical open-source project with many contributors and clear contribution guidelines. Maybe this could change.

Recently i have seen more plugins released, then questions asked - or at least i had that impression. I as well would love @bastianallgeier opinion on this, maybe it is possible to find some shared ground, where some solid plugins can be added to the getkirby repo and maintain them as a community so that they don’t deprecate when the next version of kirby is release and work well with the existing codebase / ui, - as submodule or plugin.

[bastianallgeier]

Thanks for the feedback! We always appreciate to hear such pain points. They help us plan the next steps. What we try to do is to collect them all and then decide for each new release, which features should make it to the core and which should stay optional. It’s a really tough decision each time because the requirements for each site are vastly different. For example, I still build a lot of client sites myself and I never ran into the requirement for tabs with my clients. But I totally see their point and in fact we have them on the internal feature list for a very long time — just most likely not in the form of tabs. It’s sometimes maybe a bit difficult to understand from an outside perspective, why things don’t make it into the core, which seem so obvious, or why it takes us so long to build them. But especially tabs are a great example here. We just don’t want to toss in “obvious” solutions. Everything we add comes with a cost. It’s not necessarily about adding bloat, but more about code complexity, UI complexity, maintenance and sometimes even about necessity. We always ask ourselves over and over again if a feature is really needed and if the majority of users will benefit from it. We also ask ourselves if there isn’t a better / more simple way to achieve the same result. In case of tabs, I really believe that we can do a better job of organizing form elements. We only didn’t tackle it so far, because other fundamental features had to come first.

I also agree on your second points about translations. We definitely can become better there. The best way to move such ideas forward is to post an issue on Github. Especially with the new issue reactions, we can measure quite well, which feature requests are more “urgent” than others.

We already added quite a lot of improvements in the last releases, which always had their origin in such feature requests. I think in general if you take a look at the changelog, about 80% of all changes come from user input.

About the panel UI: It was a very clear decision right in the beginning, that the UI of the panel should stay as neutral as possible. This helps to not make it “The Kirby interface” but focus on the client’s content and their brand instead. I actually even thought about removing any form of color at all, but that is simply not possible. I agree with @Thiousi that the custom panel stylesheet should always stay the place where to add modifications, if you need them.

[Thiousi]

Thanks for your reply @bastianallgeier

I think that what you explain here is very interesting. Can I ask what your opinion is about user contributions to the code base?

Looking at the contributions on Github, I don’t see many people (excepted for translations). And more to the point: there are no contributions guidelines. Judging from what you just said and the experience I’ve had with kirby in the past, the effort that’s put into developing each feature the right way is my favorite feature of Kirby. However, I would love to be able to contribute to the core with proper guidelines if that’s something that you and the team are looking for.

I’m pretty sure the situation is complex. Between taking the time off from coding to write down those contribution guidelines, reviewing user submitted pull requests, weighing the pros and cons of each addition to the core… I’m not pointing fingers and saying tackling this is easy. I just want to hear your thoughts on the topic if you can.

[bastianallgeier]

We regularly get PRs and we try to include them, whenever possible. But you can see that we also have quite a couple open ones. That’s totally our fault because of not having such guidelines.

Maybe it’s interesting to shed some light on our internal way of doing things at the moment:

1. Lukas and I discuss the features we want to add for a new release and we start working on them separately.
2. For complex features we discuss very extensively how we want the APIs/methods/UI elements to be and we plan different use-cases in code and see how useful the new stuff really is in real-life scenarios.
3. We discuss the consequences and possible breaking changes and if they will be acceptable or not.
4. We discuss possible needed translations and add them to Transifex.
5. We build on separate branches and review them afterwards. We use Git flow feature branches for that.
6. We add tests whenever possible
7. Everything we push to Github is also being tested by Travis CI, so we see when we broke something.
8. We add docs for every new feature and we also instantly describe the new feature in a new changelog entry, which will be published on the site once the release is done.
9. Before every release we do additional tests in our testkit setup, which has extensive blueprints for every panel field and also additional plugins installed.
10. Since our cookbook has been released, Sonja has started to join us afterwards by writing matching recipes for new features, which is pretty awesome.

The reason why there is no guideline yet, is simply the amount of work that would need to be put into it. In my opinion such a guideline should contain the following:

1. an extensive coding style guide, which describes how we format Kirby code
2. an extensive description of Kirby’s core and panel architecture
3. a guide how to write tests for the core and for the panel
4. a guide how to extend the testkit.
5. a guide how to write docs and changelog entries
6. a guide how to create PRs and how to describe them in the most useful way
7. a guide how to work with our panel gulp setup to make changes to the css and js for the panel.

I think it becomes obvious that — if done right — features take a lot of effort. I didn’t even mention browser tests and responsive adjustments, when we build new UI elements for the panel.

In the beginning of Kirby, I mostly built stuff in a very relaxed and fast way without caring too much about such things, but we try to become more professional with every step we take and that unfortunately means that we are getting slower in preparation, but it will also save us all time in the long run.

[Thiousi]

Thanks for your answers and the very interesting insights into your current workflow with Lukas and Sonja.

Judging by your answer I think it’s fair to say that we won’t see contribution guidelines right away. It’s totally understandable as this is something that would require a lot of time to put together.
Is it your assumption that the amount of work required to build a feature into the core the right way with the same level of tests you have today (unit testing, non-regression testing, cross browser and platform testing) and the same quality of documentation will simply prevent people from contributing? And to push further the conversation, is this one of the reasons that the - albeit considerable - effort to write contribution guidelines and all accompanying documentation was not undertaken to date? I’m sure you have to weigh the pros and cons of every minute you invest in Kirby and I also know that every decision is taken seriously. In your opinion, does the potential benefit of having more contributors not outweigh the time investment of permitting those contributions and controlling them?

There are some great things to learn from large open-source repositories and maintainers. I’ve been very interested in the stories that some maintainers share online about this. There are lots of struggles for sure and I’m glad that we’re talking about this. I’ve heard you explain how you came up with the licensing scheme of Kirby in talks you gave and read more about it online and here as well. It is my understanding that Kirby isn’t really an “open-source project with a licensing deal to help maintain it” but rather a “commercial project with an open code base”. This has never bothered me in any way but the more time I spend working with Kirby, the more I wish there were ways to contribute. Helping in the forum and writing tutorials and plugins is the best way I’ve found to “contribute” so far. I’d love to get my hands dirty in the code, though

It’s all up to you, in the end, to decide whether the burden of welcoming contributors overweighs the cost. It’s also potentially the strict control of what makes it into the core and when that has made Kirby what it is today. I trust you fully to take the right decisions. Thanks for Kirby

[bastianallgeier]

This is a really interesting discussion and a topic that has been following me ever since the first day with Kirby. Your understanding of Kirby’s model is pretty on point. It’s a commercial product with an open code base. That’s sometimes a burden and sometimes its cure. I think it has helped us to keep it constantly maintained and focused for the last four years. I saw quite a lot of open-source projects go down in the same time. But it’s also really tricky to let people contribute.

I think we gain all the benefits from an open-source project in terms of transparency. You don’t have to take our word before you purchase a license. You get to try it and you can explore each and every line of code and check for yourself if it is good or not. It feels right from our perspective, because we know that we didn’t “trick” people into buying. We really have to earn your trust first.

But it’s still a commercial product that makes money and that has a revenue stream and there’s money ending up on our accounts. Let’s be honest, that money plays an important part in keeping us happy and focused.

The question, how to earn money and at the same time accept PRs from contributors is a really tricky one though. Of course the PRs are totally voluntary and people who help us with PRs on Github or translations on Transifex are well aware that Kirby is a commercial product. But to be honest, I don’t feel as comfortable about accepting those contributions, as I would be, if it was an open-source project.

In my wildest dreams I always imagined a shared revenue model, where we somehow measure the quality and effort that has gone into a PR and pay out a share to the contributor. But how? It starts with the measuring process. How on earth would you do that. Lines of code? Written test cases? Lines of docs? There is no technical way of measuring it and as soon as the team starts judging, it becomes personal and unfair again. But even if we would be able to find a really fair system, the bureaucracy behind it would be total nuts. Remember that it’s a German company

So we are back at voluntary contributions. All contributions come at a cost, no matter if it’s an open source project or not. A PR has a ticking clock attached to it. You have to go through all the code and see what has been done there. Does it fit? Is it well written? Is it secure? It’s sometimes really easy to accept small PRs, which fix a small bug or add a very focused improvement. But whenever it gets more complex, time is such a huge factor. If you combine that with the time we spend on our own plans and features and the support we provide, it’s often really hard to reply to PRs and all the issues on Github at all. Then there’s the human factor. We get voluntary contributions to a commercial product and it sucks big time not to accept them. It feels ungrateful. At the same time, as you said, we really think that our way of “leading” Kirby sets it apart. It makes sure that it doesn’t simply implode with too many careless additions. It might even be one of the main reasons why people actually pay for it.

But don’t get me wrong! The feedback here, the PRs and all the issues on Github are pure gold! I think this is also what sets us apart from other fully closed commercial products. The community around Kirby is very open-source like. We got massive amounts of help from day one and it has always lead to better versions with many ideas and improvements, we wouldn’t have found on our own.

This discussion alone clearly shows, why it has been the right decision to go this way. It might be tough to balance the two worlds from time to time for us all, but I’m quite confident, that we will get the best out of it together.

I think it would be great to go forward with such a guideline, even if it might not be complete from day one. Maybe you can even help us with it. As long as you feel it’s worth contributing to Kirby, we will definitely keep on doing our best to keep you on board and happy

[Thiousi]

Thanks for your thorough answer. It means a lot.

@bastianallgeier

I think it would be great to go forward with such a guideline, even if it might not be complete from day one. Maybe you can even help us with it. As long as you feel it’s worth contributing to Kirby, we will definitely keep on doing our best to keep you on board and happy

If not for a full contribution guideline, at least a “message from the team” that summarizes what you just said above would be a good starting point

[philipp]

Sorry for writing back a little late.

Thanks @bastianallgeier for the insight into the kirbyproject. Some points made during this conversation are really interesting. I also think it is good that kirby is a well curated open-source project - mainly by @lukasbestle and you. And i don’t think i have to add much more to this:

@bastianallgeier

This discussion alone clearly shows, why it has been the right decision to go this way. It might be tough to balance the two worlds from time to time for us all, but I’m quite confident, that we will get the best out of it together.

Looking forward:

@bastianallgeier

I think it would be great to go forward with such a guideline, even if it might not be complete from day one. Maybe you can even help us with it.

To simplify your and our devs / clients it would be great to have guidelines. Maybe to get started, we could lay a foundation with a boilerplate for the first four steps of the process @bastianallgeier and @lukasbestle go through when evaluationg a suggestion:

@bastianallgeier

Lukas and I discuss the features we want to add for a new release and we start working on them separately.
For complex features we discuss very extensively how we want the APIs/methods/UI elements to be and we plan different use-cases in code and see how useful the new stuff really is in real-life scenarios.
We discuss the consequences and possible breaking changes and if they will be acceptable or not.
We discuss possible needed translations and add them to Transifex.

I believe a lot of discussion around such features happens in the forums as well. A lot of us have clients too or use kirby for private projects. On one hand some stuff is easily fixed with a plugin or some additional lines in the stylesheet on the other hand are more general problems that might be annoying in multiple projects that require deep integration (e.g. i saw a feature request to simplify routes in multi language installations).
Maybe it might even help to have some more people discussing such topics since collaboration is gold. In the end it is still your decision whether or not requests, in form of suggestions, feature requests or pull-requests go through or not.

All the best
Philipp

PS:

A friend of mine @FabianSperrle also submitted some pull-request and was sad they didn’t go through, he would have been proud to contribute to the awesome Kirby project

[lukasbestle]

I see your point that it can be frustrating if PRs and feature requests don’t get included in Kirby. It was the same for me actually, since I started working on Kirby as a community dev as well.
It’s just difficult for us to review everything and even then we sometimes have to wait until enough people have asked for a feature and until we have a solid and future proof solution.

Example: Permissions. We are well aware that you guys want permissions for literally years. We have been working on this feature for more than a year and are in the process of finally finding a good solution we are comfortable with.

I totally agree with:

@philipp

On one hand some stuff is easily fixed with a plugin or some additional lines in the stylesheet on the other hand are more general problems that might be annoying in multiple projects that require deep integration (e.g. i saw a feature request to simplify routes in multi language installations).

There are a lot of plugins that hack their way into the core to provide a feature that would be better implemented in the core in the first place.

But, same thing as with permissions: Sometimes, it’s just not very easy to find a good solution and a solution that people actually want. Throwing new features in and then realizing that just one person uses them like we implemented it while others would have liked another implementation means that a) we wasted time on an implementation that no one uses and b) we now have a feature that we can’t remove or change again easily.
Good solutions take time. And while that definitely can be very frustrating, at least you will get a good solution at the end.

[Thiousi]

@lukasbestle

wait until enough people have asked for a feature

@lukasbestle

a solution that people actually want

Thanks for participating in this thread Lukas! The two quotes from your reply matter a lot to me. From what you and Bastian have said, this is something you’re both equally very considerate about. And this should definitely be outlined somewhere (in the contribution guidelines?):

If you have a feature request, submit it, explain what it’s about, why it’s useful, and if enough people feel the same way, we’ll do our best to find a solution. There’s no guarantee this will ever be implemented as there are many things that we need to consider before adding features to the core. But the more people you get that feel like this feature should be added, the better the chances. You should also feel free to write code that extends the core to suit your needs, and submit a pull request to share your work. Although it maybe will not be implemented in the core, it could be useful to others.

I guess this all comes down to the tight balance between the greater good (i.e. what the core must have for the broadest possible set of user and use cases without becoming bloated, affecting performance, UX, security, or anything else) and the personal preferences of each individual person (and the specifics of each individual project).

I much rather have a sane, stable, and well-performing core on which I can carefully cherry pick extensions that a bloated powerhouse that tries to do it all and becomes a nightmare to use on a daily basis. I think everybody is going in the same direction in this thread, which is great. It shows what this community is about.

[flokosiol]

@Thiousi

I much rather have a sane, stable, and well-performing core on which I can carefully cherry pick extensions that a bloated powerhouse that tries to do it all and becomes a nightmare to use on a daily basis.

This had been said very often before. But it can’t be said often enough.

[Malvese]

In the Drupal community there is a saying: “Talk is silver but code is gold”. The consequence is that those who don’t code much or at all can’t really have a voice that matters. High level problems discussed by designers and UX people are seldom solved the right way, if at all, and it really shows in the aging end product. After ten years, I see the same issues rise over and over again.

I love the balance the Kirby team achieves between openness, foresight and actual code. I think they are great designers and developers. This is very much aligned with how I approach my own designer’s job. I’ve found a new home.

[jenstornell]

@bastianallgeier

I still build a lot of client sites myself and I never ran into the requirement for tabs with my clients

It’s quite useful when having very many fields. I use one of the tabs plugins myself.

We only didn’t tackle it so far, because other fundamental features had to come first.

Yes, tabs are pluggable so the functionality can still be added. I like that you often focus on the stuff deeper down in the core where no plugins can enter.

pay out a share to the contributor. But how?

I agree. It’s impossible to measure it like that.

As I see it there are only 4 ways to pay back to a contributor:

1. Hire him/her and pay per hour or per month.
2. If it’s a great paid plugin like Shopkit (I’ve not tested it), buy a license.
3. If it’s a great “thing” like Macotuts, buy the whole project.
4. Pay back in other ways like give away licenses, give feedback etc.

@lukasbestle

Permissions […] We have been working on this feature for more than a year and are in the process of finally finding a good solution we are comfortable with.

If I remember correctly @distantnative was working on that. Is he not with you anymore?

Throwing new features in […] that we can’t remove or change again easily.

I think the best features are the ones we don’t expect or understand at first sight, but can be useful in every project, for example the ways to extend the object.

@Thiousi

I much rather have a sane, stable, and well-performing core on which I can carefully cherry pick extensions that a bloated powerhouse

I totally agree. Keep the core as clean as possible, but not cleaner than that. I’ll build a christmas tree out of it (with plugins).

@Malvese

Talk is silver but code is gold

I agree that having too much discussion with the wrong people will give the wrong output, but I also think that it’s good to have much discussion with the right people.

Where I worked before my boss said:

We have a feature request, talk a lot about it so you can code as little as possible. If you are lucky you can shorten the problem down so much that you don’t need to code at all.

An example of a case could be: “How can I add the pages into the database?” and the Kirby answer would be “Why do you need a database?”. I think the crew is really good at this as well, to shorten the problems down to a minimum. @lukasbestle uses the 5 whys.

@philipp

I believe a lot of discussion around such features happens in the forums as well.

I like the animated gifs that sometimes appear on twitter, like the with the new strucure field. That gives us the oppertunity to give feedback.

My personal “problem” is my curiosity. I want to now every feature as early as possible even if the feature will not end up in the final version.

I also want to give the crew credit for being a little more open than before. The releases feels like they are coming more often and we can already read about future stuff in the changelog of 2.4.

[lukasbestle]

@jenstornell

If I remember correctly @distantnative was working on that. Is he not with you anymore?

Yes, the first implementation was done by Nico. He is still part of the team but he has a new project that takes up a lot of his time.
Bastian and I have been working on the permissions feature as the most important task in the last few weeks and so there’s finally progress, it’s just a very complex feature that requires a lot of thought.

@jenstornell

I think the best features are the ones we don’t expect or understand at first sight, but can be useful in every project, for example the ways to extend the object.

Yes, that’s true. We like those features too as they increase flexibility but the added complexity is very small. They are also not features we have to think about that long as the solution we first think of is often the only good solution available/the solution that “just makes sense”.

@jenstornell

We have a feature request, talk a lot about it so you can code as little as possible. If you are lucky you can shorten the problem down so much that you don’t need to code at all.

An example of a case could be: “How can I add the pages into the database?” and the Kirby answer would be “Why do you need a database?”. I think the crew is really good at this as well, to shorten the problems down to a minimum. @lukasbestle uses the 5 whys.

That’s absolutely right, we use that strategy as well. If a problem can be solved with an existing feature, that’s waaay better than adding new specific features and duplicating functionality.

[distantnative]

@lukasbestle

Yes, the first implementation was done by Nico. He is still part of the team but he has a new project that takes up a lot of his time.Bastian and I have been working on the permissions feature as the most important task in the last few weeks and so there’s finally progress, it’s just a very complex feature that requires a lot of thought.

Just want to add: I started a new job at an international university and it has swallowed me more than I expected. And still does. Which is why I have been a lot less active over the last few months, I hope to “return” later this year to my passion for Kirby. However, I already gotta say that Permissions are the perfect example for the way Kirby works. The way the permissions feature is shaping up through @lukasbestle and @bastianallgeier’s work just looks so much better as the implementation Bastian and I started with over a year ago. So sometimes it really needs that long time of consideration, of “thinking it” and then again “rethinking it”. And I so love that approach of Kirby a lot. Even if takes sometimes longer than everyone (community AND team) would prefer. Even if it means throwing away a first implementation that just does not feel right.

Oh and thanks @jenstornell for caring

[mmeinesz]

I want to share my point of view on kirby plugins. I am a kirby user, not a coder, but I happen to know a bit about coding. Consequently this view is the view of a user:

As many of you I switched from Wordpress to Kirby. One of the reasons for the move was plugins. WP has plugins for everything. The worst plugins are probably the ones handling multi language support. Multi language support is a good example for how bad plugins can be. It needs to be deeply embedded into the core WP, which makes it a very complex and heavy code. The resulting functionality has a really bad UI, because it needs to fit somehow into existing UI. Occasionally the plugin doesn’t work the way it should, overwrites content without asking etc. Updating to newer versions of WP can cause problems. This is just an example for one bad plugin. The others aren’t better. Think about incompatibilities between a certain set of plugins combined with multiple versions of the core CMS. There are trillions of combinations, which just can’t be tested. Here is one more bad thing about plugins: Most plugins are “one timers”, which means they are programmed for one specific website (we have done so as well for my company). It very often happens that there is no budget for maintenance. Not every plugin coder wants to work for free. The code might be other than GPL, so nobody will take over. Dead end. Who will test all these plugins and make sure they still operate correctly on the latest version of the CMS?

It is nice to talk about a “slim CMS” for the developer. For a user, who needs a certain functionality, it does not matter if the functionality is found in a plugin or in the core. Many users will find it inconsistent to look for documentation on plugin pages, which are separate from core documentation pages. It can become a great mess for all parties, especially the user.

Remember that Linus Thorvalds choose a monolithic kernel approach. Even in the 90s, when he started, that was not considered very modern. It took some time before package managers like .deb and .rpm could handle complex dependencies and not everything needed to be “complied into” the kernel. Even now Linux is not even close to a micro kernel approach, and the buzzword lost its appeal.

food for thought.

[Thiousi]

Thanks for a great contribution and an interesting point of view @mmeinesz!

@mmeinesz

For a user, who needs a certain functionality, it does not matter if the functionality is found in a plugin or in the core

This is key!

See from my point of view, Kirby targets developers that build websites for themselves and for clients. And that’s one huge difference with Wordpress. It doesn’t try to do anything else but to target developers. And that’s quite important to me. There’s been a trend over the past decade that pushed people to think anyone can build a website without writing a line of code. Sure they can, but it will never be as good as a website built by a developer. Kirby doesn’t target end-users. Sure, you can download a theme and get started really fast… but you’ll have to put your hands in the code at some point… if only to set an option in the configuration somewhere!

And because it is developers that build websites with Kirby, it is their responsibility to cherry pick the plugins and extensions they add. It is their responsibility to document the usage of the website for their customers. It is their responsibility to support the development of plugins they rely on. It’s pure gold if you ask me.

I’m not saying some of the plugins shouldn’t be part of the core. And if it makes sense for them to be a part of the core, they will at some point, in time, and well integrated.

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. There must be something that can be done to go in that direction surely. What’s your thoughts on that @lukasbestle and @bastianallgeier?

[philipp]

@Thiousi

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. There must be something that can be done to go in that direction surely. What’s your thoughts on that @lukasbestle and @bastianallgeier?

+1 up this. 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. Think about it as a in-between ‘solution’/ boilerplate (or any other similar solution for that matter) for common problems (cookbook?).

For the following reasons, that are also true in regards to kirby:

@mmeinesz

WP has plugins for everything.

@mmeinesz

Think about incompatibilities between a certain set of plugins combined with multiple versions of the core CMS.

@mmeinesz

Most plugins are “one timers”, which means they are programmed for one specific website

Minimizing the amount of plugins for one use case would be a good start to prevent multiple / outdated / unsupported plugins.