Make `image` key configurable for thumbnails/images #421

Schallbert · 2025-11-16T19:26:13Z

Why this change?

Some people like me use themes where the image key in a post's front matter is either already taken (e.g. for a banner image) or unused.

I use (minimal mistakes) that has a different way of organizing a post's frontmatter with header.teaser.

This PR should solve the issue with a customizable key: thumb_path_key can be set in _config.yml and will point the liquid template to the correct thumbnail image path.

This can help deduplicate front matter information.

What I touched

~~- I have reorganized the generator's code just a bit so its main routine looks shorter for readability.~~

In the liquid template, thumb_path_key is evaluated and split to allow for higher nesting depths in the front matter like header.teaser
I updated the affected readme section with examples, might be a bit lengthy now.

Still this change keeps backwards compatibility due to default values for image and image.path.

Testing

add tests for changes in feed.xml
add tests for the updated .rb paths

minor refactoring in generator.rb

- exchanged image.path and image defaults

parkr · 2025-11-17T20:16:40Z

Thanks for the PR! It's generally good hygiene to keep each PR narrowly focused. Would you mind pulling your refactor into a separate PR? Anything directly related to the image path change is fine to stay.

Schallbert · 2025-11-17T22:23:21Z

OK, will do.
I'll also write some tests for the new behavior.

parkr · 2025-11-18T17:19:58Z

Thank you!

Schallbert · 2025-11-19T20:39:05Z

I hope we should be good to go now.

parkr

Thank you! First pass of review.

parkr · 2025-11-22T17:29:00Z

README.md


-* `image` - URL of an image that is representative of the post (can also be passed as `image.path`)
+* `image` - URL of an image that is representative of the post. It can also be passed as `image.path` or set by the user. 
+To customize, go to your `_config.yml` and add the field `thumb_path_key: your.image.key`. Dots express nesting depth of the key. 


Did you mean this to be all part of one list item in the unordered list? To create a new paragraph you'll need a blank line between. If intended, no problem.

Yes, I wanted it to be as short as possible:

parkr · 2025-11-22T17:30:58Z

lib/jekyll-feed/feed.xml

      {% endif %}

-      {% assign post_image = post.image.path | default: post.image %}
+      {% assign thumb_key = site.data.thumb_key %}


We use the term "image" previously, not "thumb". Could you update this to "image_path_key" or "image_path_frontmatter_key"?

OK, changing all ocurrences of "thumb" to "image" for consistency.

parkr · 2025-11-22T17:31:57Z

lib/jekyll-feed/feed.xml


-      {% assign post_image = post.image.path | default: post.image %}
+      {% assign thumb_key = site.data.thumb_key %}
+      {% capture key_parts %}{{ thumb_key }}{% endcapture %}


The key is already a string. Is the capture necessary? Couldn't it be split directly? I believe this is allowing the key to have liquid of its own which might be overkill.

Right you are. It is a leftover of my tries to get the job done without having to split. Thought I could avoid the loop. Removed.

…sary capture

parkr · 2025-11-23T01:36:25Z

lib/jekyll-feed/generator.rb

        Jekyll.logger.info "Jekyll Feed:", "Skipping feed generation in development"
        return
      end
+      site.data['image_key'] = get_image_key


I believe this can be removed, is that right? I don't think we're using it in the feed.xml Liquid.

Currently this is where I hand over the image key to feed.xml so it becomes available for retrieving the image path.
If we pulled the key from the config directly in Liquid, we could avoid adding code in ruby altogether. Without ruby involved though, I wouldn't know how to add the log line about using a custom path key.

parkr · 2025-11-24T05:08:56Z

lib/jekyll-feed/feed.xml

      {% endif %}

-      {% assign post_image = post.image.path | default: post.image %}
+      {% assign image_key = site.data.image_key %}


In a site with site.data.image_key missing, will any of this fail? Perhaps we should consider adding a default: "image" here so that it always has an image_key. Then we can remove the default: post.image below on line 126.

It wouldn't fail because site.data.image_key defaults to image.path which tries replicating the behavior we had before the change (if image.path is empty it tries post.image)

parkr · 2025-11-24T05:09:58Z

lib/jekyll-feed/generator.rb

+        Jekyll.logger.info "Jekyll Feed:", "Using custom image_path_key = #{image_path_key}"
+      end
+      return image_path_key
+    end


Same with this -- I believe it can be removed.

As written above. Would you like me to try a liquid-only variant? It would be getting the key from the config posts_limit times then and we wouldn't have a log line, but it will definetely simplify things.

Let's keep the log line - I think it's useful.

…quired anymore

Schallbert · 2025-11-24T13:40:35Z

generator.rb: Modifiy get_image_key to check_custom_image_key that won't to anything but log if we detect a custom image key
generator_spec.rb: Removed altogether as there's nothing left in the generator that affects the feed.
feed.xml Read site.image_path_key directly.

Schallbert · 2025-11-25T16:50:42Z

lib/jekyll-feed/feed.xml

