Entity reference revisions mapping broken in alpha27

I am not sure sure I am able to reproduce your issues.

Below are 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 'Paragraphs' (not 'Entity reference revisions')
• Confirm that recipeIngredients is using the Ingredients paragraph (/node/add/recipe)

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

I am pretty sure #3469251: Improve layout starter kit caused this regression.

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

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

#3489462: Improve field type categorization. will return it to the 'References' category in the Schema.org Blueprints UI.

I merged #3489462: Improve field type categorization.. 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 #3481313: Track and prevent displayed entity reference recursions in JSON-LD

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: Setup schema in Ingredients paragraph. 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, drush updb -y and clear the cache.
9. Step 9: Just edit and save the schema in the Recipe content type configuration.
10. Step 10: Check the Recipe node again:
    • Ensure the schema is rendered correctly.

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
        }
    ]
}

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.

@see #3497197: Ensure the variation cache is cleared for JSON-LD.

Can you please try fully clearing
your cache?

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

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

I have tried hook_schemadotorg_jsonld_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!