Differences to Grav

The CMS Questions
25

So I finished my project with Grav.

All in all it’s a pretty good tool. The admin plugin is limited now, so Kirby’s admin would be an easier sell to clients I think. The static content, page metadata (fields), traversing and routing capabilities are good (though a bit under-documented). The modular pages (non-routable pages which are generally used as sections of a parent page) are a nice feature — the actual feature is that each “module” can have its own template (I think the same thing would be doable in Kirby with a plugin, by the way).

My main issue was the documentation, which made the learning curve not so bad, but still slow… lots of trial and error, and difficulties to find the right information (when it was even there).

Compared to Kirby, Grav might also feel a bit over-engineered (when you tout “we use Symfony components!” as a selling point, that’s kind of expected ^^), and the focus on distributing themes and plugins adds one layer of complexity (which Kirby basically skips). In Grav a lot of config can end up in your page’s metadata, because that metadata will then be used by themes and plugins; in Kirby you would do more things in your templates and/or controllers, not relying on third-party “themes” that you can switch in-and-out (ala WordPress/Drupal/etc.).

A few things I liked:

  • The built-in image processing and caching is nice.
  • I did like working with Twig templates (but I’m used to Twig, Django/Jinja, etc.).
  • Page collections with built-in filtering on dates + the pagination plugin. Not perfect but really helpful to have easy pagination support almost out of the box.
  • The admin plugin views for editing the main config files. I thought this was awful at first, but you can create a user which has not access to those files, and it turns out the web view is a nice way to discover settings that you can use to tweak or optimize your project. Live documentation. :slight_smile:

Some things I have more mixed feelings about:

  • When you want to do something not self-evident, you have first to check if there is built-in support or a plugin for that, then try to use the right YAML settings in your global config or in your page’s “header” (“fields” in Kirby parlance), stumble through documentation that is often limited or too complex. If that doesn’t work, maybe try to do it in your Twig templates, using the page object and collections and some underdocumented methods. And if you’re stuck after that, can you just write some PHP? Well, after finishing the project I discovered that the Grav way to do that is to write a plugin. While in Kirby you can use PHP in your template (not recommended for logic but if you want something quick and dirty, you can do it), in a controller or in a plugin, in Grav apparently you have to write a plugin which must be a verbose PHP class (very much like Symfony stuff). The main plugin tutorial from the docs actually describes what I would call a controller, so that’s not very intuitive for me.

  • The documentation for Grav is rich but it can be hard to find what you want. Since Grav is young, a few details are outdated. It lacks a proper reference (especially for things like traversing content and filtering, I had to look at the PHPDoc-generated docs, aka not really docs; when you have to read the comments of class methods, you’re not in friendly doc territory anymore). I also find the regular doc a bit hard to use (long pages without table of contents or sub-headings showing up in the search).

  • The user community seems to have less programmer types, judging by the average questions in the forum. A bit more like your usual open-source CMS, WordPress etc. It’s great that it helps more people build websites, but that means forum answers can have a lot of noise when you’re looking for solid technical answers. On the flip side, the developers of Grav seem to be really reactive in the issue trackers, and often answer questions in the forum.

  • Customizing the form views for the admin plugin was alright, I managed to do what I wanted mostly, but the YAML conventions used for that were very verbose and had so much nesting… it was hard to get started.

  • There’s a built-in asset pipeline, which I didn’t use because I didn’t need it but if you use plugins that output CSS or JS code to work you will need to use it. It seems well done and useful, but asset pipelines can be a mixed blessing (losing some control over what you output, introducing a bit of complexity…).

4 Likes