WordPress to Grav Lessons

In our last post we were very excited to announce our "grav-ified" website launch. In that post we mentioned some of key takeaways from our deep dive in Grav, but didn't go into the details. Well, that's what we're here to do now. So let's get detailing...

Difficulties / Problems

It's pretty clear from our last post we loved moving out website to Grav. However, now that some time has passed, it's probably a better time to judge everything. And we can still confidently say we're still very happy we moved to Grav. That all being said it's wasn't all super smooth sailing all the way long. There were difficulties and challenges and passing those along is hopefully very helpful to others, probably more so than detailing all the things we loved. So let's start with the challenges before the benefits.

Frontend Forms

First of all I should say if you are doing just a regular frontend form you probably will find them pretty easy to work with and have no issues. However, previously on our website we had our contact form in our main modal nav (so it's loading on every page) as well as the contact page. This caused a whole bunch of headaches. I'm sure there is a way to get around this, particularly if you setup your form to be AJAX powered, but we never solved it. The reason why we did was while working on this issue we actually decided it's probably a better UX to not have the form in the modal nav. Moreover, we decided that we'd rather have the latest blog in modal nav to draw more attention to that key part of our website.

All in all this was a pretty minor thing, it just probably stands out more as we are a longtime Gravity Forms user and using that plugin makes setting up extremely powerful and complex WP forms a breeze. Change is hard sometimes. :)

Spell Checking

This is definitely an important warning for all you bad spellers out there. If using the Grav Admin plugin to write and edit your content, there is no spell checking. Yikes! I guess I am just so used to spell checking automatically occuring in any field I type in I didn't expect this issue. I should have known though when no spelling errors popped up -- maybe I just thought that suddenly my spelling had become perfect! This is an open issue in Grav though, and while not easily solved, at least it's something that is known and folks are talking about it.

No Logged Out Warning on Save

Just a small beef here, but for those who use the Grav Admin plugin and tend to leave the page they are editing open as a tab their your browser, there are no warnings that you have been logged out (for security reasons, which is a good thing). And yes you can definitely change the timeout period to something much longer if you want. Anyway, if you've timed out and just sit down and start typing then hit "Save", only then will you find you are logged out and nothing is saved. No ideal! But with Grav 2 this should be resolved as the admin is being significantly revamped to be more app like.

Key Things We Found Easier

I could provide a huge list of benefits of Grav, but the Grav website itself already details the key features/benefits. Instead, I just want to call out a few items that we particularly found to be a big upgrade over WordPress.

The most notable change and benefit of Grav (or any flat CMS vs a databse powered CMS) is being able to have version control over your entire install. As someone a bit obsessive over never losing any of my work, this comes as a great relief. Sure there are some folks trying to provide git ability for your WP database but that not easy to do and is fraught with challenges. With Grav however, putting your entire project into a git repository is as easy as git can be.

Another thing we loved was the Grav documentation. It is simply fantastic, definitely some of the best I've ever come across in the past decade. The Grav team should be commended many times over for the job they've done on this. It certainly makes it very easy to get into Grav and not get stuck very often. It's also handy because Grav of course does not have a massive community (yet) around it, so there are far fewer answers to questions you may have as you go along. But what we found is that quite often the answers you are looking for are actually right there in the Grav docs.

Lastly, the admin custom fields setup is awesome -- and a major improvement over how they are handled in WordPress. We loved how powerful and flexible they are while still maintaining their simplicity. Being able to place your custom fields almost anywhere you wanted is the best part. You can put them below the main "Content" tab editor or in their own tab and so on. This allows you to nicely customise your admin for each individual use case and for each client. A big win for Grav!

The only thing missing from the current custom fields setup is the ability to create flexible content fields (similar to what Advanced Custom Fields for WP has). This would be an amazing enhancement to Grav, particularly in enabling you to give your clients powerful content creation without all overhead and complexity of a full "page builder" style admin.

Code Snippet / Tip

Alright, that was a lot of reading without any code or fun screenshots. So now it's time for your reward for making it this far...

Blog using sub-folders

If you really like to keep things organised and if you have a lot of blog posts, then you probably want your blog posts in folders instead of just one big long list under your blog page. There certainly may be a better way to do this, but hopefully this helps you get started...

First of all, your Blog main page front matter should look something like this, with the key difference from a usual setup being the items line.

---
title: Blog
content:
    items: '@self.descendants'
    filter:
        type: item
    order:
        by: header.date 
        dir: desc
    pagination: true
    limit: 4
---

While the above is change is easy and I believe well documented, the challenges come when you want to do some common blog operations on your posts, like get a recent post or get a random post. That's where I found the documentation didn't give you the details you needed because you now have to make some changes to how you would otherwise do it. The key line again is the items line, and also note the permalink used in there will have to be whatever the permalink is for your blog main page.

Get Recent Posts (.twig)
{% set blog_posts =
  page.collection({
    'items':{
      '@page.descendants': '/blog'
    },
    'filter': {
      'type': 'item'
    },
    'order': {
        'by': 'date',
        'dir': 'desc'
    },
    'limit': 3,
  })
%}

{% for post in blog_posts %}
  <p>{{ post.title }}</p>
  <a href="{{ post.url }}">LINK!</a>"
{% endfor %}
Get Random Posts (.twig)
{% set random_posts =
  page.collection({
    'items':{
      '@page.descendants': '/blog'
    },
    'filter': {
      'type': 'item'
    },
    'order': {
        'by': 'random'
    },
    'limit': 1,
  })
%}

{% for post in random_posts %}
  <p>{{ post.title }}</p>
  <a href="{{ post.url }}">LINK!</a>"
{% endfor %}
© 2019 Creative Logic Tech Solutions.