To avoid wasting any more of your time, I think it would be best if you were to provide a minimal reproducible example.
@jmooring Understood. Will get a minimal repo together.
Now available at:
content/posts/_index.md does not have a corresponding image.
Ah. So I then added a PNG ending in
_index.png to cover that one, and it worked.
Then I added that same file to my real site and am still having the same errors as before (
expected images.ImageSource; got resource.Resource) — but with
warnf back in place, I now see among the many entries:
WARN 2022/07/22 12:06:40 %!s(<nil>)
…which suggests there’s another similarly missing image in there somewhere. So, while I’m still bug-chasing, I believe you’ve put me on the right track. Thanks!
Opinion: it would be less error-prone to use page resources for these OG images. Then you could use a generic name instead of having to match file names.
True, but I keep multiple posts in the same folder (arranged in a
content/posts/[YYYY]/[MM] format) so I assume I’d still have to give each overlay PNG file a different name rather than, say, a generic name of
…Unless I’m totally misunderstanding your meaning, that is.
Use leaf bundles.
content/ └── posts/ └── 2022/ └── 07/ ├── my-first-post/ │ ├── index.md │ └── og.png └── my-second-post/ ├── index.md └── og.png
Also falls in the category of if I were starting over, rather than 200+ posts into my current setup. But, duly noted, sir. I am always grateful for your help and time!
Update: Finally found the problem. There were a few files that had typos in their names, along with two additional ones I’d just missed creating. Once there finally was a corresponding and correctly named file for each (as I’d originally thought was the case), it worked. That said: for anyone searching this in the future who’s getting started: the advice I received above is absolutely correct — i.e., go with a leaf-bundle-based approach if you think you might similarly pair images and posts. It’s a lot less trouble in the long run.
Well, post a successful example dangit!?
Actually, my real repo (GitHub - brycewray/hugo_site: This is the repository from which the Hugo-generated version of https://www.brycewray.com is built.) has it now.
Note: For those following the above thread and wondering why I can’t easily implement the advice I was given, the problem is that I am also keeping each “title” file — what’s being overlaid in each case — separately on my local drive apart from the repo, hence the additional need to maintain separate files with unique filenames. Moreover: the whole point of this was to give me more control over the OG/Twitter card’s appearance. I used Hugo’s built-in text filter for a while, which is much simpler from a coding standpoint — but, at this writing, it doesn’t allow control over the overlaid text’s alignment (left-align only), its right-side padding (x-start and y-start only), or its word-breaking. …Hence, what I’ve done here. If those features ever get added to the text filter, it’ll be far and away a better choice.
Further edit from the next day: Also for those who find this thread later, I reconsidered the (as-always) excellent advice of @jmooring and decided to re-build my site that way. (At this writing, I’m finishing that up in a branch, but things are going well enough that I’ll probably merge it into
main later today.) He’s absolutely right that it is far less error-prone and, as an added benefit, makes the coding much simpler.
Pretty cool. So the Text function will just do a single line then with no wrapping or anything
No, it wraps — but you have no control over the wrap. You end up with stuff like this:
This is a post about Hugo
…instead of (adding simulated center-alignment, too):
This is a post about Hugo
This might help
Thanks. Actually, by the time I saw your reply, I had already done it manually in a branch — but this is still helpful info!
Later update: Have merged and pushed all the changes; I then wrote about the experience (with numerous links to this discussion):
I haven’t converted mine yet. Only a few. Initially, I wanted to keep my files as I used them in Jekyll in case I wanted to switch platforms (I was trying Hugo, Eleventy and Zola). But since I settled on Hugo, I am still thinking about converting all files to page bundles (nearly 300). So, I am still not converting mine until I decide to do so in the future.
It definitely was a multi-hour project, but the resulting templating is much less finicky to manage, just as @jmooring advised.
Indeed! All my posts with images are page bundles. Page resources are a bliss!
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.