webpage-micropub-to-github

webpage-micropub-to-github copied to clipboard

Setting a value for slug in a Micropub client (tested with https://quill.p3k.io and https://micropublish.net), the value gets ignored, and instead a number is assigned, appearing both in a front matter slug property, and in the generated file path.

So, if I set the slug as my-great-slug, and with the following config MICROPUB_FILENAME_STYLE="src/_posts/notes/:year-:month-:day-:slug":

Expected result:

File path: src/_posts/notes/2017-07-15-my-great-slug.md YAML frontmatter property: slug: 'my-great-slug'

Actual result

File path: src/_posts/notes/2017-07-15-74902.md YAML frontmatter property: slug: '74902'

I very much agree, this should be respected

I have tested this and found that if the slug is sent as the parameter slug it works. This should be using the mp-slug parameter instead.

Posting with a duplicate slug results in a 400. It might be nice if it automatically made it unique by appending a number to the end. So the second time a slug foo is posted, it converts to foo-1, then foo-2, etc.

Some such things might be tricky as this endpoint has no data itself about the content of a site but rather relies on GitHub lookups whenever it wants something – so checking data across many files at once can be complex and slow.

That said – I’m confident the slug handling can be improved. I can’t say when though as I have had very little time for open source work outside my day job, especially since last summer. So it depends on whether I find some time during a weekend like I did this last weekend.

22 jan. 2018 kl. 19:11 skrev Keith Grant [email protected]:

Posting with a duplicate slug results in a 400. It might be nice if it automatically made it unique by appending a number to the end. So the second time a slug foo is posted, it converts to foo-1, then foo-2, etc.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.