mkdocs-rss-plugin
mkdocs-rss-plugin copied to clipboard
Material social cards not working with customized social.cards_dir directory
assets/images/social is hardcoded at this line, so if you change the directory where social cards are stored then the cards are not detected and linked to properly:
https://github.com/Guts/mkdocs-rss-plugin/blob/19069bb57c5f0ac944bcbeeac12518e4f4f12b95/mkdocs_rss_plugin/integrations/theme_material_social_plugin.py#L309
For example this configuration would be broken:
plugins:
social:
cards_dir: assets/img/social
It also doesn't seem to be using the computed location correctly when used with the material blog plugin: https://github.com/squidfunk/mkdocs-material/issues/7518
If it helps, here's how mkdocs-material references the cards_dir
Hello @jonaharagon and @perpil,
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.
Which version of the plugin are you using? Because since 1.16, the integration with Material Blog has been improved: https://guts.github.io/mkdocs-rss-plugin/changelog/#1160---2024-10-24
Since you're using the Material theme, please consider using the same report workflow as described in their documentation: https://squidfunk.github.io/mkdocs-material/contributing/reporting-a-bug/
Thanks for the update! Using 1.17, the repro that was attached to https://github.com/squidfunk/mkdocs-material/issues/7518 seems to be working. However, when I try with my mkdocs.yml, it's looking for the social cards in the wrong place still. I'll debug further in the coming week and try and provide a new repro.
Ok, here's a repro. It appears to be that the build directory for social cards isn't correct when use_directory_urls: false
9.5.48+insiders.4.53.14-rss-social-use_directory_urls-false.zip
I was able to make some minor edits to the code to make it work in this scenario, will see if I can make it work for all scenarios.
Thanks @perpil for your attentive tests and following up here, really appreciated. I try to have a look before next year!
Thanks to @kanru this issue has been fixed. Released as part of 1.17.2 version.