Whenever possible, hardcode your page headers on grav

The preferred Grav behavior is usually not you want. Here is a case involving grav's page.date.

By Ace Z. Alba

Published on May 9, 2023, 3:36 pm

Category: grav

Tag: debugging

This is a weird behavior I found when debugging Grav themes. The preferred Grav behavior is usually not you want. For example, Grav wants you to manually type in your metadata values. However, you'd want your metadata to be generated automatically. Luckily there are enough tools in Twig for you to generate your SEO from within your theme.

However, there is another mess that can make your Grav debugging a pain.

When the date metadata is not defined, Grav uses the modified_date attribute of your markdown file. This is good and all for an initial setup. However, if you chose to settle with this default behavior, theme changes can screw over the look of your page content. if the date is not hardcoded, editing and updating page files from the CPanel file manager or debugging the page headers can mess with your page collection views. If the theme is also not designed properly, the date displayed will also be updated, and it would be difficult for you to figure out the original date of the file right away.

So to handle any messes caused by the date logic, take note of the following:

  1. Hard code your date header in your content.
  2. Check the sorting logic of your page loop. You'd want a sort setting that uses hard-coded data, such as publish_date.
  3. If you can, read your theme files to check if the theme has a preferred way of handling page.date, content.items, and any date-dependent logic for that matter.

As of writing, Canvas resolves this by preferring a hard coded publish_date for display over page.date. I do plan to improve this logic later.