This article explains a quick fix to FrontMatter fields in a solution not getting populated when using BlazorStatic. I ran into it after repeatedly exporting all of my stuff from my legacy WordPress site to my in-the-works BlazorStatic site.
StaticBlazor is a game-changer for developers who want the power of Blazor combined with the simplicity of static site generation. However, like all powerful tools, it comes with a learning curve. In this post, we’ll walk through an issue where FrontMatter fields weren’t populating in my BlazorStatic site, and – more importantly – how to fix it.
Background
(Let me do some hyping up first!)
Looking to create a fast, efficient, and hassle-free website with StaticBlazor but stuck on uncooperative FrontMatter fields? You’re not alone!
Say goodbye to WordPress headaches and YAML-induced rage, and let’s get your StaticBlazor project back on track. Keep reading for a quick fix!
Static site generators have always been a favorite of developers who value speed, simplicity, and control. Enter StaticBlazor – bringing the magic of static sites to the Blazor framework, which itself has revolutionized the way we create web applications. Instead of wrangling JavaScript, developers can use C#, producing highly interactive and reliable sites.
StaticBlazor takes this a step further by enabling static site generation with Blazor.
If this sounds familiar, it’s because I’ve explored similar terrain on koskila.net before. From bemoaning WordPress (honestly, who thought we needed so many plugins just to make a CMS usable?) to singing praises for Blazor’s approach to clean, efficient development, StaticBlazor is a natural progression.
But, as always, every shiny tool has its quirks – and this one hits you where it hurts: in the metadata, where your FrontMatter fields mysteriously refuse to populate.
Problem
Okay, so – you start off with high hopes, setting up your BlazorStatic website.
You meticulously add FrontMatter fields to give your blog posts structure, ensuring they include a title, description, and tags. You hit F5, eager to see your beautifully organized posts. But surprise – only some of those FrontMatter fields show up. Instead, you get blank spaces (or default values) where your metadata should be.
Below is a sample of one such post – extracted from my actual legacy website.
---
title: "2019 - Year Review (200th post on this blog!)"
published_date: "2019-12-31T21:00:00.000+02:00"
status: "publish"
isFeatured: false
categories:
- "blog-posts"
- "rants"
author: "koskila"
tags:
- "newyearsresolution"
- "yearreview"
coverImage: "CIRAstock-102-4000px.jpg"
--And my FrontMatter.cs (the file containing the class to which these FrontMatter fields are deserialized to):
namespace koskilanet.web
{
public class KoskilanetFrontMatter : IFrontMatter
{
public string Title { get; set; } = "Empty title";
public string Lead { get; set; } = "";
public DateTime Published_Date { get; set; }
public List<Author> Authors { get; set; } = [];
public List<string> Tags { get; set; } = [];
public string Status { get; set; } = "draft";
public bool IsDraft
{
get { return String.Equals(Status, "draft", StringComparison.OrdinalIgnoreCase); }
}
public bool IsFeatured { get; set; }
public List<string> Categories { get; set; } = [];
}… cue frustration!
Time to recheck everything, hoping it’s a typo. I scrutinized my YAML (because clearly YAML needs to make “human-readable” a running joke) until all I could see was different kinds of whitespace. I lowercased everything. I changed the fields in FrontMatter to definitely, 100%, always for sure match the casing. I told, asked, begged and finally ordered Copilot to fix it.
And yet – the issue persists. And the weirdest thing is that this used to work. It honestly might’ve broken after moving my dev workflow to macos, which is when I also switched over from my beloved Visual Studio to JetBrains Rider.
What gives?
Reason
The root of this problem lies in how StaticBlazor processes FrontMatter fields during build time. It’s expects certain format and certain naming convention – and apparently, not necessarily that the name actually matches!
Namely, there is this configuration line in the BlazorStatic library:
Based on quick testing, this means that those FrontMatter fields that had underscores would not be properly deserialized.
That makes sense. That’s how BlazorStatic is configured. But I could swear it worked before! And I don’t want to change the property names – I want them to match.
So… What do?
Solution
Luckily, this isn’t one of those problems that require hours of digging through obscure GitHub issues. Fixing it is relatively straightforward and only requires a few adjustments.
Here’s how you can get your FrontMatter fields populating like clockwork:
1. Open your FrontMatter class file
Mine is, boringly, called FrontMatter.cs. It’s in my web project, where I reference the StaticBlazor project as a dependency.
2. Add a dependency
Next we’ll do something interesting – but before, we’ll need to add this dependency:
using YamlDotNet.Serialization;
3. Configure the deserialization to ignore naming conventions and respoect the actual property name
Now we’ll want to make sure that BlazorStatic is grabbing the values from YAML properly and deserializing them to right properties in FrontMatter.
For me, this looks somewhat like this:
[YamlMember(ApplyNamingConventions = false)]
public DateTime Published_Date { get; set; }With these steps, we’ll have our FrontMatter fields populating properly before you can say “Untangling Weird FrontMatter Issues Still Beats Trying To Cope With WordPress 24/7”.
Sometimes, a little debugging is a small price to pay for a sleek, static solution.
References
- Official Blazor documentation: https://docs.microsoft.com/en-us/aspnet/core/blazor/
- StaticBlazor GitHub repository: https://github.com/StaticBlazor/StaticBlazor
To me the bottom line about static site generators is this: Debugging is annoying, but when it works – it’s so worth it!
Overall, adopting StaticBlazor has been a significant step in my project to finally get rid of WordPress… For good 😁
Anyway – until next time (something breaks)!
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
