Supporting `mp-slug`, `summary`, and `type` on the Micropub endpoint?

[BWLNG]

I have a few questions about support for additional parts of the Micropub spec while I’m working on converting a site to Micro.blog

Setting summary

The summary field, which is part of the Micropub spec, would be useful so long posts in the main timeline can show a brief overview instead of the full article (while still having precise control over the content of the summary instead of relying on Hugo’s autogenerated summary). As far as I can tell, it’s ignored. Is it possible to add a summary/excerpt content with any Micro.blog API or plans to support including a summary param on the Micropub endpoint?

Setting the post type

q=config on Micro.blog’s Micropub endpoint says it includes support for post types including note, article, and photo, but it doesn’t seem to include a type other than post as a param available to templates, which makes it difficult to query by type for theming/filtering. With Indiekit, for example, a type param can be set. It seems other folks have used mp-type. Is there a way to set the type through the Micropub endpoint?

It would be nice if there were a way to explicitly set the type when creating a post and have Micro.blog use the algorithm for Post Type Discovery and include the inferred type in posts params when the type isn’t explicity set.

mp-slug

Not a part of the spec, but a common extension many Micropub servers support (e.g. Indiekit, the Micropub plugin for WordPress, etc).

Micro.blog does not support this as far as I can tell and it would be helpful when migrating posts, but also nice to have more control over the URL that is displayed.

Custom fields

Barring support for these specific fields, other Micropub servers seem to save any extra params as properties of the item being created. So passing, e.g. type=article would make that available at .Params.type w/o Micro.blog having to have specific support for that param (not sure that’s best approach, but it’s an idea )

Appreciate any insight/feedback/help the community has

[jsonbecker]

Micro.blog right now is pretty fixed on “post” as the only type and not taking advantage of Hugo having content types. There’s been some discussion about allowing different content types, but what I’ve seen so far from Manton is the idea that it would still be an enumerated list maintained by Micro.blog versus custom post types. The main advantage of post types is what you said-- having different templates directed to that type for rendering. Most of us who have an interest in that have just overloaded the categories/taxonomies as a mechanism for the same. It definitely makes for less clean templates, but it is functional.

Summary, slugs, and custom fields are less about Micropub spec-- they’re primarily about custom front matter. Right now, Manton discards a lot of supported/potentially supported Hugo front matter. That’s also been discussed before-- I think there’s been a small crack opening to potentially allowing for that. IMO, step one would be to support the built in, non-custom fields in Hugo front matter not currently supported by Micro.blog. Summary and slugs are two core ones. See here.

Of this list, I think the following should be supported, even if they’re not exposed in the Micro.blog interface at first:

• aliases (for redirects)
• date
• description
• expiryDate (ephemeral posts)
• layout (an easier way potentially than types to point to a different template without having to change Micro.blog’s directory structure model of everything being a post)
• series (connect posts together)
• summary

I think if these were used first, then exposed optionally via the web or could be set by folks using the API, that would be a big step up.

From there, I think there’s an open question if custom front matter properties or some of the other properties are worth using. I excluded some such as image, video, and audio that MB already populates in some ways or gates partially as pro features as I believe the platform already supports those “intelligently”. Similarly, draft and publish date may not be how Micro.blog supports scheduling/drafts, but there’s already a system in place for that.

[BWLNG]

@jsonbecker

There’s been some discussion about allowing different content types, but what I’ve seen so far from Manton is the idea that it would still be an enumerated list maintained by Micro.blog versus custom post types.

For my use case, the built in types would be fine, I’d like a way to set or expose that in the frontmatter/params. This is the full response from q=config with the types I’d like to see in .Params

{
    …
    "post-types": [
        {
            "type": "article",
            "name": "Article"
        },
        {
            "type": "note",
            "name": "Note"
        },
        {
            "type": "photo",
            "name": "Photo"
        },
        {
            "type": "video",
            "name": "Video"
        },
        {
            "type": "audio",
            "name": "Audio"
        },
        {
            "type": "bookmark",
            "name": "Bookmark"
        },
        {
            "type": "checkin",
            "name": "Checkin"
        },
        {
            "type": "event",
            "name": "Event"
        },
        {
            "type": "rsvp",
            "name": "Reply with RSVP"
        },
        {
            "type": "reply",
            "name": "Reply"
        },
        {
            "type": "repost",
            "name": "Repost"
        },
        {
            "type": "like",
            "name": "Like"
        }
    ]
    …
}

@jsonbecker

Summary, slugs, and custom fields are less about Micropub spec-- they’re primarily about custom front matter.

Without exposing them in the Micro.blog interface, I think the Micropub spec and what’s included in front matter/.Params go hand in hand. Since the Micropub spec includes summary as a property that can be included for h-entry, it would be nice to support via the Micro.blog API.

Where there is overlap between the Micropub spec and Hugo’s front matter variables you linked, it seems like a good place to start (mp-slug/slug, summary, type) so the web/app UIs don’t have to be complicated, but users who choose to can use other apps and the Micropub endpoint to leverage them.

[jsonbecker]

@BWLNG

Where there is overlap between the Micropub spec and Hugo’s front matter variables you linked, it seems like a good place to start (mp-slug/slug, summary, type) so the web/app UIs don’t have to be complicated, but users who choose to can use other apps and the Micropub endpoint to leverage them.

To be clear, the reason to start with Hugo frontmatter is because regardless of whatever the API spec is, Hugo is what has to process the data. Micro.blog as a blogging system has to first expose and work with those things before exposing them in the API is meaningful.

I think you’re building backwards— the API interface accepting a parameter is not useful if the underlying application underneath can’t do anything with it. So what I’m really saying is some of the features you want from the API are not yet supported by Micro.blog the product. Step one is get the product supporting things like custom summaries, which is “fairly easy” from the outside because Hugo can support it, then setting it via API makes sense.

For example, your “built in types” and support for them doesn’t mean supporting an API parameter— it means Micro.blog doing something with it. It’s far harder for Micro.blog to allow for post types than it is to allow for that to be set in the API.