No apparent clean way to access the image object corresponding to a field
See original GitHub issueI posted this on the Lektor Gitter channel, and one of the devs who’s worked on the image processing infrastructure, @xlotlu , instructed me to post this here as a bug.
I’m putting the finishing touches on a thoroughly overhauled version of Lektor-Icon, a modern, highly responsive single-page theme (of that sort that it seems all the flashy personal and business “showcase”-type sites are after these days…) that also includes a blog and other goodies. I’m wanting to implement responsive image sizing, i.e. to be able to feed lektor one high resolution source image and spit out differently-sized versions with thumbnail()
for use with srcset
, or even just resizing one image appropriately.
However, I’m pretty new to all this, so and I can’t find a particularly clean and robust way to just turn the image name/path from a field into an image object that works with thumbnail. It seems there should be some way either in the model setup or a function to get the image at a filename/path, but I can’t seem to find it. The best I was able to do is call {% set hero_img_file = record.attachments.get(this.image) %}
inside the HTML template for the flowblock, and then call .thumbnail()
. Here’s a minimal example of such a flowblock model:
[block]
name = Hero
[fields.image]
label = Hero Background Image
type = select
source = record.attachments.images
and in my contents.lr
I have
hero:
#### hero ####
image: camg-classic-storm-rainbow.jpg
---
But that seems quite clunky and overly complex; I figure there must be a better way I’m missing, but it seems @xlotlu didn’t know of one either. Incidentally when trying to get the parent (to work around this and call this.parent.attachments
, before I stumbled across record.attachments
), I also found this.parent
doesn’t work for a flowblock; can that possibly be intended? Is there any other way to get a flowblock’s parent object if its needed?
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (10 by maintainers)
Top GitHub Comments
You’re right. I was being reductionist, sorry. I was trying to emphasize the “arbitrary number” bit. Thank you for the background on what you’re going through.
There’s a lot I could address here, but I’ll try to stay on topic.
This is related to #484. One way or the other, assets, and in particular image assets, should be made easier to work with. That you can’t call
.thumbnail
on an asset is problem. Soon, videos could have the same problem. Every method of Attachment instances and subclass (Images, Videos, future types) instances that makes sense for assets should still be something you can get, but for a lot of them you can’t.@CAM-Gerlach the first half of this is captured in #625, the other half being the actual “image”-type field. I suggest you create a new issue for it to can keep things orderly, since this kinda turned into a support / philosophical discussion.
(As well for any other issues you captured here. E.g. appending to a template block from another, to be able to push styles into
<head>
? Anything else?)