CODEWITHSUNDEEP
jekyllgithub-pagesgithub-pages-deploy-action
Start-Automating
Start-Automating

Reputation: 8367

Why aren't Jekyll Assets Displaying Correctly?

I'm building a few GitHub Pages using Jekyll, and I'm stuck with a mystery.

A number of asset files existing in a repo, and yet they do not seem to render correctly.

One repro of things can be found in the repository for Irregular. Its gitHub page shows empty space where .gif assets should be.

The GitHub Actions log indicates it has been copied

The asset seems like it is there, but just renders as a transparency.

see: https://irregular.start-automating.com/assets/images/RegexSyntaxHighlighting.gif

Another repo can be found in the repository for EZOut. Its page also shows blank space where there should be images.

The image is displayed correctly when I run the pages locally.

What could be causing this behavior? What can I do to workaround it?

All ideas are welcome.

Thanks

Upvotes: 3

Views: 263

Answers (1)

Christian
Christian

Reputation: 5521

I have forked your repo and my GH pages build just shows up working fine with no changes, see https://cadamini.github.io/Irregular/

I have tested both images on my site (https://cadamini.github.io). It seems like an encoding issue. The raw content of both images looks different, one had normal characters, and the other one displayed � characters.

Your repository actually contains multiple versions of the file in question, but only one is working.

You seem to have (intentionally?) overwritten three of them two months ago. The last working version was this commit.

This got me thinking about what else could mess up the repository, and it seems like the culprit was a GitHub Action that replaced the files. I noticed an issue tracking this, and it appears fixing it has fixed the display issue.

As far as why it showed up as it did, I have some theories:

  1. Because the file was valid and then rewritten as text, some bytes were malformed and out of order.
  2. GIFs, being an older format, were able to guess at a resolution but otherwise fail to decode (hence appearing invisible, though not with the correct bounds).
  3. PNGs, being a newer format, recognized they were corrupted and failed to render.
  4. SVGs, which are really just XML under the covers, rendered fine

This just shows that encoding issues can visually manifest in many different ways with different formats. Very fascinating.

Upvotes: 2

Related Questions