Incompatible with jsonapi_default

Thanks for this issue; the two modules should definitely be made compatible.

"the $include_parameter can't get the "include" query parameter on the second request"-- Why is this? Is the jsonapi_default module removing the include query parameter?

Adding a related issue in JSON:API Extras module. We need to determine whether the bug is in JSON:API Extras or JSON:API Include. I don't want to add a workaround for a bug in another module; if the bug is in JSON:API Extras, it should be fixed there. If someone can demonstrate that the bug is in the JSON:API Include module, we will fix it here.

Ok, thanks for the additional information.

My initial assessment is that this should be fixed in jsonapi_extras, not jsonapi_include. But, I am willing to consider a solution here if there's a good argument for fixing it in jsonapi_include instead.

Hello,
Patch not working on our website. After refresh data is still missing.

Drupal 10.3.10
Next.js 2.0.0-beta1
jsonapi_extras 3.26.0
jsonapi_image_styles 3.0.2
jsonapi_include 1.8.0
jsonapi_menu_items 1.2.6
jsonapi_resources 1.2.0
jsonapi_search_api 1.0.0_search_api
jsonapi_advanced 1.0.6

Please check the related issue: #3487895: Initial request shows complete response on an included field, consecutive request shows incomplete response (/jsonapi/user/user).

As a workaround, do not use the default includes feature of JSON:API Extras; that seems to be the cause of this issue.

Postponing this because I think it should be fixed in JSON:API Extras (see my comments in #6 and #8).

https://git.drupalcode.org/project/jsonapi_include/-/merge_requests/28 is resolving this issue for me for now but is more of a work around for sure.

The issue is the resources are cached so on the second pass we're never hitting the following:

https://git.drupalcode.org/project/jsonapi_extras/-/blob/8.x-3.x/modules...

which sets the default includes param to the request

$request->query->set('include', implode(',', $includes));

Either jsonapi_defaults needs to ensure this is set even when loading the resource response from cache or jsonapi_include needs to think about caching too - if we cache the generated output from `parseJsonContent` with the same cache tags / context as the resource then we'll only be processing when uncached and therefore have the include param available.

Hi @ptmkenny,

As a workaround, do not use the default includes feature of JSON:API Extras; that seems to be the cause of this issue.

I don't understand this answer because if I don't use the Default include list field (see screenshot), I don't have any base includes.
For information, here is our page structure :
Page -> parent paragraph -> list of child paragraphs containing one or more media.

Could you explain to me how to add the inclusion of paragraphs and media without using this field ?

The "default includes" feature of JSON:API Extras and this module are currently incompatible, so you cannot put any value in that field and use this module.

Instead, I believe you can just use an ?includes=node.image in the standard way for JSON:API. See the documentation on includes for more info.

The patch https://git.drupalcode.org/project/jsonapi_include/-/merge_requests/28 is very useful while a solution is figured out in #3487895: Initial request shows complete response on an included field, consecutive request shows incomplete response (/jsonapi/user/user). Works perfectly with jsonapi_extras, jsonapi_default and jsonapi_include. In case we need any module that requires jsonapi_resources (for example jsonapi_menu_items) the endpoints of these modules will stop to work after this patch is applied.

The error message while calling any endpoint that requires jsonapi_resources will be:
Error: Call to a member function getThirdPartySetting() on null in Drupal\jsonapi_include\JsonapiParse->parseJsonContent() (line 292 of /var/www/html/web/modules/contrib/jsonapi_include/src/JsonapiParse.php).

This can be avoided changing in the patch:

$defaultIncludes = $resourceConfig->getThirdPartySetting(
        'jsonapi_defaults',
        'default_include',
        []
      );

to

$defaultIncludes = $resourceConfig?->getThirdPartySetting(
        'jsonapi_defaults',
        'default_include',
        []
      );

Avoiding the call of the method on a empty object and ignoring this logic for the jsonapi_resources based endpoints.

I can confirm the issue (and fix) described by @betoscopio

@daniel korte Thanks for keeping the MR up-to-date.

As stated in #8, I think this issue needs to ultimately be fixed in #3487895: Initial request shows complete response on an included field, consecutive request shows incomplete response (/jsonapi/user/user), but it's good to have a workaround available here.

This issue has now been fixed upstream in #3487895: Initial request shows complete response on an included field, consecutive request shows incomplete response (/jsonapi/user/user). Thanks everyone for the workaround and your patience.