When GET:ting data for nodes like /jsonapi/node/article the referenced images are correctly appearing in response so we get:

"field_image": {
                    "data": {
                        "type": "file--file",
                        "id": "1c563a12-6bb7-4aa0-be83-d2ba62c420cc",
                        "meta": {
                            "alt": "test",
                            "title": "",
                            "width": 320,
                            "height": 240
                        }
                    }

But if the entity type has a default image the file reference data is:

 "field_image": {
                    "data": null,
...

Reproduce:
1. Create an article with an image. => Request works.
2. Set a default image to article image field.
3. Create a new article using the default image. => Request gives null value to field_image.

CommentFileSizeAuthor
#4 3005528-4-do-not-test.patch4.32 KBwim leers

Issue fork drupal-3005528

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

TipiT created an issue. See original summary.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue tags: +API-First Initiative

Fascinating! Working to reproduce this.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: Default image data » Image field type's "default_image" functionality only works in formatters and widgets, not at the data level and hence not in HTTP APIs
Project: JSON:API » Drupal core
Version: 8.x-2.x-dev » 8.7.x-dev
Component: Code » image.module
Priority: Normal » Major
Issue tags: +data integrity

This is a core bug. Great find!

Found the root cause: the default image is only used by the field formatter, whereas it should be computed by the field itself.

\Drupal\image\Plugin\Field\FieldFormatter\ImageFormatterBase::getEntitiesToView() does this:

    // Add the default image if needed.
    if ($items->isEmpty()) {
      $default_image = $this->getFieldSetting('default_image');
…

But we need \Drupal\image\Plugin\Field\FieldType\ImageItem's list_class to compute this.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Active » Needs review
StatusFileSize
new 3005528-4-do-not-test.patch4.32 KB

I think something like this is what we want. Untested patch.

tipit’s picture

tipit commented

Well, that was fast!

"3005528-4-do-not-test.patch" OK, I won't. :)

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

You can test it, but IDK if it will work, I didn't actually run the code. The -do-not-test suffix is only there to ensure DrupalCI doesn't run automated tests :)

effulgentsia’s picture

effulgentsia commented

Does this bug exist for the default values of other core field types? Or only images?

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: Image field type's "default_image" functionality only works in formatters and widgets, not at the data level and hence not in HTTP APIs » Fields' "default value" functionality only works in formatters and widgets, not at the data level and hence not in HTTP APIs
Component: image.module » field system

Good question. I quickly checked, and yes, the same problem exists there too.

In the general case, the UI text for this is: The default value for this field, used when creating new content. — in \Drupal\field_ui\Form\FieldConfigEditForm::form().

So at least that somewhat implies it only applies at content creation time, i.e. that it's not dynamically computed. Still, that either ought to apply to entities created through the REST API also, or the UI text should be updated to clarify it only sets form defaults.

Apparently this setting is disconnected from the setDefaultValue() and setDefaultValueCallback() operations on field definitions.

Generalizing. Good catch, @effulgentsia!

tipit’s picture

tipit commented

The patch did not quite work because I get:

Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to
allocate 262144 bytes) in
web/core/modules/image/src/Plugin/Field/FieldType/ImageItemList.php on line
17
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to
allocate 262144 bytes) in Unknown on line 0
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to
allocate 262144 bytes) in Unknown on line 0
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to
allocate 262144 bytes) in Unknown on line 0

when navigating to /node/add/article. I don't think the patch is good enough
from the performance perspective because I also needed to pump up the max
execution time to over 60s.

What I also noticed depending on which node type I try to create e.g.
/node/add/habit the error line.

E.g. habit gives in
web/core/lib/Drupal/Core/TypedData/ComputedItemListTrait.php on line 34

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Thanks for trying the patch! (I also unpublished your comment at #2958554: Allow creation of file entities from binary data via JSON API requests about this, to keep that issue focused).

This is very much a PoC patch, so I understand that it doesn't work.

tipit’s picture

tipit commented

You did everything right - again. So thank you - again.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

maseyuk’s picture

maseyuk commented

I've just tried the patch out and it looked like the isEmpty() check in core/modules/image/src/Plugin/Field/FieldType/ImageItemList.php was causing the loop. I just removed that and everything seems to be working as hoped. (Even without the isEmpty check if a genuine image has been uploaded its not overwritten by the default which I thought might happen without the isEmpty check)

I've not tested with the original posters jsonapi issue I was testing the related issue to do with image field tokens and the metatags module not showing the default image value when no image has been uploaded

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

hudri’s picture

hudri
Primary language German
Location Austria
commented
Status: Needs review » Needs work

IMHO the default value should not be computed, but stored. The problem with computed default values - no matter if on field widget level or if in FieldItemList - is that a user can't nullify a computed default value. Currently you can override a default image, but it is not possible to remove a default image on a single instance of a content entity. Please see the referencing issue #3250680

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

amjad1233 made their first commit to this issue’s fork.

ro-no-lo’s picture

ro-no-lo commented

Is there any plan to fix this for Drupal 9.4? Or could be work around with a jsonapi_default_image module?

ro-no-lo’s picture

ro-no-lo commented

@wim-leers: is it also possible to fix it via a module which hacks into the json:api request, thus I can _easily_ provide default images? I don't want to patch every Drupal core all the time.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.