Vector images not generating webp files

[KingHowler]

Have you checked that your issue isn't already filed?

• I read through FAQ and searched through the past issues, none of which addressed my issue.
• Yes, I have checked that this issue isn't already filed.

Bug description

al-folio doesn't convert ".svg" files to ".webp" files. ".svg" files are small and their quality isn't lost when being displayed so not converting it is the best option. I should also mention that the images are displayed on the website without any faults. The issue which I want to bring forth is the error logs. The workflow "Check for broken links on site" produces an error log which should not be generated.

How to reproduce the bug

• Add a .svg file in assets/img/
• Include this image in a post
• Push changes and check the Check for broken links on site

Error messages and logs

✗ [ERR] file:///home/runner/work/kinghowler.github.io/kinghowler.github.io/_site/assets/img/dec/logic-gates/NOR.svg-800.webp | Failed: Cannot find file

What operating system are you using?

Not applicable (e.g. you're using GitHub Pages or other hosting)

Where are you seeing the problem on?

Deployed site

More info

I suggest to create an exception case to not search for converted .svg files

[george-gca]

If it looks for converted svg files it means that the jekyll-imagemagick plugin is "converting" svg files. By converting I mean it is at least creating the tags with the .webp extension, since the Check for broken links on site workflow gets the links straight from the built site.

How are you adding the svg image to the post? Using figure.liquid?

[KingHowler]

Yes I am using figure.liquid

In the deploy workflow's log, there is a section which tells each image converted.

I have multiple images and Imagegick is converting all of them, but there is no log for any of my svg files which leads me to believe they are ignored when generating images.

[george-gca]

If you check

al-folio/_includes/figure.liquid

Line 17 in de4e89d

srcset="{% for i in site.imagemagick.widths %}{{ img_path | relative_url }}-{{ i }}.webp {{i}}w,{% endfor %}"

it creates a source to a .webp image even though none was generated. I believe we should add a check if the extension is not one of the ones in

al-folio/_includes/figure.liquid

Line 1 in de4e89d

{% assign img_path = include.path | remove: '.jpg' | remove: '.jpeg' | remove: '.png' | remove: '.tiff' | remove: '.gif' %}

and if it is not, don't add .webp source. If you manage to fix this, can you send a PR?

[KingHowler]

If you check

al-folio/_includes/figure.liquid

Line 17 in de4e89d

srcset="{% for i in site.imagemagick.widths %}{{ img_path | relative_url }}-{{ i }}.webp {{i}}w,{% endfor %}"

it creates a source to a .webp image even though none was generated. I believe we should add a check if the extension is not one of the ones in

al-folio/_includes/figure.liquid

Line 1 in de4e89d

{% assign img_path = include.path | remove: '.jpg' | remove: '.jpeg' | remove: '.png' | remove: '.tiff' | remove: '.gif' %}

and if it is not, don't add .webp source. If you manage to fix this, can you send a PR?

Ok will look into it

[KingHowler]

If you check

al-folio/_includes/figure.liquid

Line 17 in de4e89d

srcset="{% for i in site.imagemagick.widths %}{{ img_path | relative_url }}-{{ i }}.webp {{i}}w,{% endfor %}"

it creates a source to a .webp image even though none was generated. I believe we should add a check if the extension is not one of the ones in

al-folio/_includes/figure.liquid

Line 1 in de4e89d

{% assign img_path = include.path | remove: '.jpg' | remove: '.jpeg' | remove: '.png' | remove: '.tiff' | remove: '.gif' %}

and if it is not, don't add .webp source. If you manage to fix this, can you send a PR?

Ok will look into it

The faulty </source> tags might also be originating from here

[KingHowler]

I just took a look, the is not a fault in the code.
How do you process the .liquid files?

[george-gca]

What do you mean? Liquid files are processed during jekyll build.

[KingHowler]

What do you mean? Liquid files are processed during jekyll build.

I am asking if the you have written some code to dictate the processing of liquids or is it done automatically by jekyll. If it is done automatically then its an issue we will need to have to forward to the ones maintaining jekyll or liquid language.

[KingHowler]

Basically what I mean is that liquid has a feature where it automatically adds closing tags which it thinks are missing. The creators of Liquid must have accidentally set <source> to have a separate closing tag. In order to fix it we'll have to contact the ones maintaining Liquid.

[george-gca]

Every file that starts with a frontmatter

---

---

is processed by jekyll during build.

[KingHowler]

Every file that starts with a frontmatter

---

---

is processed by jekyll during build.

@george-gca, that's exactly what I meant. Jekyll processes liquid files right?
You haven't done anything to modify how the processing takes place. This means that the error is in liquid itself.

[KingHowler]

Right now I am working on adding repos to projects. When I am done I will fix the issue with vector images and then send a pull request.

[george-gca]

You haven't done anything to modify how the processing takes place

No, I haven't.

Actually liquid is a template language that jekyll uses. .liquid files only have this extension for better usage by code editors and prettier. But every file that starts with the front matter is processed by jekyll, no matter what the contents are. I've seem even some templates add the front matter to a javascript file to further change its contents.

[KingHowler]

You haven't done anything to modify how the processing takes place

No, I haven't.

Actually liquid is a template language that jekyll uses. .liquid files only have this extension for better usage by code editors and prettier. But every file that starts with the front matter is processed by jekyll, no matter what the contents are. I've seem even some templates add the front matter to a javascript file to further change its contents.

Yeah I read about all that. I also found at that liquid has this neat feature where it auto-closes missing tags.
That's where the issue of the non-existent </source> tag occurs. Liquid must think that <source> has a closing tag even though it doesn't. That's why even if you didn't write </source> you can still find it in the HTML files produced.