Grav is a modern open-source flat-file CMS | Hacker News Reader

Grav is a modern open-source flat-file CMS

getgrav.org

135 pointsthunderbong67 comments

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).

Personally think https://getkirby.com is the entry to beat but I guess it’s just because I’m used to it and it works incredibly well for my use case.

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.

The active community for kirby is bigger than grav's as the following shows:

https://devboard.gitsense.com/getkirby/kirby

https://devboard.gitsense.com/getgrav/grav

Historically speaking, grav is more popular as it had over 2000 contributors, compared to kirby which is about 500.

Full Disclosure: This is my tool

It’s two different projects run in two different ways. I don’t think that looking at git is useful or insightful in this case.

It is not just git though. It's looking at no code participation as well.

Yes but the two projects are run differently. Most of discussions around Kirby happen on the official discord server or on the official forum.

So looking at git activity is not really all that useful.

Yes you are right about not having the complete picture, as far as no code activity goes.

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.

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)

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?

Keep in mind that Kirby is also a paid product

Oh? Thx. I missed that.

Another vote for Kirby and I’ve tried them all.

Wait, isn't laravel based on/using a bunch of libraries from symfony? Or did it just use to be that way and it has changed?

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.

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.

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?"

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.

This Statamic blog post has (at least some) insights: https://statamic.com/blog/statamic-at-spiegel-scale-2

> So how does SPIEGEL do it?

> 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.

Is or isn't Asana still mostly powered by Statamic?

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.

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.

Grav is my favorite CMS. It’s a perfect fit for my use cases: side projects that often take unconventional formats.

This is my most out-there example: an ongoing synesthesia art project, running on Grav with Turbolinks: https://testfixture.presteign.com/

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.

Maybe I should start a side project.

[0] https://learn.getgrav.org/17/basics/basic-tutorial

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

Good old PHP —- still making the front page in 2023.

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.

Sorry, nowadays i use json file to store metadata, then query with asql (sql for json), then parse the markdown to browser.

Frameworks need to die, just give the fuck core libraries to work across frameworks, or you get "vendor locked-in" sooner or later.

How does that work for multiple editors that aren’t programmers?

Seriously, to suport collaboration, postgresql is simple solution.

the "get premium" sticky makes this website unusable for me. was curious to see how a flat-file CMS can make a come back.

If only it wasn't built with PHP. We need a batteries included, non-headless, open source CMS for Node.js.

Headless is pointless for the vast majority of use cases, so I don't really understand why Node.js developers keep making them.

It's funny how CMSs follow the same design patterns based on the language. PHP CMSs are generally the same, Node.js CMSs are generally the same.

How about .NET?

Headless cms + static site generator.

All the pros of a tiny, static website and all the pros of a cms system and dynamic content.

Scale to millions of visitors for a couple of dollars.

Because PHP is bad or because you personally don't like PHP?

I think they just want it in Node.

Rewrite it in*

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.

The closest I could get is Sveltekit + Supabase + a custom editor/svelte renderer for my website at https://omarkama.li

I think there’s room for a solution that offers all this in a single package.

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.

In case people were wondering: https://en.wikipedia.org/wiki/Headless_content_management_sy...

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?

Good to know, will likely not forget the name since there's also Grav Labs glass.

Looks more open core than open source, given the massive premium banner.

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

Website is unreadable on mobile.

Works for me

Part of the problem probably is that the site won't completely load. Hug of death maybe.

Finally loaded. Didn't help.

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?

A content management system where the content is stored in flat-files like csv.

You know, like dos-on-dope -

https://github.com/secretGeek/dod

To be fair, this thing is not new at all

Exact link first posted 6 years ago https://news.ycombinator.com/item?id=13743660

> How many CMSs are there now?

Probably too many [1].

> How come people are still making more?

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.

[1] https://en.wikipedia.org/wiki/List_of_content_management_sys...

Whole list you can find: https://whatcms.org/Tech_Reports

Flat file means that there is no database but instead a bunch of text files are used to store data, usually 1 file per entry.

Sometimes these files are being kept in memory by the server to offer very fast read access.

This is used to keep a stack simple and it makes your data easily versionable.

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.

Reply on news.ycombinator.com