[Bug]: 4.3 not reading data from site.<collection> correctly.

[JKarlavige]

Operating System

macOS Monterey

Ruby Version

ruby 3.0.3p157

Jekyll Version

jekyll 4.3

GitHub Pages Version

No response

Expected Behavior

On version 4.2.2, we have a _data collection, reading data from here works as expected, for example: {{site.data.customers}}. When logging the data, it shows an object with all properties.

In collections where we use a name property, that property is set correctly on the site, for example when using: {{include.event.name}}.

Current Behavior

Seeing odd behavior when reading our _data with site.data. When logging the data it shows a Jekyll hash, rather than the actual object: site.data.customers: #<Jekyll::DataHash:0x000000012cad8db0>

The name property is also being replaced by the filename in all collections. In our events collection, we have a name property is each file within the collection, for example: name: Coalesce 2022. However, the name property is replaced with the filename on the site in Jekyll 4.3.0 when using {{include.event.name}}. Screenshots below:

The same is occurring for another collection _resource-categories/case-studies.md:

---
name: Case studies
singular: Case study
slug: case-studies
description: ""
---

And when logged, the name property is replaced with the file name:

Relevant log output

Build installed latest Jekyll 4.3.0 version:
9:37:35 AM: Fetching jekyll 4.3.0
9:37:36 AM: Installing jekyll 4.3.0

We noticed these issues after Jekyll 4.3.0 was installed.
Reverting to Jekyll 4.2.2 reverted the issue:

10:10:58 AM: Fetching jekyll 4.2.2
10:10:58 AM: Installing jekyll 4.2.2

Code Sample

No response

[ashmaroli]

@JKarlavige May I know how exactly you're logging the site.data object. Yes, there has been an internal change into Jekyll::DataHash object, but I had tried my best to not expose that detail to users to maintain backwards compatibility. Guess, I overlooked something.

Is the repository accessible to public?

[ashmaroli]

@JKarlavige I have submitted a patch to fix the name attribute issue. Could you please cross-verify if that is acceptable to your use-case?
To check, you may point your Gemfile to the PR as:

gem "jekyll", github: "jekyll/jekyll", ref: "refs/pull/9167/head"

Thanks.

[JKarlavige]

@JKarlavige May I know how exactly you're logging the site.data object. Yes, there has been an internal change into Jekyll::DataHash object, but I had tried my best to not expose that detail to users to maintain backwards compatibility. Guess, I overlooked something.

Is the repository accessible to public?

Hi @ashmaroli, I can confirm your update looks to have fix the issues with the name property. However, I am still seeing issues with the items in our site.data collection. Unfortunately this is a private repo, but I will share as much as I could.

We have multiple .yml files within the _data/customers directory. Each .yml file includes a name and img property.

On Jekyll 4.2.2, we were accessing these files using site.data.customers, which returned an array of objects with the data from each .yml file.

On the new version of Jekyll, the same call returns: site.data.customers: #<Jekyll::DataHash:0x0000000129e50478>.

In our frontmatter, we have an array of customers:

customers:
  - Customer name
  - Customer name
  - Customer name

We are looping through this array, and pulling the data from the customer file under _data/customers:

{% for customer in customers %}
  {% assign thisCustomer = site.data.customers | where: "name", customer | first %}
     <div class="customer-img-contain">
       <img src="{{thisCustomer.img}}" alt="{{thisCustomer.name}}" width="120" height="45">
     </div>
{% endfor %}

However, when trying to get the customer file with the line: {% assign thisCustomer = site.data.customers | where: "name", customer | first %} it is unable to find that file as it appears site.data.customers is returning that data hash and not the actual object.

I am using the following command to log the data:

<script>
  console.log(JSON.parse(decodeURIComponent("{{ site.data.customers | jsonify | uri_escape }}")))
</script>

One note, it looks like calling individual files in the _data collection works. For example, we have a file in _data/announcement.yml, and calling site.data.announcement works. The issue seems to only occur when trying to call a directory rather than an individual file.

[suppadeliux]

Hello,
Having a similar issue on our documentation site, since the update.
Before => context.registers[:site].data['chapter_link'] inside one of our plugins, just to return the right value in order to handle it.
But now, the same calling returns simply => Jekyll::DataEntry:0x00007f088f3a1cd8
Any idea or hint about this?
I know is the hash which is returned now, but I have no idea where to fix this.
Anyways, thanks for the help!

[ashmaroli]

@JKarlavige Thank you for giving me additional context to reproduce the issue. I was able to create a sample using clues from your opening post and reproduce the error using the jsonify filter.
While I was able to "solve" the issue, I decided that the better solution would be to revert the commit that introduced the change.

[ashmaroli]

@suppadeliux Thank you for reporting the issue.
I have decided to revert the change and release v4.3.1 either today or tomorrow.

[suppadeliux]

Thanks for the quick fix! 🎉 🎉 🎉, everything is working as expected with the new version (4.3.1)