-
Notifications
You must be signed in to change notification settings - Fork 321
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
Use realfavicongenerator API to build high-res PNG favicons #883
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great and much simpler than I had anticipated! I have given you a bunch of comments to help make the code more robust (these are tips I've learned through getting them all wrong myself!)
I'm also wondering if it would be better to pull this out into a separate build_favicons()
that the user would need to call explicitly? Otherwise we're potentially hitting this API every time we build the site. (We could store the favicons in pkgdown/favicons
maybe?)
I think we should use a shared key that I register, providing an option for users to override if they want to provide their own. |
@hadley, thank you for your comments. I addressed some of them and I will probably have a look at the rest tomorrow. I did the last changes in numerous small commits to make it easier to review. But once everything is ready to go, I can rebase & squash and force push.
Yeah, I forgot, I was thinking we could maybe add a check at the beginning of this function or in |
Do we want a better default favicon while we're at this? Currently it's a (lo-res) blank black hex. |
@Bisaloo I think it would be better to be explicit about it and force the user to call a function. (Also you don't need to squash on your end, as I can squash when merging) @jayhesselberth I think we can ditch the default favicon now that we no longer need magick. |
So I just tested and this works perfectly for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, should definitely prefer svg logos now. I think it's fine to include that here since it should be a fairly small change.
I'd suggest that you also run the function on pkgdown itself and check in the results. |
The API also creates a bunch of files that we don't use ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should include them to the template too.
We probably also need to make the template only include them if the favicons are actually present
I'm not sure how to do that 😕 |
In that case, let me do a final review of this work, and then I can merge it. Then I can figure out how to let the template know. |
Are you happy for me to merge this now? |
Yeah, I just tested locally one last time and everything seems to work fine so I guess it's good to go. |
Awesome, thank you so much for all your hard work on this! |
Thank you for all your comments! And don't forget to register your API key 😉 |
I signed up yesterday, but still haven't received the email 😢 |
due to r-lib/pkgdown#883. This reverts commit 62a051a.
fix #845, fix #869
This is still WIP but I'm putting it here if you want to have a first look and tell me if I'm going in the wrong direction. I still need to:
svg
build_favicon()
Among others, I would like you to review:
pkgdown
users, hardcoded in the code? Asking users to register one themselves would introduce more complexity.