I could think of dozens, but I’m going with: NoDB. Deploying, backup, version controlling, creating content and the whole workflow is soooo streamlined compared to a traditional CMS.
What’s the main reason you love and use kirby?
I have to agree. While I love so many things, especially the often very intuitive ways of accessing, filtering,… fields, it is NoDB that seals the deal.
Just comparing how awful it is to move between local development, hosted presentation and client’s deployment hosting it is every single time I have to do a Wordpress project. That’s just such a pain and I’m so much more happy with Kirby in that regard.
1 Like
As a (almost) non-developer, I’d go with NoDB too. Git all the things.
Another big benefit for me is not having to deal with environments/VMs/server configs. php -S is good enough for my needs for now.
1 Like
I also agree:
- NoDB makes developing, testing and deploying so much more fun
- Git workflow
- full control about how information is organized and retrieved
- straightforward template development
- Markdown (although I’d really like some more features added to MD)
- great prototyping tool (and free)
- quoting myself
: https://www.texniq.de/en/blog/i-am-a-kirby-addict-10-plus-reasons-why-kirby-2-is-worth-more-than-a-try
3 Likes
Wow, what a flattering thread 
But seriously, for me it’s super interesting to hear your reasons why you like Kirby and of course also the stuff you don’t like. So keep it coming!
2 Likes
What I don’t like (since it’s NoDB):
There are no primary keys. So if you link an article in a template and you change the name (yeah, yeah, you shouldn’t change names because of SEO, I know) - the connection is lost.
Even worse: If you grant access for a specific user, you shouldn’t change the user name.
It’s not a no go - obviously I love Kirby a lot - but sometimes I wish there would be primary keys
Also: Changing a template name (in production) is kind of annoying since you have to change the content files, blueprint file and pages allowed as subpages in blueprint. After making that mistake once, I really think about naming a template now 
2 Likes
Oh and the agency I work for, thinks the awesome documentation & support is the biggest advantage.
1 Like
Ha, best topic ever… I could write here for days but — you know it — I’m biased. Big time.
Lookin’ forward to reading your thoughts here though.
1 Like
Yea, suffering with this at our conference site a lot at the moment as we move the talks/speaker folder structure to our past-conference-archive after each conference. Kirby works perfectly for moving the data around with a simple folder move and everything has the new layout and so on – but what I’ve been missing are some sort of permalinks to the speaker sites that don’t care if they are still in the current conference section or moved to the archive.
1 Like
The primary key thing can indeed become a problem sometimes. You could of course work around that but not too easily. Your friend in general is the new router. Redirections have become so easy with that. Especially for the conference site I’d really add redirections for speaker pages - maybe even dedicated urls for each speaker:
http://yourconference.com/speaker-name
and redirect that to wherever it makes sense. You could even write some small code which automatically looks for speakers by template for example and creates the redirect no matter where the speaker page is at the moment. That way you wouldn’t need to update it at all.
Basically what you get with Kirby is a hybrid between something entirely static and something database-driven. With an entirely static site you would have exactly the same issues and there’s hardly anything I can do about it. I guess there are always some pros and cons for those kinds of aspects and in the end it’s all about what is more important for your project or how easy is it to work around the issues.
1 Like
I completely agree with you. It’s a small price to pay for all the advantages. And the router does indeed solve most of the problems, but it’s still a bit inconvenient.
how about an auto generated id-field that isn’t shown in the panel (like sort for files) - that way you could link to both the uri and the id
Well, with sites that are 100% panel driven, this would of course be no issue at all. One of Kirby’s major advantages in my opinion though is that you don’t need the panel at all. I know plenty of users who don’t even have it installed on their servers. In such a case it is impossible to implement such an ID field and it would also be very distracting if you really just work with the text files.
good point…
so maybe a panel plugin
There’s another downside - performance. With unique IDs the lookup would always include all pages. For a small site that wouldn’t be a problem but for a large one this would suck compared to the way pages are detected by path.
1 Like
Again: valid point
Templating is super easy. Learning-curve is, well… flat. A panel clients are comfortable to work with. Updates are easy. Licences are cheap. There’s no end to it. Love it.
4 Likes
The reason I like Kirby is because it gives you the option to choose rather than forcing you. This really holds true for databases. I’m not against them, they serve a purpose but it’s nice that Kirby allows you that freedom of flexibility.
2 Likes
KIrby has No DB and even Beginners can use all those tools which are at their disposal for simple yet individual web development.
1 Like
Simplicity. Kirby is structured so cleanly and the documentation is superb—I’m primarily a designer so it’s nice to feel like I actually understand how things are built and function in Kirby.
3 Likes