I wonder if it would be a good idea to group assets, snippets and templates in a theme folder (site/theme). I mean in a future Kirby version.
It could be possible and practical?
You can do that with a plugin, but if it would be for your entire site it would be a hassle imho.
If it was for me I would follow the “Kirby conventions” about this.
What would be the advantage, considering that templates and content files are closely related?
Maybe this will help?
If I would create a theme of some kind I would probably make a plugin and call it
my-theme. That way the theme will be separated from the other things. I would also register all needed things with the extension registry features.
Yes, I know that content, blueprints and templates are closely related. The idea would be to group the theme files in a folder.
I have no experience developing plugins. I suggested it as an idea to integrate in the folder structure.
I also like to follow Kirby conventions, you avoid a lot of future problems.
I don’t think there will be a theme support in the future (I can be wrong). Kirby is very different in structure to other CMS:es for example WordPress.
While WordPress uses hooks and filters everywhere and always have like a default setup of fields in the admin, the Kirby setup is much more customizable. For example, the blueprint can be empty and no fields would show up in the Panel. Just a thing like that would be hard in WordPress.
I think theme support can work but I also think that it would be tricky to get it right. It would probably generate more support questions like “My theme does not work! Why not?”. It could also attract the “wrong” kind of users, the newbies that never seen a computer before.
So to make it a core feature can be good but can also be a big risk. It would lead Kirby into a path that would be hard to back away from later.
Yes, I like the WordPress theme structure, but I see it would be difficult to adapt it to Kirby.
Anyway, the idea came to me looking at the Jekyll theme system and how it groups templates and styles.
@11bits don’t forget that you can customise Kirby’s folder structure, so you can, to a point, separate the mechanics from the content and style (you can pull Kirby and the panel etc out of the webroot, so your just left with content and assets in the webroot). That makes it easier to swap things in and out, but your still tied to naming conventions in blueprints and stuff, so its not really “plug and play” - your going to have to patch up content and stuff if you theme swap.
My own approach to “theming” (for want of a better word) has been to build my own “starter kit” that I use as a base for every site. This covers all the common stuff so i don’t have to wire it all every time (forms, pagers, SEO settings, navigation helpers etc). That way I’m not inventing field names for common data in every project, and i get some consistency. From here, i just add the stuff specific to the current project.
I find a utility theme like this is quite valuable - i can turn it into just about anything. Working in this direction is easier then using an existing theme and adapting it to my current project (which, for the most part, you find your self deleting and recoding bits, which is counter productive).
Another approach is to use something like the modules plugin and build up a collection of prebuilt modules that you can drop into any project.
I create themes for selling and I prefer to keep the original folder structure.
And I agree, I also use a “starter kit” it’s the best way to DRY in every project
What if you have to make an update to the base theme, though? Would you then have to manually add it to each site you’ve already created?
Not with the way i do it. I use the Kirby Plainkit plus my own plugins and a build system. A Kirby plugin can just be blueprints and snippets if you want, and this way make it portable and easy to update accross different projects. My comments here relate to Kirby 3 now, since this thread was started for Kirby 2 and is three years old now Kirby 2 is also no longer supported.