Folder and template organisation confusion

Kirby 2 Solved ✅
1

Hi all. Just experimenting with Kirby. I’m used to a number of other systems.

I’m really stumped by Kirby’s organisation. There is a site folder which contains the template files, but assets are outside this, and content is also. It seems most of what is outside the site folder is everything that is shown on the site. Locations and names give no obvious indication as to what they are to a beginner (other than templates and content).

Blueprints are fields? Really? We have a word for fields; it’s fields (or custom fields). We have the words variables, data, front matter and form fields. New terminology is not needed. Assets are not in the template folder? Yet they are template assets. This is the norm.

I think Kirby has tried too hard to be different. It nearly finished Drupal, but the system was good enough to get through it. But it changed where it could after realising the mistake.

With the various CMS, static and flat-file options out there, and considering this is a paid one, why try to re-invent wheels that went along fine? Just my 2 cents as a user who probably now won’t be stopping.

2

Thanks for your feedback.

The Getting Started Guide has an introduction into Kirby’s folder structure.

As regards the term “blueprints”, this is not a synonym for field. A blueprint does not contain a single field but a collection of fields that in it’s entirety define a complete form. On top of that, blueprints allow us to define a lot of other settings, like whether or not a page can have subpages or files, the size or number of files a user can upload, meta data fields for images etc. So it would not make sense to call these files fields.

The content folder is a separate unit, because it contains user generated content. By having it separately, you can make it a separate git repository that is stored away from the rest. Also, the site folder can be safely tucked away out of the web root, as it does not have to be writable by the server.

So in fact, there are good reasons for the current folder structure.

But Kirby wouldn’t be Kirby if it wouldn’t give you absolute control over your folder structure. So if you don’t like the default structure, you can move everything around.

Interesting that you talk about norms. I haven’t seen any two CMS where the folder structure was identical, let alone speaking for itself.

3

Fair points. Yes, you’re right about norms and no two CMS being the same. Just done to me not explaining that well. But I still think blueprint is an odd choice for a CMS term. It’s real-world meaning I could see being implied to system architecture, but not having sense here. Based on your explanation, a folder called fields, collections, data or metadata would have make more sense to me.

