How to reproduce
git clone https://github.com/deining/vitalcontrol.de/
cd vitalcontrol.de
npm install
hugo server
In your browser, go to:
http://127.0.0.1:1313/en/docs/data-link/vcsynchronizer/installation/
With hugo v0.122.0, images are displayed fine. With hugo v0.123.0, images are not shown any more.
Any help is appreciated!
npm install
npm ERR! code 1
npm ERR! path /home/jmooring/temp/vitalcontrol.de/node_modules/hugo-extended
npm ERR! command failed
npm ERR! command sh -c node postinstall.js
Thanks for looking into this!
Can you please try from branch hugo-v0.123.0:
git clone -b hugo-v0.123.0 https://github.com/deining/vitalcontrol.de
I removed offending module hugo-extended there, it is not needed to reproduce my issue.
This exists:
content/de/docs/data-link/vcsynchronizer/images/_index.md
This does not:
content/en/docs/data-link/vcsynchronizer/images/_index.md
So in de the images directory is a section, but in en it is not. And since neither directory has content, it doesn’t look like a section to me.
If you do this:
rm content/de/docs/data-link/vcsynchronizer/images/_index.md
The images appear as expected when visiting:
http://localhost:1313/en/docs/data-link/vcsynchronizer/installation/
I’m still scratching my head a bit on this one.
Prior to v0.123.0 orphaned files were blindly copied to the publish directory. With v0.123.0 and later, they are not (this is intentional). My best guess is, without a section page in content/en/docs/data-link/vcsynchronizer/images, Hugo thinks the directory contents (recursively) are orphans.
There may be a bug here, but if so it is subtle and edge-casey. Having a directory in one language a section, and the same directory in another language not a section, seems like a rare use case, if not an outright structural error.
This needs some more investigation.
The fix is to make neither directory a section, or both directories a section.
I opened a docs issue a few days ago to describe the change in orphan file handling…
https://github.com/gohugoio/hugoDocs/issues/2428
…but obviously haven’t gotten there yet.
A very small reproducible example…
git clone --single-branch -b hugo-forum-topic-48359 https://github.com/jmooring/hugo-testing hugo-forum-topic-48359
cd hugo-forum-topic-48359
rm -rf public && hugo && tree public
Now remove this file:
rm content/de/s1/images/_index.md
And test again:
rm -rf public && hugo && tree public
All good!
When a directory in one language is a section (has an _index.md file), and the same directory in another language is not a section, some of the page resources are treated as orphaned (not published).
@bep This is an edge case; not sure if it qualifies as a bug. The test example above is quick to run.
I have not tested the above, but in my head they are treated as duplicates (one of them is thrown away); you cannot have both a leaf and a branch bundle with the same logical page Path. We could possibly warn about it.
Indeed, that solved the issue for me. Thanks for your investigation and your help, much appreciated!
Warning about this seems a good idea to me.
Understood. The example above is slightly different.
content/
├── de/
│ └── s1/
│ ├── images/ <-- branch bundle
│ │ ├── _index.md
│ │ └── a.jpg
│ └── p1.md
└── en/
└── s1/
├── images/ <-- just a dumb directory of s1 page resources
│ └── b.jpg
└── p1.md
Again, I’m not sure if this a bug or just an erroneous structure. I’ll log an issue (warn the user).
This seems to be the problem i’m having. All my header images are placed into a images/ directory, but if there is only a portuguese version of the page, it doesn’t show up.
content/post/2021/2021-11-09-facebook-empresas-meta has index.pt.md and this frontamatter
resources:
- src: images/roman-martyniuk-QQhAQHWvTYk-unsplash.jpeg
name: header
I then fetch the header with this code:
{{ $image := ""}}
{{ with .Resources.GetMatch "header" }}
{{ $image = (.Fill "402x269").Permalink }}
{{ else }}
{{ $image = .Site.Params.defaultImage }}
{{ end }}
<img src="{{ $image }}">
$image returns the default image if there’s no index.md in that folder.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.