Oh, it's PHP - neat. Personally I think Statamic is the entry to beat for flat-file CMSes in the PHP space. This project is the Symfony flavor I suppose (vs Statamic being based on Laravel).
Kirby has a very loyal customer base w/ lots of people that exclusively work with Kirby in their day job (like I am) - there's a new update? People report the first bugs in minutes. Huge benefit of Kirby imho (and also a reason why I prefer it over Statamic, Statamic people are often like "oh you have a question? yeah go look into github issues from over three years ago, i'm not here to help" tbh)
But even from a code perspective I'm not sure comparing repos is always all that useful. I'm not sure about Grav but on the Kirby side, if I'm not mistaken, the current official repo started with the v3 and the two previous versions were archived. So you're only comparing the code activity from ~2019 onwards but Kirby has been around for more than 10 years at this point.
Thanks for the additional info. If we are were to just look at the repo stats, Kirby is a lot more active than Grav right now. Do you happen to know what the archived repos were and if they are public? If you look at https://devboard.gitsense.com/getkirby you can see the insights for all the kirby org repos
I do want to make it clear that Kirby is a very healthy project, if anybody is misinterpreting the data.
They are not available as far as I can tell. If memory serves me well, the current kirby repo had a different name during v3 development and the code for v2 was living in another repo also named kirby. When v3 went live they renamed the two so that v3 became the kirby repo currently online and the old one became kirby-v2 or something like that. And that repo has now being archived apparently.
I've had the pleasure to build a small website with Kirby and it was such a joy to use as a developer. The only problem I faced was with my client as he was used to Wordpress and making the transition to Kirby was a bit rough for him.
Can you unpack this a bit? What was rough? How much of that was the client not being able to change?
I'm lightly looking into alternatives to WordPress. Obviously CraftCMS come up, but being a paid product - nothing work with that per se - does limit its appeal for some projects / client. So maybe there's a place for Kirby?
came here to say this. i went all over looking for a replacement... just pay for it. its exactly what you want. i built https://2020isasong.com/ on kirby and tries to rebuild with grav and ended up deciding kirby was just too good.
Agree and there’s something nice in using a paid product with a simple and straightforward license, no silly subscriptions and from a team that genuinely cares about the product.
Plus the product itself is incredibly good and it’s getting better and better over time.
Statamic is great for simple sites but for larger or multilingual sites it has lots of problems. I have a 5000+ page website that the static site generator takes 3 hours to build and there's been no improvement since v3 launched. You can use their "Static Caching" as an alternative to static generating but for my project requirements I need a purely static site. I'm busy doing a huge rewrite and switching to using Statamic in headless mode with NextJS in the front... which takes just a couple of minutes to generate the static sites instead.
I'm also still waiting for RTL support for languages in the CMS and multi-site permissions which has probably been on the roadmap for over a year but keeps getting delayed. I've submitted many ideas and bug reports on how to improve the multilingual experience but I don't think it's a priority for the team.
A very big German newspaper (https://www.spiegel.de/) runs on Statamic and they probably have an order of magnitude more pages. But not sure what kind of improvements/custom implementations they've done.
> Curious about how SPIEGEL’s stack works? Here’s their high level approach, keeping in mind this is running on v2. Upgrading to v3 streamlines even more of their stack.
> A huge flat file content store organized with each entry inside its own subdirectory (you can’t have more than 10k files inside a single directory, an operating system limitation)
> The content store is using a cloud storage solution.
> Statamic’s control panel pushes entries into the content store, and then into an ElasticSearch instance via message queue.
> ElasticSearch runs as a content API with blazing fast response times and is consumed by the control panel and front-end
> The front-end is built in Go.
> User accounts are connected with an Office 365 Active Directory integration with OAuth.
Serious: you should run a profiler on the generation step (or like... for a minute of it and the CTRL-C out). Often times degenerate cases like this exist but are more or less invisible to maintainers, and just saying "the generator takes forever" is not nearly as actionable as "here's the first 60 seconds of the generation process, does anything look weird?"
I've incidently just completed a headless statamic project that used Astro for the frontend. I'd recommend you check out Astro if you haven't already as dev experiece was great and generally feels a better fit for this usecase over next.
Laravel the framework does use a bunch of Symfony libraries under the hood, but is still a very different framework. Symfony’s library offerings end up everywhere, with good reason. They’re used in but not strongly tied to the Symfony framework.
I used Grav for my CS capstone back in 2016. One of the requirements was to create and host a web page with project details, abstract, etc. I completely forgot about that portion until 2 days before the deadline, and I stumbled on Grav while looking for templates. I had the cleanest, most modern looking site of all our groups up in about 5 hours of tinkering and adjusting and turned what would have been a C into a B+.
Haven't used it since, but I'm glad it still exists.
I worked on the Grav team when it was first created. Remarkable flat-file CMS that it is, it's actually found a lot of great use cases that WordPress just doesn't play well for.
I personally still use and love it even now, a good six years later.
After reviewing the Basics Tutorial[0] I have a few reasons I don't like it, but others may:
- It is not purely Flat File based, but rather a specific Folder structure with specifically named and marked up Files in them
- URL Routing is implicit in your folder structure; however
+ URL Routing has some special cases wherein:
a. Folders named starting with digits and a dot (i.e. "04.") will be "ordered"
b. Folders named starting with digits and a dot (i.e. "04.") will be "included in the navigation menu"
c. Folders named starting with digits and a dot (i.e. "04.") will be have the digits and dot removed in the URLs
d. It is unclear what "unordered" pages mean
e. It is unclear how to escape the starting numbers and dot so that they are included, but maybe just doubling "04.04." would work
- Page metadata such as HTML Meta Title and special CSS classes are included in a special header of the Markdown content
- Page template is determined by the actual filename within the URL routed folder rather than in the Page metadata
Personally, I would prefer a simpler "flat file" format that simply mapped folders and files to URLs in a more naive manner.
Metadata being in the page is fine and can totally include the Template that I want to use for that content.
Metadata within a page could also include the "ordering" and "menu" information.
That said, I'd possibly prefer a declarative mapping somewhere of my templates to folder and file patterns and a declarative mapping of my menus to specific files rather than including that data within the content file.
In my flat-file blog thingy I just included the page's slug in the file's metadata, that is so I could order files as I please but still not break links for page
This keeps coming up and getting recommended, along with Statamic. But everytime I've tried these, they assume you have a full PHP dev environment steup and know all the gotchas. Ive tried Grav and Statamic, and each time hit a stumbling block (something PHP setup related) and found the docs don't talk about it at all.
Its always: Step 1, Step 2.... (jump) Step 10, your blog is running! And Im stucj at step 4 which isn't even documented.
Compared to Wordpress, all these alternatives are almost impossible to even get started with.
yeah, I was thinking it was going to be a thing that generates all the content as files, like Hugo, but with a nice web interface for the admins. But no, it requires PHP to display to the end users.
I wonder how different it is from basically a static site generator re-generating pages once input files change, à la `zola serve`.
BTW I would be interested in a static site generator / CMS that extracts data from flat files (which are the source of truth) and puts them into a database that can be queried in interesting ways during page generation.
I've been building a website in Grav and I've found it a really nice introduction to the world of dynamic content. I was pleasantly surprised by how familiar PHP felt coming from Python, and all the frontend skills of static website building transfer really nicely. Plus the documentation is great.
Maybe in a utopian future, there will be a universal seamless ABI for most dynamic and static languages such that rewriting will be both unnecessary and undesirable.
I agree. As a PHP dev it seems to me that the JS world is stuck on reinventing every kind of wheel for every kind of project.
From what my view as an outsider, it seems that there just isn't as much conglomeration around big projects as there is in PHP/Ruby/etc, or there are many more projects and there haven't been a "sacred few" as winners yet outside of frontend frameworks.
In PHP, I can reliably stick myself in a Laravel/Symfony/Wordpress camp and the framework will either have most of what I need, or the ecosystem will have packages for it that get the job done. In JS, the projects that accomplish the same either don't have much publicity or there's some other blocker.
In other words, where is Wordpress.js? Solve an entire problem for an end user, not just a fellow developer who can operate a terminal.
> I agree. As a PHP dev it seems to me that the JS world is stuck on reinventing every kind of wheel for every kind of project.
Kettle, met pot lmfao.
JS succeeded PHP language as "the first language most developers will most likely experience" and it came with a lot of newbies reinventing wheels with it.
It's depressing when there's excessive imitation without differentiation leading to lack of innovation and too many similar options that lack advantages.
Most small shops and individuals want an integrated CMS that has an admin interface AND serves the content while handling content versioning, storage, and publication. If a site grew, then it might be worth revisiting which components should be separated.
A Node CMS is not market-ready. Try to deploy Node on any cheap shared hoster - it either won't work, have a huge cold start because of Plesk, or not be offered at all. Something like Ghost is impossible to be installed on a shared hoster. Then why should I use an inferior technology to build a site when I can use PHP that runs on any shit server, at good performance?
Eh, if you actually look at what Premium is, it's just some premium plugins that they have developed.
> Grav Premium is an exclusive collection of plugins and themes the Grav team has built to enhance your site by providing additional functionality beyond the scope of Grav itself.
Premium plugins include Cloudflare integration, Algolia search, a premium theme.... etc
What is a flat-file CMS? What are CMSs that aren't flat-file?
How many CMSs are there now? How come people are still making more? Why isn't this a boring, fairly stable commodity category the way web servers or something are?
To show they (or their new tech stack) can, to avoid licensing issues, or to have a system tied to their needs.
> Why isn't this a boring, fairly stable commodity category the way web servers or something are?
For what it's worth, it is... the market is uttery dominated by Wordpress (~43% of all websites, and 63% of all websites using a known CMS), followed by "WYSIWYG builder systems" (Shopify, Wix, Squarespace), Joomla and Drupal. The "large enterprise" market seems to be firmly in the hands of Adobe AEM which is an utter PITA.
Development of static or near-static websites is just a sector of the software engineering economy that's humongous in size/volume, so it's often bewildering if you're a software engineer in any other space to see just how much activity there is in that space, despite being relatively trivial.
CMSes cover wildly different needs and editors want all kinds of weird things in their articles. And they still need full control of the publishing. This leads to lots of work for us. And I dont even work on cms activity. I also think its weird that this is not more consolidated. One observation: dynamic langauges tend to be more succesful here, possibly because it is faster to make simple plugin systems and simpler to make one-off articles.
