Links incorrect in feed

[brabster]

Hi there,

I have an RSS feed on my blog here: https://tempered.works/feed_rss_created.xml

The links in the most recent post for images and other internal content are wrong - appears to be literally what's in the markdown, not the rendered version

src="./assets/hero.webp"></p><p>When I wrote about <a href="../2024-03-23-irresponsible-expertise-install-python-package/index.md">dangerous advice

Image should be: https://tempered.works/2024-03-31-exploring-setup-py/assets/hero.webp
Link should be: https://tempered.works/posts/2024/03/23/irresponsible-expertise---python-packages/

I think there's a couple of folks raised similar issues with cover images before, but I'm also seeing the issue on other internal links.

Repo https://github.com/brabster/tw-site-mkdocs

Initially raised with mkdocs-material and suggested I raise here

[jgraber]

The problem is still around in version 1.16.0. Is there any chance to get this problem fixed?

[brabster]

The solution I have is hacky - I take the HTML produced by mkdocs-material and find-replace the broken elements. I can un

I can 💯 understand why @Guts doesn't want to merge it, but I don't think there is a good solution today and not easy to fix that. I'll explain.

My understanding of the situation today is:

• mkdocs uses Python-Markdown
• mkdocs takes a set of markdown files, applies (potentially a lot of) configuration and executes Python-Markdown
• Python-Markdown takes in all of that and produces HTML
• There is no intermediate representation where the information from the config has been applied - it just emits HTML

For example, the final URLs of the various types of relative links in the original markdown can only be seen in the HTML output - which is why I find-replace that.

I can only see one neater solutions: update Python-Markdown to introduce a well-defined intermediate representation. The RSS plugin can then obtain that instead of the HTML, and process it before turning executing the last step to emit HTML. That wouldn't be quick if it's an option at all.

I'm not sure if there are any other options.

[Guts]

Thanks @brabster for carry on maintaining your fork handling this issue in your way. For now, I'm not convinced by the solution and I don't want to introduce something like this in the plugin's codebase since it should be handled upstream IMHO, i.e. Mkdocs or Python Markdown, maybe with a custom preprocessor or something.

On my side, I'm still focused on:

• improving the RSS plugin code base: modularity, customization to fit heterogeneous needs/setups and... performance which still suffers for now
• integrating with Material framework: Social Cards and now blog plugin