Fontmatter caching

Let’s start with a big hug: Great platform. I’ve been looking for a flat cms over the last weeks and this one tops everything I’ve seen. I’ve pushed hard, starting right away with some specialized features and there’s one big concern: I’ve seen that a lot of templates use the fontmatter as a “secondary” content store, mostly for structured data like portfolios, etc. Great, that’s what I thought in the beginning, but when your run down the road coding a bit you detect that there’s something wrong with that: Fontmatter (the header part of a page) has a different cache behavior. It’s easy to see: You have to alter a frontmatter setting once the event “onPageContentRaw” triggers (after markdown processing) and within the same procedure you alter the content part. On reload you will see that you lose your fontmatter modifications while the content modifications are maintained in cache: Short story: a page needs four sections: fontmatter (header), storematters, summary and content!

A side note: obviously I could store the changes back to disk but this would imply losing simplicity: the modifications include code that is a lot harder to understand and I’d like to maintain things editable for end-users.

Frontmatter is not really intended as a runtime content store, hence the fact its cached separately and before content. However, there is a way to store page-specific meta data via $page->addContentMeta($key, $value); and short codes plugin makes use of this:

Thanks @rhukster for your reply. I’ve solved this but I will have a look into the shortcode plugin to see if there’s a better way.