-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Processed images are published without invoking .Permalink, .RelPermalink or .Publish #10255
Comments
@dgerhardt I am unable to reproduce this: template
commands rm -rf resources/ public/
hugo
tree public resources result
The resource is cached, but not published (it's not in the public directory). I'm probably missing something. Can you provide a more detailed example? |
@jmooring Sure. You can try the following example to reproduce the issue:
This will result in 7 published image files:
|
@dgerhardt Using your example I get this:
Here's a test repo to try: git clone --single-branch -b hugo-github-issue-10255 https://github.com/jmooring/hugo-testing hugo-github-issue-10255
cd hugo-github-issue-10255
hugo
tree public resources The template code is in |
@jmooring Thank you for further looking into this. I've now switched from the Docker images to the the official v102.3 binary to make sure the version wasn't the cause of the issue. I was able to reproduce the issue with your repository but it only happens once the cache exists. Fresh start without cache:
Only delete public this time - keep the cache:
|
Confirmed. MRE: git clone --single-branch -b hugo-github-issue-10255 https://github.com/jmooring/hugo-testing hugo-github-issue-10255
cd hugo-github-issue-10255
hugo && tree public resources # Results are expected
hugo && tree public resources # Results are NOT expected |
I think I have observed this myself, and I'm also pretty sure I have this fixed in a branch that has taken me a bit longer to get over the finish line than I planned. I have been side stepped a little lately, but I plan to pick up this particular ball on Monday. |
@bep Since you mentioned that you might already have a fix: Did you have the chance to have another look at it? |
Reproduced on
This also happens with image resources from a headless bundle, e. g. a sub-folder of a top-level section, with It's even worse:
This is clearly not what I was expecting. The reason why I set https://gohugo.io/content-management/build-options/#publishresources Dunno, if it matters, but I have a dual-language setup, i. e. the headless bundle has (and needs) an
I'm currently trying to figure out under which conditions a page resource is (supposed to be) published: |
I noticed another situation in which this could cause issues. I had created a custom This was happening, even if I delete my I solved this by using |
Thanks, that worked for me for a related issue. I was using a resized image in my |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
According to the docs, assets in the
assetDir
directory are only published by invoking.Permalink
,.RelPermalink
, or.Publish
. This is true for the source images but once image processing methods are applied, the result is automatically published. This can have a significant impact on the size of build artifacts, especially when multiple operations are performed on images.For my use case, I am resizing two images, merge them with the overlay filter, convert them to webp and then generate a fingerprinted permalink. This leads to a huge number of published image variants which are never used.
Update: The issue seems to only occur once the cache exists. When
cacheDir
is deleted before the build, the issue can no longer be reproduced.What version of Hugo are you using (
hugo version
)?Does this issue reproduce with the latest release?
Did not check against v0.102.x because klakegg's Docker images are not available yet but there are no related changes documented for this version.Yes, tested with v0.102.3.
The text was updated successfully, but these errors were encountered: