What's the future of Kirby?

You might have noticed we like kirby (a lot)
Kirby seems to have a focus on «simple» projects

But we like kirby so much we are already trying some arguably complex stuff
Because this is how I think complex projects should work too

The question is what’s the future of kirby in regards of complexity:
Are you planning to let kirby handle more complexity in the future?

For example I read you have some sort of “user management” on the pipeline.
Are you planning to invest in more “complex” stuff? or don’t want to go too far?

It would be amazing to create a fairly complex web application with kirby!

I suppose you need to define complex.

IMHO Kirby can become challenging when:

  • your website is very large with lots of pages and files
  • you need to have dynamic content on your website

For the first situation, please check this:

For the second situation you can use something like firebase, or if you want to avoid vendor lock-in, an open source equivalent (shameless plug: I’m working on diskette which is my attempt to solve all my dynamic data problems).

I agree with @dfreire that it depends on what you define as complex. There are quite complex and large sites built with Kirby out there, for example the sites of the Nimbus Group.

What I really like about Kirby: It is so flexible that you can make your sites complex by extending the functionality.

Regarding user management: It is planned to support user permissions (code already exists), but we can’t say when that’s going to arrive.

1 Like

By complex I mean anything that kirby doesn’t do out of the box, but if it did, it should belong to the core (not plugins). E.g. user permissions.

I know kirby can have plugins, but I’m interested in the core.

What’s the future of the core?
Any interesting plans other than user permissions?

Just curiosity, I don’t have a specific interest.
Actually, there is very little I would ask kirby for after user permissions.

Well, if your question is:

then the answer is no: The Kirby core won’t ever handle stuff that’s not part of its core. :smiley:

Just kidding, I see your point. :slightly_smiling:
Bastian wrote about the plans for Kirby in this topic.

1 Like

I’d love to see the Kirby core stay on its current course of well-thought out features, performance improvements, decrufting, etc. Also remember that the Panel is not part of the core, and I think it’s important to keep it at arm’s length.

The question that I’m most interested in is how the community can contribute maintainable code. We have a folder structure that separates plugins, controllers, templates, snippets, blueprints, and fields.

Plugins and fields are usually fairly self-contained, and I’ve grown used to using git submodule to keep them organized and up-to-date.

But what about something like @molocLab’s recent Calendar board field? It’s a custom form field that also comes with a blueprint, and it’s reasonable to assume there might be templates that come in future versions. This is a great contribution to the Kirby community, but all the relevant files are scattered about and this will make it hard for version control in the future.

Perhaps the Kirby core should evolve to include some kind of manifest or package manager to handle the ever-growing community of contributors.

Of course, this should be simple enough so it can still be managed with drag-and-drop file management in Windows explorer :wink:

Edit: I also forgot about config values like routes, user roles, and language variables.


@lukasbestle I think that’s good answer to my question
Thank you very much :thumbsup:

@dfreire Good points, thank you :thumbsup:

Leaving this open for further discussions.

Agree. I wrote about it here a while ago. I don’t think anyone saw it, but it’s there. :slight_smile: