Skip to content

Images generated by python library don't appear to be uploaded to CDN #9680

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.

Sign up for GitHub

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

Jump to bottom
Closed
etsauer opened this issue Oct 19, 2022 · 4 comments
Closed

Images generated by python library don't appear to be uploaded to CDN #9680

etsauer opened this issue Oct 19, 2022 · 4 comments
Labels
Needed: more information A reply from issue author is required Support Support question

Comments

@etsauer
Copy link

etsauer commented Oct 19, 2022 •
edited
Loading

Details

We recently switched our site to use the Material theme for Mkdocs, and we've been trying to take advantage of their Social Cards feature. The plugin uses two python libraries, pillow and cairosvg to generate attractive thumbnails for your site that get used in social media posts, chat links, etc.

The library generates PNG files that are expected to be included in the _build/html directory as part of the mkdocs build output, and then uploaded to the CDN along with the rest of our image assets. We added a couple of debug commands to our build via a post_build step, and we can see in the output that the files are indeed being generated in the correct location as expected. However, we have not seen them served as part of the site content yet.

The files we are missing are located at _build/html/assets/images/social

Also of note is that so far we have only tested in PR builds. Not sure if the CDN upload behaves differently in those cases.

Expected Result

When I load any page in my site, there will be some meta tags in the <head> , like so:

<head>
  ...
  <meta property="og:image" content="https://pelorus.readthedocs.io/en/latest/assets/images/social/index.png">
</head>

The url in the content property should resolve to an image.

Actual Result

The meta tag is populated as expected in the above output, but the URL results in a 404 instead of an image loading.
@etsauer etsauer mentioned this issue Oct 19, 2022
Merged
@humitos humitos added the Support Support question label Oct 20, 2022
@stsewd
Copy link
Member

stsewd commented Oct 26, 2022

Hi, I'm able to see the image at https://pelorus--695.org.readthedocs.build/en/695/assets/images/social/index.png.

When I load any page in my site, there will be some meta tags in the , like so:

That link is assuming that your image is already on the latest version of your documentation, but your PR hasn't been merged yet.

@stsewd stsewd added the Needed: more information A reply from issue author is required label Oct 26, 2022
@etsauer
Copy link
Author

etsauer commented Oct 26, 2022 •
edited
Loading

@stsewd oh! i see now that the URLs to those images are statically generating from the site_url that we feed in via mkdocs.yml. I guess I assumed the PR builds would overwrite site_url so that links like this would work in those builds, but I didn't notice that the domain itself is different for PR builds. Is there something we can do config-wise to have that URL replaced in PR builds so we can test these things without merging?

@stsewd
Copy link
Member

stsewd commented Oct 26, 2022

Is there something we can do config-wise to have that URL replaced in PR builds so we can test these things without merging?

Currently, no, but it may be possible in the future, see #8260 and #8529.

@etsauer
Copy link
Author

etsauer commented Oct 26, 2022

Ok, well thanks for the help. I'll close the issue.

@etsauer etsauer closed this as completed Oct 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Needed: more information A reply from issue author is required Support Support question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@humitos @etsauer @stsewd