+      {% assign image_key = site.image_path_key | default: "image.path" %}
+      {% assign key_array = image_key | split: "." %}
+
+      {% assign image_value = post %}
+      {% for key in key_array %}
+        {% assign image_value = image_value[key] %}
+      {% endfor %}


I just see that these lines could be moved above the "post" loop as they just need to be executed once which would make the code more efficient. On the other hand readability and cohesiveness would degrade, as the variable image_value is instantiated there but used somewhere else. Any opinions?

The image_key and image_key_array could be pre-calculated above outside the loop to speed things up. The image_value would need to be calculated inside the loop to ensure it gets the right value for each post. I think the cleanest solution could be:

Outside the loop: if site.image_path_key is non-null, build key_array.
Inside the loop: if key_array is non-null, build image_value. Assign post_image as post_image = image_value | default: post.image.path | default: post.image

What do you think?

parkr · 2025-11-26T15:50:43Z

lib/jekyll-feed/generator.rb

+        Jekyll.logger.info "Jekyll Feed:", "Using custom image_path_key = #{image_path_key}"
+      end
+      return image_path_key
+    end


Let's keep the log line - I think it's useful.

parkr · 2025-11-26T15:53:47Z

spec/jekyll-feed_spec.rb

+
+    image_key_tests.each do |test_case|
+      it "correctly processes image_key: '#{test_case[:thumbs]}'" do
+        site.data["image_key"] = test_case[:thumbs]


Does this need to be image_path_key to pass?

parkr · 2025-11-26T15:56:20Z

lib/jekyll-feed/feed.xml

+      {% assign image_key = site.image_path_key | default: "image.path" %}
+      {% assign key_array = image_key | split: "." %}
+
+      {% assign image_value = post %}
+      {% for key in key_array %}
+        {% assign image_value = image_value[key] %}
+      {% endfor %}


The image_key and image_key_array could be pre-calculated above outside the loop to speed things up. The image_value would need to be calculated inside the loop to ensure it gets the right value for each post. I think the cleanest solution could be:

Outside the loop: if site.image_path_key is non-null, build key_array.
Inside the loop: if key_array is non-null, build image_value. Assign post_image as post_image = image_value | default: post.image.path | default: post.image

What do you think?

Schallbert · 2025-11-26T21:54:38Z

Outside the loop: if site.image_path_key is non-null, build key_array.

Makes sense to me. What I can't get my head around right now (too tired) is how I should build the value outside the loop and prepend post afterwards inside. Maybe I need to work with empty array index [0] , place post and reconvert it to a key or maybe I need the post array of length 1 and append the pre-build image_value...

Will take another look at it tomorrow.

spec: fix naming error image_path_key

Schallbert · 2025-11-30T20:00:16Z

Now, three tests fail:

They all fail because at a place where I'd expect object-image.png the spec result shows image.png and I just cannot figure out why. My real website is built fine and has no image-swap issues.

I guess I need some help getting the tests to pass.

Schallbert added 2 commits November 16, 2025 19:54

make 'image' key user-customizable

3091e81

minor refactoring in generator.rb

update readme: explain customization of image key in front matter

3c9018a

Schallbert changed the title ~~Add user customization to image key for thumbnails/images~~ Make image key configurable for thumbnails/images Nov 16, 2025

make tests run OK

04ced07

- exchanged image.path and image defaults

Schallbert added 3 commits November 18, 2025 21:46

rewind refactoring in generator

813f123

add tests for ruby code

b1f2c24

add custom thumb_key tests

2e2a729

unify header of spec.rb files

005ae90

parkr reviewed Nov 22, 2025

View reviewed changes

address review findings: Replace "thumb" with "image", remove unneces…

9cb1899

…sary capture

parkr reviewed Nov 24, 2025

View reviewed changes

Schallbert added 2 commits November 24, 2025 14:04

update to have business logic in Liquid only

7ff6ce4

fix liquid error, use double quotes, remove generator tests as not re…

39d19c7

…quired anymore

Schallbert commented Nov 25, 2025

View reviewed changes

parkr reviewed Nov 26, 2025

View reviewed changes

feed: pull some assignments before post-loop for efficiency

2065ad8

spec: fix naming error image_path_key

Make image key configurable for thumbnails/images #421

Are you sure you want to change the base?

Make image key configurable for thumbnails/images #421

Uh oh!

Conversation

Schallbert commented Nov 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why this change?

What I touched

Testing

Uh oh!

parkr commented Nov 17, 2025

Uh oh!

Schallbert commented Nov 17, 2025

Uh oh!

parkr commented Nov 18, 2025

Uh oh!

Schallbert commented Nov 19, 2025

Uh oh!

parkr left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Schallbert commented Nov 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Schallbert commented Nov 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Schallbert commented Nov 30, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Make `image` key configurable for thumbnails/images #421

Make `image` key configurable for thumbnails/images #421

Schallbert commented Nov 16, 2025 •

edited

Loading

Schallbert commented Nov 26, 2025 •

edited

Loading