Skip to content
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

Add ability to enable/disable at site level #10

Open
pensivedog opened this issue Sep 3, 2023 · 5 comments
Open

Add ability to enable/disable at site level #10

pensivedog opened this issue Sep 3, 2023 · 5 comments

Comments

@pensivedog
Copy link

Summary

Add ability to enable/disable all Hyas images-based image processing at the site level in config.

Basic example

Ideally, via a param in hugo.toml, such as hyas_images = false for local development, which can be overridden to true in production/config.toml.

Motivation

I have a site with thousands of images. Using Hyas images image processing in single, list, partial templates, and shortcodes increases build times significantly, making local development much more difficult and time consuming. I have created a custom site-level param to achieve this functionality, and simply reference it in my templates as follows:

{{ if .Site.Params.hyas_images }}
            {{ partial "picture" (dict
            "ctx" .
            "src" $image
            "alt" .Title
            "class" "my-classes"
            )}}
{{ else }}
            <img src="{{ $image.RelPermalink }}" class="myclasses">
{{ end }}

This works fine in templates, but it doesn't work with Hyas images processed through shortcodes. This approach also requires a lot of extra coding, as I have many templates this logic needs to be added to.

Built-in site-level enable/disable would be so much better for cases like this.

@h-enk
Copy link
Member

h-enk commented Sep 3, 2023

@pensivedog
Copy link
Author

Thanks for the reply. I'm not overriding any default cache settings, except the one that came with Hyas:

[caches]
  [caches.getjson]
    dir = ":cacheDir/:project"
    maxAge = "30m"

With the disabling method mentioned above, I still see the width warning on each build for images processed through the shortcode.

Is there some custom cache setting that I need that I'm missing?

@h-enk
Copy link
Member

h-enk commented Sep 4, 2023

Is there some custom cache setting that I need that I'm missing?

This should do:

[caches]
  [caches.assets]
    dir = ':resourceDir/_gen'
    maxAge = -1
  [caches.images]
    dir = ':resourceDir/_gen'
    maxAge = -1

With the disabling method mentioned above, I still see the width warning on each build for images processed through the shortcode.

Is the width of these images below the smallest width:

image:
  ## General
  type: page # page (default) or global
  widths: [480, 640, 768, 1024, 1366] # [600, 900, 1300] (default)
  [..]

Or, are you using custom widths — see e.g. https://github.com/future-wd/hugo-responsive-images#shortcode---cropping-an-image-to-an-aspect-ratio-custom-respnsive-widths

@pensivedog
Copy link
Author

I'm not using custom widths. Yes, some images have widths below the smallest width specified for processing, hence the warning messages. But I still get the warning messages even after adding these caches.assets and caches.images config settings, which means they're still getting processed on each build.

Also, these cache settings are the hugo default... As far as I understand, that means they will only have any impact if set to any other values, right?

@h-enk
Copy link
Member

h-enk commented Jan 26, 2024

Images 3.0 improves image generation time — significantly — thanks to using better templates

Note that, images are only rebuilding when you run for example:

npm run clean:build && npm run dev

For production, see Image processing performance consideration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants