Support defining a mapping between author identifier and the author in the feed

[stefansli]

The RSS standard specifies the author should be [email protected] (John Doe). In the documents I'd like to use a username, for example the github username, as author. Would it be possible to implement a mapping between usernames and RSS authors? I'm thinking aboud a new config setting and a yaml file that maps the authors to RSS Name + Email definitions. Alternatively one could implement rss_author and rss_authors metadata.

Background information: I'm using the mkdocs-material theme with the blog plugin. The blog plugin can also render pages for authors. With the current setup, specifying a RSS conform author, the URL to the authors page looks quite ugly (containing %40 for the @ and several spaces).

Do you thinkt that's a good idea? Then I'd start with an implememtation and open a pull request.

[Guts]

Hi @stefansli

Sorry for the delay, I work on this side-project from time to time, mainly when I have free time to develop, review, get paid for or have a particular need.

Well, I'm actively working on a better integration with the blog plugin from @squidfunk Material framework for Mkdocs. My goal is to retrieve the author's name from the .authors.yml file when it comes to the RSS plugin to deal with a Material Blog post. For that, I wanted first to improve the integration logic. You can have a look to the linked PRs if you want to review the recent work. I'll release a 1.17 version soon to make it testable in real conditions.

I know it does not fully cover your needs, especially the full RSS compliance (author = "Firstname NAME [email protected]") as already spotted in other issues, but I think it's a good first step. I'm not willing to add another config file specific to this plugin alongside the others. With the 1.17, to include authors emails, you'll be able to extend the .authors.yml with relevant mail addresses (see fresh documentation).

The other way, more aligned with the general plugin purpose, would be to use the git log (#37) which comes generally with both names and emails. But it's a bit more tricky since we would have to manage the "match" between authors names and git log and maybe uselss since we should rely on plugins which already do this kind of jobs.

[Guts]

@stefansli mentioned integrations are packaged with the 1.17: https://github.com/Guts/mkdocs-rss-plugin/releases/tag/1.17.0. I let you try and give your feedback here.

[stefansli]

Hi @Guts, I'll try to test as soon as possible and will give feedback. Hopefully this is before the end of the week.

[Guts]

Hello @stefansli,

No hurries, as you may have noticed I'm not really in a rush on this project ;).
Thanks for your time for reporting and testing, it's really cool.

[stefansli]

Hi @Guts, I just tried this and I general it's working. However the author is generated as John Doe ([email protected]) instead of [email protected] (John Doe). Without specifying an email address in .authors.yml, the author is generated as John Doe (the name from the authors file). In the past the key was used instead of the name attribute. For me this is not an issue. I just wanted to let you know in case you value backwards compatibility highly.

[Guts]

Thanks @stefansli for following up.

However the author is generated as John Doe ([email protected]) instead of [email protected] (John Doe).

Sure, I was a bit confused with different format. Fixed in 1.17.1.

Without specifying an email address in .authors.yml, the author is generated as John Doe (the name from the authors file). In the past the key was used instead of the name attribute. For me this is not an issue. I just wanted to let you know in case you value backwards compatibility highly.

When you say in the past, you mean recently? if so, I can consider adding a backward compatibility but since it's not a big deal to update Material for Mkdocs, especially for the last year (mainly bug fixes and enhancements, no breaking changes), I think it's not necessary.

If you are happy with the latest version, feel free to close here :).