I also saw snippets is a term which is predominately referred to as partials in most other flat-file and static systems I know of. Plus the more I look at it, I think snippets, templates and assets being separate directories is confusing (they could be in a theme directory, for example.

Yes, it’s good the structure can be changed. But for me, as a new user, it’s better to go with how it is, and these things say something about the overall approach. Drupal lost tons of ground due to many being put off because of it’s confusing initial appearance. I genuinely see Kirby falling into that trap.

4

There is a site folder which contains the template files, but assets are outside this, and content is also.

I don’t use the default folder setup. Just to see what you can do, look at this: Alternative Folder Setup.

With the various CMS, static and flat-file options out there, and considering this is a paid one

I thought the same thing a few times before I got used to the idea. You can use it without paying for it until you are satisfied. When you are satisfied with, it I don’t think it’s too expensive.

why try to re-invent wheels that went along fine?

If all of them would work the same, we would only need one CMS. About the blueprint, it’s not the only CMS that use that name and I think it’s good to not reinvent the wheel in that case. :slight_smile:

If you like Drupal very much, maybe you should go with that but if you want to try out something else, maybe Kirby is for you.

1 Like
5

I don’t agree with you here. “Blueprint” in its meaning of “model”, is a fitting term here. It is neither a collection, nor data or metadata, but a model for a page form in the Panel. Check out the blueprint docs if you like. In fact, Grav uses the same term. And I guess, I could find other CMS that call partials snippets (Yellow, Feindura).

But IMHO, these are just words. If naming of folders keeps you from using a system, that is fair enough and of course your decision. What counts for me is that I get a system I feel comfortable with, that gives me a great amount of freedom to build what I or my clients need, both with an ease of use for me as a developer as well as my clients as users. Absolute freedom with regards to structuring content. Easy PHP templates without additional template languages (but the freedom to add that if I want). And a whole lot more including fair licensing/pricing and a great community of dedicated people.

Yes, they could be. But assets must be accessible by the browser, while templates, snippets, controllers and all the rest can live outside of the web root, so it does make sense to separate these things.

Edit: And one more thing: If you are happy with your current CMS, there’s certainly no reason to change. If you want to embrace Kirby despite its folder naming , we are here to help smooth the process.

Disclaimer: I’m part of the team.

1 Like
6

@mikeuk i understand the confusion, this is very normal when trying out new thing isnt it! I can asure kirby is much much simpler than Drupal so don’t overthink it.

I think you have to realize that kirby is mainly aimed at much less experienced developers than Drupal devs. Its main aim is simplicity. If you can make sites with Drupal - Kirby is going to be piece of cake. And you might find it to be extremely fast for development (reason why senior devs around here are using it).

Considering the Blueprints. I dont know how many cmses you’ve seen but ive seen a lot and Blueprints its actualy very common name for files that describe how the admin area (panel) will be generated. Ive seen two types of approaches cmses (that have same funcionality) to take:

  • They either describe pages and call it a blueprint (blueprint for mapping of many fields belonging to page)

  • Or they dont think in pages at all and describe content and call it something like content type (you create type of data with certain properities - fields).

Its the same thing just from different viewpoint.

By the way - worpdress and drupal dont have similar functionality without doing lot of additional work. In wordpress to get custom fields example you need sophisticated plugin (and the good ones cost money) that changes the way wp works. And while i like Drupal more than WP - Drupal is actualy very oldschool in its thinking and the namings in drupal are very nonstandard. Of course Drupal also grew from CMS into almost aplication platform - it tries to be so universal so you can use it as backend for anything. Its much bigger in scope.

With kirby its much simpler and more focused. Its just about creating websites.

7

I’ve tried smartypants but never the worpdress. :smiley: :wink:

1 Like
8

Engage WORPDRESS!

Need to make that.

1 Like
9

I come from a WordPress background.
I had to adapt to this new concept and it actually was a blessing to get rid of the theme thinking.
Themes often lead to configuration and configuration leads to unnecessary complexity for clients (when you are not actually building a theme for sale).

Of course you have to adapt to the “kirby” approach.
But the beauty of Kirby is that you can almost change everything to your needs or preferences. And trying something new without adopting any new approaches somehow defeats the purpose of trying something new in the first place I believe (besides databas vs. flat file).

Give it a try. For me personally it was totally worth it.

3 Likes
10

I did not expect so many replies. I must admit I kind of jumped in a bit with a critical perspective, so appreciate the calm replies. I guess I feel too entitled to an opinion as I get involved in projects I use, helping a lot and with occasional contributions. It also makes me determine to make the switch to a system that will fit (I’ve already done too much switching).

I don’t agree with you here. “Blueprint” in its meaning of “model”, is a fitting term here. It is neither a collection, nor data or metadata, but a model for a page form in the Panel. Check out the blueprint docs if you like. In fact, Grav uses the same term. And I guess, I could find other CMS that call partials snippets (Yellow, Feindura).

Fair enough. It’s one of the oddest CMS / development terms I’ve seen since first coming across Drupal’s taxonomy. Thank you for model, that means so much more to me. I think that word clarifies what blueprints are. Maybe I willl just be obstanant and continually refer to them as models…

Although this is the only bit I’ve quoted, a lot of interesting things were said in the other posts. Too many to know what to do with. Thanks to those that posted alternative folder organisation. About the ‘why not stick with Drupal’, that was two systems ago. It would be my choice for a large project but I want to focus on small business websites and a model that will provide content control wiithout bloat, with easy styling and easy duplication to keep costs down.

Off-topic, I actuually only tried Kirby because I couldn’t get Grav admin panel to work on my Linux localhost. It was a post relating to Kirby that had the solution, so decide to give it a try. The initial appeal was the functional but simple admin panel that was an integrated part of the system.

I also don’t quite get Twig in the PHP world. PHP + HTML, and with MVC if preferred, seems to be fine.

I am not a markdown fan for HTML web content though. It think it looks horrible to non techy clients, but there’s no easy way out of that where static or flat file systems are concerned. Short term I’m looking at ways so content editors won’t need markdown. Longer-term i’m going to look at a plugin.

11

Well Grav panel is nowhere near the kirby one. Trust me i tried hard. There are few issues the philosophy behind it (dropdowns everywhere) that make it particulary unusable after you have 20 pages. This happens especialy with things that you have in bigger numbers like blogposts or any kind of events etc. Most of the rough things im grav you can code around but for this you would need to fork admin and rewrite it pretty hard.

The pitty is that this seems to be on purpose. Because they are planing closed source “admin pro”. Authors of Grav are normal bussiness. Company that builds worpdress themes. And this was aparantely plan the whole time. Build hype, take some customers from kirby and statamic and then have them pay.

Now i am not against paying i think this keeps everything healthy. But this smells to me. besides if i am paying, why would i not take much more mature Kirby with awesome support? Its just little trick to get customers - you start coding, you make most of the site in grav, you crash into limits… by that point its much cheaper to buy admin pro than rewrite. This ecxact thing happened to me. I would actualy buy it they havent released it yet. So i had to rewrite.

There were people talking about fork on chats. But thats far away, it would probably happen only if the company changes bussines plan and close the source at sone point. I am not saying this will happen but many things can happen when you have single company running open source project.

So dont be mistaken Grav is not your regular grassroot comunity opensource project like worpdress or druplel. Unfortunately.

1 Like