Static website generator
- Thread starter Lee
- Start date
A snippit from my intended post that was too long, bottom line, I went with Kirby.
The second contender is Kirby, I have looked at it 3 times in the last couple of months. Commercial software, mmmhhh, not so keen. However, all the source is there and available on GitHub which you can download and dissect. The difference is that if you want to use it live then you need a licence, it calls home. Super simple bypass but I am not into that, in fact, I am an avid contributor to all Open Source projects I use so the cost is not a limitation. And if you consider that Grav will have a paid Admin Panel component soon.
Kirby is easier to get up and running than Grav, LAMP/LEMP, dump the files in, no unusual configurations, it just works and everything is up and running. You can either go for the starter kit which provides a basic theme, project pages, blog and about page or use the plain kit which is core plus panel and off you go from scratch.
Out of the box, Kirby the panel is very underwhelming where Grav was over, in fact on face value Kirby lacks so much. Ah, think again. What Kirby does is simply give you a starting point. Very basic form for pages and posts, a title and a text box along with a save button.
Want to add a file for a cover image, no worries just edit the blueprint for that panel page, and voila! Add a cover image, tags, date, categories or whatever else it can be done in seconds.
This is where Kirby really stands out from the start, it is a flat file CMS to build what you want; however you want to do it, it makes no assumptions about what you are going to need and lets you make all the choices.
Create a panel page for blog posts, done in 5, create a homepage with several sections that can be all be edited from the panel, done in 10. About page with a photo, some blocks about you or other people, done in 10.
Have what you want and need in the panel to build the site, nothing more.
Kirby is built on PHP, only PHP. So, you need to know it reasonably well to get by, for the best experience though, know PHP well and you will be a whiz in no time. Editing files is all PHP based, no templating engine, yes the <?php dosomething(); ?> Hi there <?php dosomethingelse() ?> method is not as attractive as Symfony’s Twig or Laravel’s Blade but it works and still only requires PHP. A template engine component is however available if you really want one.
The documentation is rich with code snippets and the forum is very active and helpful. Many of the plugins are created by the core team and are free to use. Overall the documentation is good but patchy, a few 404’s when searching for things.
I think what caught my attention most of all is the familiarity of it being so PHP centric, a clear object and method model. When building the blog, I realised there was too much logic, not an issue, dump much of that page into a blog class and done.
Overall it is so much cleaner than Grav. Better? Subjective but in my view yes.
In terms of the time, it took me 3 hours to get the same result from Kirby as it did Grav. The difference is that I know every inch of that site because I built it from scratch using my own PHP code. Grav was pretty much drag and drop though and I did not get the final to stop my twitch when it came to content position and so on, it would have taken far longer to hack through what was already there.
In no time I was $page->children()->visible()->flip(); and I did not need to look at the docs, I knew exactly what the result would be and it was the desired one. Certainly, there is a lot of snippet code to do all the things you would want to on the site, but if you are fairly comfortable with PHP it’s not required after a while, you know what is needed.
So, whilst it is commercial based on a team of 5 it is mature, 2009 I think it was created. Updates are not as frequent however they don’t need to be having looked back at the history as it has a clear vision of what it wants to be and how it will develop.
At this stage I can find very little to bother me other than patchy docs and I mean http://yoursite.com/tag:tag – really a colon…
And that’s about it for Kirby so far. So, a TLDR in the form of 4 for and against.
Pros:
Easy to set up and get going.
Clean PHP Object and Model Method. No templating engine.
You build based on your project, it gives you the tools, up to you what is used.
Well supported with great themes (costly), lots of free plugins and an active helpful forum.
Cons:
Documentation is patchy.
You really need to know PHP OOP to get the best out of it. Not really for a novice.
$19 for a licence to use on a single site.
Won’t work on IIS (Not a con, just thought it was funny).
On a test of 1,000 pages created with 5 paragraphs of lorum and 3 images per page, there was a noticeable difference in the search and recovery but still very quick and faster than Grav. Testing on a BuyVM cheapest slice.
If I could sum up Kirby. I was fully in control of my site.
The second contender is Kirby, I have looked at it 3 times in the last couple of months. Commercial software, mmmhhh, not so keen. However, all the source is there and available on GitHub which you can download and dissect. The difference is that if you want to use it live then you need a licence, it calls home. Super simple bypass but I am not into that, in fact, I am an avid contributor to all Open Source projects I use so the cost is not a limitation. And if you consider that Grav will have a paid Admin Panel component soon.
Kirby is easier to get up and running than Grav, LAMP/LEMP, dump the files in, no unusual configurations, it just works and everything is up and running. You can either go for the starter kit which provides a basic theme, project pages, blog and about page or use the plain kit which is core plus panel and off you go from scratch.
Out of the box, Kirby the panel is very underwhelming where Grav was over, in fact on face value Kirby lacks so much. Ah, think again. What Kirby does is simply give you a starting point. Very basic form for pages and posts, a title and a text box along with a save button.
Want to add a file for a cover image, no worries just edit the blueprint for that panel page, and voila! Add a cover image, tags, date, categories or whatever else it can be done in seconds.
This is where Kirby really stands out from the start, it is a flat file CMS to build what you want; however you want to do it, it makes no assumptions about what you are going to need and lets you make all the choices.
Create a panel page for blog posts, done in 5, create a homepage with several sections that can be all be edited from the panel, done in 10. About page with a photo, some blocks about you or other people, done in 10.
Have what you want and need in the panel to build the site, nothing more.
Kirby is built on PHP, only PHP. So, you need to know it reasonably well to get by, for the best experience though, know PHP well and you will be a whiz in no time. Editing files is all PHP based, no templating engine, yes the <?php dosomething(); ?> Hi there <?php dosomethingelse() ?> method is not as attractive as Symfony’s Twig or Laravel’s Blade but it works and still only requires PHP. A template engine component is however available if you really want one.
The documentation is rich with code snippets and the forum is very active and helpful. Many of the plugins are created by the core team and are free to use. Overall the documentation is good but patchy, a few 404’s when searching for things.
I think what caught my attention most of all is the familiarity of it being so PHP centric, a clear object and method model. When building the blog, I realised there was too much logic, not an issue, dump much of that page into a blog class and done.
Overall it is so much cleaner than Grav. Better? Subjective but in my view yes.
In terms of the time, it took me 3 hours to get the same result from Kirby as it did Grav. The difference is that I know every inch of that site because I built it from scratch using my own PHP code. Grav was pretty much drag and drop though and I did not get the final to stop my twitch when it came to content position and so on, it would have taken far longer to hack through what was already there.
In no time I was $page->children()->visible()->flip(); and I did not need to look at the docs, I knew exactly what the result would be and it was the desired one. Certainly, there is a lot of snippet code to do all the things you would want to on the site, but if you are fairly comfortable with PHP it’s not required after a while, you know what is needed.
So, whilst it is commercial based on a team of 5 it is mature, 2009 I think it was created. Updates are not as frequent however they don’t need to be having looked back at the history as it has a clear vision of what it wants to be and how it will develop.
At this stage I can find very little to bother me other than patchy docs and I mean http://yoursite.com/tag:tag – really a colon…
And that’s about it for Kirby so far. So, a TLDR in the form of 4 for and against.
Pros:
Easy to set up and get going.
Clean PHP Object and Model Method. No templating engine.
You build based on your project, it gives you the tools, up to you what is used.
Well supported with great themes (costly), lots of free plugins and an active helpful forum.
Cons:
Documentation is patchy.
You really need to know PHP OOP to get the best out of it. Not really for a novice.
$19 for a licence to use on a single site.
Won’t work on IIS (Not a con, just thought it was funny).
On a test of 1,000 pages created with 5 paragraphs of lorum and 3 images per page, there was a noticeable difference in the search and recovery but still very quick and faster than Grav. Testing on a BuyVM cheapest slice.
If I could sum up Kirby. I was fully in control of my site.
WasNotWSS
Member
Thanks for that writeup.
Overall, it sounds a lot like a "CMS" I built around 2001, but more Web 3.0.
Personally, I'd wrap things these days in Smarty (or a better engine- Twig and Blade in a pure-PHP setup still rubs me a little raw, as I'm an old). I als did php-include types for design which made it virtually impossible to rebuild my system back in the day- and caused me to eventually abandon it.
Maybe I'll give Kirby a glance in the future, but every time I stray, I end up returning to TextPattern (which can do static pages, but really designed for that).
Overall, it sounds a lot like a "CMS" I built around 2001, but more Web 3.0.
Personally, I'd wrap things these days in Smarty (or a better engine- Twig and Blade in a pure-PHP setup still rubs me a little raw, as I'm an old). I als did php-include types for design which made it virtually impossible to rebuild my system back in the day- and caused me to eventually abandon it.
Maybe I'll give Kirby a glance in the future, but every time I stray, I end up returning to TextPattern (which can do static pages, but really designed for that).
I dropped TextPattern pretty early on as an option, the issue is the focus, big gaps in the development, I likened it my coding when Pascal and Cobol was a thing, when I needed the money I put more effort in otherwise I just left it. Just lacked consistent development. Powerful all the same.
WasNotWSS
Member
Fair enough. I've been rocking it for over a decade and throwing my own code at it when I need things- never had a breach or any other issue with it, unlike, say, WordPress. Development is slow, when Dean left and WP took over CMS for the masses, I think most of the dev team disbanded and just went to do their own thing.
There is big difference between something like Kirby or Grav and a static site generator like Hugo or Pelican. I really do not see the big advantage of the former, apart from slightly easier set up, and perhaps slightly better performance.
On the other hand, static site generators give you security, simplicity and dirt cheap hosting even for a busy site. I have not used one yet, but am looking at a few (Pelican or Nikola, most likely).
On the other hand, static site generators give you security, simplicity and dirt cheap hosting even for a busy site. I have not used one yet, but am looking at a few (Pelican or Nikola, most likely).
wlanboy
Content Contributer
Simply true. I don't want to get anything running on my server that is scripted on python or php. The teams of the projects are too small to get everything covered an fixed.
I am using hugo for quite a long time. It can even handle php stuff if I need something out of redis or mongodb.
You can use them to generate php code or copy php files to the public folder which I rsync to my remote folders. But this php/ruby is only reading out of databases, no inserts, updates, or writing files. DB users do only have grands on select.
In the not so new world of async microservices I have a lot of backend ruby code doing all the stuff that should not be done on the frontend.