YAML front matter support

Hey folks,

Really like the simplicity of WriteFreely and am thinking of migrating my long-neglected personal blog to it. Being able to boost and interact with posts on the fediverse might be just what I need to encourage me to write more. There are a few features I’d like to see, though:

  • Importing content more easily. I know RSS/feed imports were recently discussed, but I have piles of posts written for Hugo, and not all of them fit within a single feed page.
  • Enclosures for podcasts. It’s fine if WriteFreely itself doesn’t do media storage, but I’d like to link to an Ogg or video hosted somewhere else and have it automatically included as an enclosure.
  • Meta descriptions. I promote posts in places that display these prominently. AFAICT these can’t be added manually to posts right now.

Has thought been given to supporting these features with YAML front matter, as commonly found in static site generators? I’m thinking maybe build out some sort of standard schema, and optionally (de)serialize that into YAML front matter at the top of the editor? This would help in a few ways:

  • I could probably paste Hugo Markdown posts directly into the editor, and have their metadata populated automatically. If I want to backdate a post without editing the date later, for example, I don’t see how I can do that currently.
  • The schema and supported features could be iterated separately from the interface. There might be some way of making enclosure additions nicer–drag-and-drop a URL into the editor and be prompted to include it as an enclosure for instance–but for now just being able to do that via YAML would be a win.

I’m not particularly wedded to YAML; I’m only suggesting it because it’s what many other generators use. Thoughts? I might be willing to take a crack at implementing this if it’s a desired feature, though I don’t know Go terribly well ATM. Might be a good project to learn. :slight_smile:

2 Likes

That’s what I just thought of! This will greatly facilitate migration! If we also add links of image from the external map bed in the MD file, then the migration of the blog will be very easy!

I currently have hundreds of posts that need to be migrated from other blog platform to WriteFreely, but the thing that bothersme the most is that WriteFreely doesn’t support YAML. I believe that write.as or writeFreely will attract more people from other blog platforms if this feature is supported.

By the way, will WriteFreely support direct reading of MD files in the future? In that case, migration achieves maximum convenience.

Hey @nolan, while this doesn’t quite address your feature requests, I recently wrote a Hugo-to-WriteFreely importer (and migrated my own old, long-neglected Hugo blog with it). Maybe it can serve as a jumping off point for you?

2 Likes

Sounds great! Looking forward to it!

I really like the idea of supporting YAML front matter as a way to set metadata in our text-based web editor. It’s a format that’s fairly well-known among static site generator users, would be pretty straightforward to implement, and fits well with our text-based ethos.

I can imagine the simplest implementation would merely parse this front matter (FM) on the client side (if it’s there) and send it to the API correctly upon publishing. This wouldn’t require any backend changes, and would make adding FM completely optional – which I think is crucial, from a product / UX perspective.

The only real issue I see coming from this would be when editing a post. Users publishing FM might expect to see FM when they’re later editing their posts. But if we’re not distinguishing which posts were published with FM, we’d have no way to know whether to include it at the top of the post or not. We could either live with this, or create a new WriteFreely editor option that always shows FM at the top of the post. In this case, when editing a post, we’d merely parse out the metadata and construct fresh FM at the top.

To your other feature requests:

I’d echo @angelo and say the Hugo importer should work great for this. But otherwise, more import options are at the top of our priority list, after the manual migration projects we’re currently working on.

I think we can definitely address this in the near future. We’ll continue the discussion on your other thread.

I can definitely understand needing a bit more control over this. Would you mind starting a new topic for this feature in particular in the #feedback:feature-requests category, so others can vote on it, too? I’m very open to adding support for this.