Entity reference revisions mapping broken in alpha27

My steps to reproduce...

• Create an Ingredients paragraph type with a simple name field. (/admin/structure/paragraphs_type)
• Create Recipe Schema.org type (/admin/structure/types/schemadotorg?type=Recipe)
• Manually change recipeIngredients from 'Text (plain)' to 'Entity reference revisions'
• Confirm that recipeIngredients is NOT using the Ingredients paragraph (/node/add/recipe)

I am pretty sure 📌 Improve layout starter kit Fixed caused this regression.

I part that I cannot do is:

Manually change recipeIngredients from 'Text (plain)' to 'Paragraphs' (not 'Entity reference revisions')

When I try to manually map recipeIngredient, I only get the choice of Entity reference revisions (there are no Paragraphs, ever for other Paragraphs). I only see Entity reference revisions for all the paragraphs. (see attached screenshot)

My Ingredients Paragraph looks like the 2nd screenshot.

What field type are you using? 'Paragraphs' or 'Entity reference revisions'

In the Recipe content type, for the Ingredients field, it's:
Entity reference revisions
Reference type: Paragraph
Paragraph type: Ingredients

Just an fyi, my Recipe content type existed before I started using the Schema.org Blueprint module, so I did not create Recipe Schema.org type as in your second bullet point (although I don't think this has anything to do with it).

Forgot to attach the first screenshot to my last message.

I think you are running into 📌 Prepare for 10.2: Move preconfigured paragraph field type to general category, fix tests Fixed

The Paragraphs field has been moved to the 'General' category.

📌 Improve field type categorization. Active will return it to the 'References' category in the Schema.org Blueprints UI.

I merged 📌 Improve field type categorization. Active . I am almost certain that fixes the issue. Please reopen this ticket if I am wrong.

I have checked after applying patch ( #3489462: Improve field type categorization.) but still facing the same issue.

Before updating module

After updating module

the screenshot took from 'https://search.google.com/test/rich-results'

Ingredients in a paragraph reference field.

I don't know how you got the custom Ingredients paragraph type to automatically switch recipeIngredient to use the entity reference revision field.

My steps in attempting to reproduce

• Downgrade to alpha26., `git checkout 1.0.0-alpha26`
• Clean installation with schemadotorg, schemadotorg_ui, and schemadotorg_paragraphs enabled.
• Create the Ingredient paragraph type (not mapped to Schema.org) with a simple name field.
• Create a Recipe content type
• Confirm the recipeIngredient field is still a plain text field.

There is a custom module for altering recipe ingredients, but before making the alterations, I have dumped the array.
Please review it.

In module version alpha26:

In module version alpha27:

The change via JSON-LD is most likely due to the addition of "Schema.org type entity references display" settings in /admin/config/schemadotorg/settings/jsonld.

@see 📌 Track and prevent displayed entity reference recursions in JSON-LD Active

I have reproduced the issue in fresh Drupal 10 environment

Demo: Google Drive video Link

Steps to Reproduce:

1. Step 1: Install fresh Drupal 10.
2. Step 2: Install Schema.org modules (alpha 26):
   • Schema.org Blueprints
   • Schema.org Blueprints Corresponding Entity References
   • Schema.org Blueprints JSON-LD
   • Schema.org Blueprints JSON-LD Custom
   • Schema.org Blueprints Media
   • Schema.org Blueprints Node
   • Schema.org Blueprints Paragraphs
   • Schema.org Blueprints UI
   • Schema.org Metatag
3. Step 3: Create a content type: Recipe.
4. Step 4: Create an Ingredients paragraph:
   • Add a field named ‘Ingredient’ of type Text with unlimited cardinality.
5. Step 5: Create a schema for the Recipe content type:
   • Set Ingredient as an entity reference for the Ingredients paragraph.
6. Step 6: Use textObject in the schema:
   • Map the Ingredients paragraph to show as a textObject in the schema.
7. Step 7: Create a node in the Recipe content type:
   • Check if the schema is rendered correctly.
8. Step 8: Update Schema.org module to alpha 27 and clear the cache.
9. Step 9: Update the schema in the Recipe content type configuration.
10. Step 10: Check the Recipe node again:
    • Ensure the schema is rendered correctly.

Updating priority as this blocks us from upgrading past alpha26. Let us know if you need any more details or in what way we can help.

I am almost sure that the recommendation via #12 is correct, and you will need to adjust the "Schema.org type entity references display" settings (/admin/config/schemadotorg/settings/jsonld)

It takes a lot of time for someone to reproduce your specific example.

You might need a developer to debug your issue or write a hook to alter the JSON-LD to meet your requirements.

The module is still in alpha releases which means APIs and output can change,.

I was able to reproduce the issue/regression, and it is a one-line fix.

I noticed that the Schema.org Blueprint Additional Mapping module validated the https://schema.org/recipeIngredient property, and https://schema.org/TextObject is an expected value. The Schema.org Blueprint Additional Mapping module removes unexpected types.

In other words, the generated Schema.org JSON-LD (see below) using https://schema.org/TextObject is not valid via https://validator.schema.org/ (see below)

{
    "@context": "https://schema.org",
    "@type": "Recipe",
    "@url": "https://schemadotorg.ddev.site/recipes/some-recipe",
    "inLanguage": "en",
    "name": "Some recipe",
    "copyrightHolder": "Schema.org Blueprints Demo",
    "copyrightYear": 2024,
    "dateCreated": "2024-12-27 12:18:51 -05:00",
    "dateModified": "2024-12-27 12:19:13 -05:00",
    "isFamilyFriendly": true,
    "recipeIngredient": [
        {
            "@type": "TextObject",
            "inLanguage": "en",
            "name": [
                "Value 1",
                "Value 2",
                "Value 3"
            ],
            "position": 1
        },
        {
            "@type": "TextObject",
            "inLanguage": "en",
            "name": [
                "Value 4",
                "Value 4",
                "Value 6"
            ],
            "position": 2
        }
    ]
}

→

Thanks a whole bunch for helping on this, I really appreciate it.

I've tested the patch from #18 on alpha27 and alpha29

On alpha27 and alpha29 - I get the same results which are:

- it works, but I need to clear the cache each time I visit a node page with the structured data. If I visit another node page, the fields that use paragraphs in the structured data are entirely missing. I then clear the cache and I can see it works upon a refresh. When I say it "works", I mean I can see all the structured data as it should be (like if I was viewing it on alpha26).

I thought this might be a local caching issue or something, but then I tried alpha26 (with no patch) and it works flawlessly without having to clear cache. So I don't think it's a local caching issue.

You definitely need to clear the entire cache.

I merged the MR. If you see any more regressions, please update this ticket or open a new ticket.

Re-opening as I was able to make some progress on this.

(Sorry but this is a tricky and challenging issue to resolve coupled with the fact that it was also during a holiday period)

I took a look at the code from line 61 to 96 of schemadotorg_jsonld.module

If I commented out that code and applied the patch and used alpha29, it works. So I think the bug lies somewhere between line 61-96. Something related to caching but I cannot figure it out.

@see 📌 Ensure the variation cache is cleared for JSON-LD. Active

I have made a little more progress on this.

I applied the patch from this issues queue and also 📌 Ensure the variation cache is cleared for JSON-LD. Active and I am using alpha29. I am still getting this caching issue.

I took a deeper dive into the code.

This line of code in particular is causing the issue:

$data = $builder->build($route_match, $bubbleable_metadata);

If I commented that line out and manually provided $data, then it works.

The key difference between my manual $data and the $data provided by the build function lies in the structure of the recipeIngredient and recipeInstructions properties. In the build function $data, these properties start with an indexed array, meaning they have an initial key of 0, whereas in my manual $data, these are directly embedded without an index.

Can you hard clearing of your cache?

By restarting redis/memcache or manually clearing the cache tables in the database.

I've tried clearing caches as you mentioned. Still getting this issue. Our site is not using memcache/redis.

Importantly, I can replicate this issue on the master site, dev site and also locally (using ddev). So I'm 99.9% sure it's not environment specific.

I'm wondering if this is a Drupal core issue..? I've looked at your BubbleableMetadata implementation. It seems ok, but I'm not an expert in using Bubblemetadata.

To me it seems the problem is coming from the build() function and using Bubblemetadata. My latest conclusion at this point is that it works when not using BubbleableMetadata (like in alpha26).

I discovered that disabling Internal Page Cache resolves the issue. However, this is not a feasible long term solution.

Keep in mind, this issue only surfaced from alpha27 and going forward.

Can we close this issue now that we have determined custom code was causing the caching issue?

Just providing an update here (as we had some offline communications in Slack).

We have discovered the root cause. Long story short, we have a custom hook_page_attachments_alter() that uses the build() function.

However the build() function changed from alpha27+. So we need to update our code. If we did a straight copy/paste of most of your code in build() from alpha27+, it works.

But instead of doing it like this, we are trying to use one of the hooks like hook_schemadotorg_jsonld_alter() instead as this is the recommended way to achieve our customisations.

Apologies for this long issue which ended up being our custom code.

Changed to fixed, as patch in this issue is still needed.

I have tried hook_page_attachments_alter in Alpha 29, and it is working fine without any caching issues when using the patch from #18.
Without the patch, I am facing the same issue mentioned in #13.

In conclusion, the issue mentioned in #13 is valid and resolved using the patch from #18.

However, the caching issue is not valid.
Thanks for the great support!