What's the future of Kirby?

[heyallan]

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!

[dfreire]

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:

Concerns about using kirby for a medium size website that will grow over time

You can have a look at my use cases: http://ruderclub-nuertingen.de Still using Kirby 1, at the moment working on updating to Kirby 2. There are many invisible pages behind which are just displayed as data (at the moment ~300 pages in total). http://wagner-ewar.de The product folder alone holds all ~250 products. Only page loading issue comes by design (at the product line, where all products of one line are displayed on the same page without pagination…). Also doing many connections in betw…

Kirby panel support for database

I think @jenstornell concerns are valid. If Kirby becomes popular for lots of use cases, at some point the community will need to address the performance issues that will naturally arise with trying to handle thousands of files. There are different approaches to how one might solve this. One possibility is to have pluggable persistence, one user might opt to store everything in disk, another might wish to use a database. Another possibility, which I find much more appealing, is to use databa…

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).

[lukasbestle]

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.

[heyallan]

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.

[lukasbestle]

Well, if your question is:

Are you planning to let kirby handle more complexity in the future?

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

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

[samnabi]

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

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

[heyallan]

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

[heyallan]

@dfreire Good points, thank you

[lukasbestle]

Leaving this open for further discussions.

[jenstornell]

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

Large plugins files scattered through Kirby?

There are these things you can do (probably more) that have their own folders: Plugins Fields CSS JS Config (including routes) When making or adding a large plugin that has all these things, is it thought that we should copy the files to all these different locations? What I like I really like to add the CSS and JS myself because I use SASS and other clever stuff to speed things up. I don’t want to be forced to have unwanted CSS files in my theme. What I don’t Think of a plugin that add rou…