Conversation
|
@benjaminparry This might solve the issue you’ve got with wanting to post articles to 2 different locations on your website. @gerwitz You had previously asked about having more ways to organise posts; would this help? |
|
Indeed, this is perfect for my case |
|
@gerwitz Out of interest, how would you use this feature (do you use 11ty)? Is it a problem that a default channel is always set if no channels are provided? |
|
Well that escalated quickly! I’ll find some time to catch up this week. Thanks Paul! |
|
Sorry, very slow getting this into a release, but Beta 20 has shipped, so channels can be configured and used as described above. |
Sorry I never answered that … the original project that triggered this discussion for me is long done. But I now intend to use it for posting to my logs as well as more traditional notes. I also will use it for categories of longer posts, letting micropub categories map to tags. |
Adds support for the channels extension in Micropub requests. Fixes #773.
This can be used to dictate where a post gets published within a publication, and potentially allows for posts of the same type to be published to different locations.
Adds:
publication.channelsconfiguration option/micropub?q=configincludes achannelsproperty with configured channels/micropub?q=channelreturns configured channelsIf channels are configured:
publication.channelsmp-channelvalue, it gets saved toproperties.channelmp-channel, the default channel UID is usedmp-channelthat don’t exist inpublication.channels, they’ll get ignored. If no values match, the default channel UID is used{channel}token is available to use in paths; if multiple channels are assigned to a post, these will get separated using the slug separator characterExample
In publication config:
Published to
/en/2024/11/channels:Published to
/de/2024/11/kanale:How should this value be used by presets?
Right now, if a publication has channels configured, the default (or chosen) channel(s) will get saved to
properties.channel, so for example a post might look like this:I think channels are analogous to Eleventy collections, so potentially for that preset, the
channelproperty should be used fortags? But you might want to useproperties.categoryfor thetagsfield instead. Not sure what is the right approach, but can figure that out in a separate PR.Might this value have equivalent representations in other platforms, too?
Should a default channel be enforced?
Right now, a default channel is enforced. That means, while you might only want to use the channel property for the output path, the
channelproperty would still get added to frontmatter properties as well. Maybe that’s fine (though this’d make be twinge…)