I dont have any connection to the company but for small webshops doing custom small-mid sized sites this is awesome. We have many sites built in kirby and its far better than any cms we have tried. And we tried everything.
Its something between static site generator and full blown database cms. Its easy to debug and you can deploy just with git.
There are other similar cmses Grav, Pico, Statamic. Kirby is the most mature and just works best.
Well, here is the point of view of a back-end developer (database) that scratched his head on Jekyll last week trying to figure out how to just make a damn god simple (but customisable and multilingual) blog using almost only markdown...
I just spend around 20 minutes on each kirby documentation pages and on grav docs.
So after 20 minutes with kirby doc I have figured out how to reach my goal with kirby even if there are some downsides and that i'll have to remind my old php courses to customize.
but after 20 minutes on grav i'm still trying to figure out if it's gonna be as simple as I need or if I'll have to understand if a twig templating of my markdown, already accelerated with parsedown and doctrine in a pimple dependency injection container will help me manage my YAML simple configuration along with the Symfony console...
YES this is all from learn.getgrav.com > BASIC > What is Grav? - the first goddam chapter of the documentation !
So the landing text of the doc is basically throwing at me that i'll have to ingest a bazillion new front-end trendy concepts while actually I just want a Markdown based site...
Maybe grav is great but i'll probably never know because documentation killed all curiosity in me.
Its much older. Kirbys admin is the big difference.
In Grav admin you have problems when you start to have more than 30 pages. Because of its design it shows pages as flat structure. In kirby its more like folders. In grav you cant say this type of page can have only these type of children. Basicaly you have to remember which page type belongs to this page.
Kirby comunoty plugins are awesome kirby-modular for exp.
Kirby also has permissions in admin, so you can limit users what they can do.
Its also way easier i think while achieving more. There is clear path of how things work and Grav is somehow overengineered idk why i would my simple cms to compile stylus or js... it uses twig which is fine but i found it to be wrong choice because in cmses like this you are traversing trough the pages (pages are your db). Twig is not meant to do that its for showing already queried stuff from db. So they are basicaly recreating more and more php in twig so you can actualy get the data.
Yes, totaly. This is why we use it. You basicaly make yaml schema of the conent in admin interface and then simply query it in template.
There is also core plugin called kirby modules which turns kirby into very sophisticated "site builder" we use it to make highly modular websites while keeping it simple for clients to administer.
They dont have to. The admin is basicaly big form field generator that maps values to markdown.
So you make field for everything. Dates, checkboxes image selectors..
Only time they would have to touch markdown is when they would need to format text - article for example. This can be solved by using wysiwyg field instead of md field.
Seems to be not open source[1], which is a deal breaker for me. It is also in PHP which I also frown up on for a rather new project in this day and age.
I do not see how it could win me away from either QOR (Go), Grav (PHP, but MIT licensed) or DatoCMS (SaaS but ties in with Hugo).
If you need clients to manage the site than Gravs admin interface is horrible especialy if you have more pages - there are dropdowns everywhere so good luck if you have 500 pages. Also grav allow restroctions in admin so for example if you have /blog which contains blogposts you cannot say that /blog can only have pages of type blogpost - it shows every single type.
Issues about this on github are ignored by Grav core devs on purpose. The reason for this is that they are company with bussiness plan and they are preparing their commercial "Admin pro" while they leave the basic interface just crippled.
I would like open source too but fees are low and the devs are extremely open.
Also kirby has much cleaner api, its much older and mature and the support is amazing. There are dedicated support people on their forums and you get response very quickly.
From where you are coming from - i dont think its thing for you. Its aimed at noobs and rapid dev of presentational sites.
Datocms is interesting - we've been using cloudcannon for our website and found it could aside from the speed. The advantage over Dato would be the wysiwyg in-place editor. So you can edit a page "live" which is important for placement.
Is running it with an admin interface an option? I'm looking for a good CMS I can deploy for others (less tech-inclined) where they could still make their own small changes.
Yes both have admins and as i wrote in coments around i think admin is what makes kirby highly superior.
We always have problems with clients not being able to edit things in wordpress.
In kirby its possible to do in much simpler way. Basicaly you create admin that has only the content. No settings and user managment and all kind of useless functionality..
Grav is fine too but users will have to learn a bit more. Its more clunky and not so dumbproof.
In all of the filebased cmses the admin and the core are separate. Core renders stuff from files. Admin is just for creating/editing filest. They dont know about each other.
I used Kirby for a travel blog a year ago. I needed something lightweight, for which I could prepare material offline and then upload when I had connectivity. Android phone + bluetooth keyboard were the preparation tools.
Using Kirby was an enjoyable experience. Easy to setup, good docs. Easy to work with on the road. A copy of the blog on the phone and on a thumb drive.
I can't offer a comparison with other file-based cms. Didn't look around. Though I don't doubt there are other very capable offerings out there. Tried Kirby, found it to be a low fuss solution that met my needs and didn't mind paying the few quid to continue using it.
You just described Movable Type (https://movabletype.org/), which was WordPress before WordPress was WordPress.
The irony here is that the reason WordPress eclipsed Movable Type was that people got tired of having to go through the edit-output static files-publish cycle to modify their content. They wanted to make their changes in an editor and have them appear immediately on the live site, without waiting for a new set of static files to grind out. WP, which generates all pages dynamically, met that demand nicely.
Then of course people eventually discovered the downside of generating every page dynamically, namely that it's much more resource intensive, and started to clamor for something more efficient. So the current wave of static site generators were born, doing the exact same thing MT got killed in the marketplace for doing.
Yeah, I learned about MT's approach from Jeff Atwood back in '09, and have been reading about the new "discovery" of the static site generators with some amusement.
That said, MT has a big issue: for something that has been killed in the marketplace, it's quite expensive. I'd love to use it for the non-profit I help out, but at a $1000, it's about $950 more than what they can aford.
The last time I used WordPress (fortunately, very long ago) the most popular caching strategies were SuperCache (writes HTML files to the webroot) and Varnish (a caching reverse-proxy.) In both cases it's trivial to separate the static content from the administrative area. I don't recommend this (I don't recommend anything WordPress) but that seems like what the poster is asking for.
Is it just an honor system licensing? If it's a file based CMS, nothing stopping me from putting the files on any webserver right?
Edit, to answer (from the docs):
There's no validity check of your code or any other communication between your Kirby installation and the Kirby server. You get a clean installation without any hacks or tricks. Entering the license code is for your own records, so you can track which installation uses which license.
I'm focusing on making Kirby better instead of fighting software pirates. I trust in you to support me with a legally purchased license if you like Kirby.
It is. Legally you need to pay a license to use it and to get tech support, but if you never ask for support, no one is going around checking for non-licensed users. I roll the fee into my expenses when I use it for clients.
Its been going strong for years. Its small well run german team of few devs. It has solid userbase in europe (germany).
Bastian Allgeier the founder and main developer is very open about everything.
I wouldnt worry about stability here because those guys make their living there and iam sure they dont want stop. If they did im sure Bastian wouldnt just leave it and would figure out some future (open source it).
"NoSQL? Kirby Prefers NoDB!
Kirby is file-based – No database involved. This means first class performance,
version controllable content, simple backups and many other awesome sideeffects."
What other "awesome" sideeffects? I tried the link and found only a download page. I also scanned threw the documentation and found no further statements and no explanation.
Seams to me, that the claims are just made without any explanations or prove. Sad.
Edit:
The claims are nice, but many of those are rather thin. For example, content in a database is also version controllable. I see no substantial advantage here in content on the file system.
It is just marketing spin. "File-based CMS" just means an editor/authoring tool. FrontPage was a file-based CMS. Dreamweaver was a File-based CMS. Heck, Sublime Text can be used as a file-based CMS, if you are comfortable with WYSIWYG not being a requirement.
It looks like it doesn't store any data at all, it is completely stateless. You'd have to overlay state by e.g. pointing Kirby at a git repository. Likewise access control, review, etc.
Therefore, of course it's high-performing -- it doesn't do anything (much).
Not necessarily, have a location that the user writes to that is readable by one other user who can write to the webroot (and has nologin, etc). Run a cron job as the other user every few minutes or something to sync things.
Anyone know if this is the right tool for what we are trying to accomplish?
We are creating a CSV of thousands of food and allergy-related items, and want to automate the creation an independent post for each item. We can use another type of input instead of a CSV, as long as we can do it in bulk.
We want to have these pages to be SEO optimized for easy discovery on Google.
We could use wordpress with a mass importer, but it has a lot of bulk. These file-based CMSs look interesting.
I can second this. I've built an index of scientific papers before with Jekyll's data feature. Built remarkably fast even with a lot of loops over the whole dataset.
Wordpress isn't bulky because it runs on a database, although you might say that running it with a database in the backend does allow it to be bulky...
The storage medium isn't really what you should be choosing your CMS on, I think. And depending on your required features and expected traffic volumes, I'm not sure there's much need to choose something else.
Sure, other CMS will serve pages faster and handle more visitors better natively... but WP can get you cheap devs fast, rather than casting around for niche workers.
Beware that you get what you pay for. If you need a high-traffic capable product with lots of modern web stack in (like React and some WebSocket thingies) and you plan to choose a fresh stack then going with WP might just be total productivity killer on the project.
WP is not a place to build your custom stuff on top of. I worked on several projects where we used WP headless, as an admin interface (since web master teams love it), but relinquish all the template rendering to an app framework (Rails in our case). We open sourced the infrastructure of it[1].
Not that Rails is so fast, but we knew it well and caching/ integrations with APIs/ ElasticSearch are all quite straight forward in Rails.
This smells of NIH to me. You built a presentation layer for WP in Ruby because that's what you are comfortable with. There's nothing wrong with that, but don't pretend that you are building anything other than (possibly) useless middleware. If you wanted a fresh stack with WP, you would use the WP API, Vue or React coupled with any caching software (Nginx, Varnish).
> fresh stack with WP, you would use the WP API, Vue or React coupled with any caching software (Nginx, Varnish)
Has been considered.
But there where many integrations that were required, and they are simply too simple in Ruby land. Also we needed to take traffic --yet serve dynamic pages-- and support user logins. The solution I mention does use WP-API, but on top of that it also allows "previews" and the "admin bar" (would be quite interesting to implement those with React).
edit: That we had a lot of Rails expertise in house did help, as mentioned. We also do plenty React, but a lot of the integrations needed to be server-side and many were batch-processes.
Hey, folks! I've read the whole there but I couldn't figure out how to deal with some dynamic content. Let me expose what I mean: I have a blog. I want to create posts. So I'd write my blog post and publish (write my blog post to disc as a static file). How could I instantly see the new blog post in my home page?
With all the discussion around other decent options for Content Management Systems, I'm surprised nobody has mentioned OctoberCMS (http://octobercms.com/) yet.
It's an awesome, highly extendable, very clean CMS to work with as a developer. Based on Laravel, it's also open source: https://github.com/octobercms/october
It gives you all the power of Laravel with some very nice features built in that make developing for it a breeze. Runtime extendable classes, event listeners, Twig templating, and an AJAX framework for interacting with the PHP side of your code are just a few of the features that it includes by default; not to mention the rapid development experience empowered by the Form & Lists widgets.
Been a while since I dug into October, but last I checked its back-end admin area was very much developer-focused (as opposed to non-technical site maintainer)... editing content required editing actual code in a textarea. Has this been addressed in the system at all (or is it even a design goal?)
Exactly what i thought too. I couldnt find the reason for using admin area since my clients wouldnt be able to use it. I guess the idea is to create admin app for clients and this makes sense on big projects it can be done much faster when you do something standard.
Depends on how you set it up. I usually use the RainLab.Pages plugin to have a nice interface for clients to manage page content instead of having them use the CMS editor.
I'm looking forwards to the frontend editing component that's coming to October soon, it should make client interaction with the site much nicer.
The source is there but it's not free nor open source. See the license. I don't know if they're allowed to put such licensed code on GitHub as a public repo.
I only said that it's not open source, and did not say anything against it and its being proprietary. And AFAIK github only allows public repos if they're open source, I mentioned that. Read the thread.
Not to use the code, only to look at it. Per Github FAQ:
You're under no obligation to choose a license. It's your right not to include one with your code or project, but please be aware of the implications. Generally speaking, the absence of a license means that the default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work. This might not be what you intend.
Even if this is what you intend, if you publish your source code in a public repository on GitHub, you have accepted the Terms of Service which do allow other GitHub users some rights. Specifically, you allow others to view and fork your repository.
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
Its something between static site generator and full blown database cms. Its easy to debug and you can deploy just with git.
There are other similar cmses Grav, Pico, Statamic. Kirby is the most mature and just works best.