Paragraphs items + JSON:API includes

Created on 25 June 2019, over 5 years ago
Updated 30 June 2023, over 1 year ago

Hi! How to I can ?include= entity from array of fields?

I have model like this:

items: [
    {
      links: [Object],
      meta: [Object],
      body: [Object],
      subtitle: null,
      title: [Object],
      bg: [Object],
      images: [],
      id: '25230875-33e1-4a93-b57b-f3a72a134e42',
      type: 'paragraph--text_with_image'
    },
    {
      links: [Object],
      meta: [Object],
      body: [Object],
      subtitle: null,
      title: [Object],
      bg: [Object],
      images: [],
      id: 'dc7f2141-ef43-4fe4-8bf0-b4f08b2ce9f1',
      type: 'paragraph--text_with_image'
    }

If I use this include `?include=items,items.bg`, I get error

"errors": [
        {
            "title": "Bad Request",
            "status": "400",
            "detail": "`items.bg` is not a valid include path. `bg` is not a valid relationship field name. Possible values: paragraph_type, items.",
            "links": {

How to I can use this structure?

📌 Task
Status

Active

Version

11.0 🔥

Component
JSON API 

Last updated 7 days ago

Created by

🇷🇺Russia alexd73

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇨🇭Switzerland berdir Switzerland

    Running into this in a project. I'm pretty sure it's not paragraphs specific, just happens to be where this pattern is most commonly seen.

    The pattern is mixing allowed bundles with different fields. Based on my testing, it works fine with a nested field as long as all bundles have the same field for nested paragraphs, so if you have field_paragraphs and paragraph type A and B, and both have field_children, you can include that. If you add paragraph type C which does not have that field, it no longer exists.

    I think the relationships should be extended to support all relationships that at least one allowed bundle has, not just those that all allowed bundles have. Might need some extra runtime checks to verify that returned entities really have that field. Entity queries support this as well just fine.

    This isn't a thing that can or should be fixed in paragraphs, so I'm moving it back into core. There's a good chance that I'll be able to look into this in the next weeks.

  • 🇮🇳India varshith

    I came across this issue but unrelated to paragraphs.
    I had to include a field that was not present across all nodes.
    In FieldResolver, if any one bundle in results doesn't have this field, an error is thrown.
    So as a quick fix, I have added an extra condition to check all the entity_type fields in case the bundle doesn't have that field. This seems to work fine for my case.
    I am submitting this as a patch to get started. Pls let me know if this is not the correct way to handle this @berdir.
    I will look this a bit more in the following days.

  • last update over 1 year ago
    29,999 pass, 1 fail
  • 🇩🇪Germany osopolar 🇩🇪 GER 🌐

    We had run into this issue too and since then we just did sub-request to get additional data. Today I had the need to add such a "forbidden" include and surprisingly it worked. I remember, that in past it also worked and suddenly it stopped working. I am not sure about the conditions triggering the failure, but I found issue #3005274: [PP-1] Support for Paragraphs' ability to negate the entity reference selection . From that it seems that the issue may appear if the allowed entity reference bundles are negated (exclude allowed paragraphs from specific field). I tested it, inverted the paragraph selection and negated it and the error appeared. So would it be at least a workaround to not negate the entity reference bundles? Would be nice if people having this issue may check if they negate the allowed paragraphs selection and if the issue happens only then.

  • 🇺🇸United States afinnarn

    Just popping in to highlight the JSON:API spec and section on includes: https://jsonapi.org/format/#fetching-includes

    So the main question seems to be whether Drupal's JSON:API implementation should return an error if you try to request an invalid relationship across all resource types returned from the endpoint or just return an empty array for resources that don't include the specified field. Rather than see an error, I've wanted more information returned when I've run into this situation, so I'm guessing most Drupal developers would like to see this change.

    Either approach appears valid, but who/what/how do decisions like changing the current implementation at a higher level get discussed and resolved? I'd think that would require some other issue or change record beyond this issue, but I'm not sure.

  • 🇦🇪United Arab Emirates ThirstySix

    Re-roll patch from #11
    on Drupal 10.3.5

Production build 0.71.5 2024