-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GF font retrieve win (#7085) #7117
Conversation
Note that there's no necessity in upstreaming this to Insiders – I'll handle that immediately once we merge this PR. |
LGTM 👍 However, I see the comment isn't formatted to make every line as long as possible to the 80 character limit, Martin could see an issue with that 👀 EDIT: Also I noticed this throughout the whole codebase, but I personally think that context managers should be as short and "focused" as possible. So only the |
A new small issue for this PR #7118 as it's related to fonts |
@kamilkrzyskow ha, you know me quite well now. Sorry, if I'm pedantic, just trying to keep everything as tidy as possible 😅 Regarding #7118 – can we solve this here as well, or should we create a new PR? I'm quite sure this is already solved in Insiders, but I'm not 100% sure. |
That should be #7118 fixed as well. See if you like the solution. It should deal with (a) no font option (b) font: false (c) font option but no text font configured as well as (d) a font configuration with a text font configured. |
Thanks, @alexvoss. It's actually a regression of 9.5.19, where I tried to make the social plugin work with other themes, see 6a761ed. The new tags plugin should not suffer from these problems. Could you please check if the social plugin still works with the |
The new code changes LGTM, also should work with the base theme as well. The changes in 6a761ed (which weren't documented with any comments btw ;^]) target the usage of direct indexing with
and the config file for the base theme doesn't: https://github.com/mkdocs/mkdocs/blob/master/mkdocs/themes/mkdocs/mkdocs_theme.yml There are some other cases in the codebase where direct indexing is used instead of the mkdocs-material/src/plugins/social/plugin.py Lines 134 to 137 in ff49d74
but are protected by a if name in theme conditional, therefore the compatibility with other themes / custom user configurations is upheld.
This line in the Blog plugin (Insiders too) should also be fixed for interoperability with the base mkdocs theme, as instead of
|
@kamilkrzyskow You got me! 🫣 You're of course right. The code base of the tags and social plugin will be entirely replaced when the next funding goal is hit, which might explain my (subconscious?) sloppiness. And yes, the For this reason, I'd say we rather bandaid those plugins, as the new implementations are much cleaner and shouldn't suffer from the same problems. IMHO, we should concentrate our efforts on those implementations. If bugs arise, we'll of course fix them in the community edition as well, but rewriting them is not economical.
Yes, I agree, but that is an entirely different pit to fall in. Material's i18n implementation predates the one in MkDocs, and at some point, we should switch it, but that's something that is absolutely not a priority right now. When you specify |
I've adapted the fix to the social plugin in Insiders (which already works for third party themes) in I've realized too late, that I already committed that to |
Was wondering whether to do that but I decided that extracting a few variables could sit in the
Am building our own documentation using Insiders and all seems well font-wise. Also tested the reproduction for #7118. Am getting warnings from the RSS plugin, though. It seems to be looking for social cards images that do not exist as they are based on where the .md file is, not the eventual path to the blog post. Is this a known issue? |
Thanks for testing, I guess we're ready to merge then. I guess it's a matter of taste what belongs where, but I think I saw @kamilkrzyskow note at some point that it's a best practice that contexts are kept as short as possible, but I might also be mistaken. The RSS plugin warning should be upstreamed. |
In general, definitely. Might be good to make it muscle memory to do so as well. I still need to develop that.
I added a reproduction to the issue Guts/mkdocs-rss-plugin#257 While at it I also stumbled across a difference in what the blog plugin expects a date to be and how the date-in-page-meta feature is documented for the RSS plugin but Guts has already committed changes that may sort this out with the next release, so I stopped short of writing it up as an issue. |
@alexvoss Thanks! I don't think the mentioned upstream issue talks about the same error, it's a different error not related to Material for MkDocs but to all themes. More specifically:
|
@squidfunk that is not the one I ran into today and is something that should have been fixed a while ago. Are you running an up-to-date version of the RSS plugin? I found I was an on a really old one and was still getting this warning today, so I updated and this one is gone. Edit: the version in our The RSS issue I was talking about is the "Remote image could not been reached" one. |
Of course not 🫣 Just upgraded the plugin and now I see the remote image errors:
Downgrading again 😅 |
We should currently not bump it. The version range we support is |
Changed the way that font information is extracted once downloaded from GF. This avoids creating a temporary file and so resolves the issue with
NamedTemporaryFile
on Windows (#7085)Tested this with our own documentation on Windows and MacOS.