Show computed field in JSON:API output

That's weird, it should just work -- see #3252278: Complete JSON:API's handling of field (including computed & empty fields) cache metadata, https://gorannikolovski.com/blog/add-computed-field-jsonapi-response

Can you debug?

> Thanks @joachim. It does just work in 2.x & 3.x. Both those links you shared would be pre 4.x, no?

They are for computed fields in general, independent of this module.

I’m experiencing the same issue. The field shows up everywhere except the JSON output.

Okay, it worked for me if I defined my computed field in code only (i.e. not adding the computed field to an entity bundle via the Field UI):

/**
 * Computed field string.
 *
 * @ComputedField(
 *   id = "computed_field_attached",
 *   label = @Translation("Computed field"),
 *   field_type = "string",
 *   no_ui = TRUE,
 *   attach = {
 *     "scope" = "base",
 *     "field_name" = "computed_field",
 *     "entity_types" = {
 *       "node" = {
 *         "article",
 *       },
 *     },
 *   },
 * )
 */

In that case, it it looks like this is a base field / bundle field problem.

I'm seeing the field in my jsonapi output, but it's only showing the first value. My computeValue method returns [1,2] but in the jsonapi I just see "1"

The root cause here comes from how JSON:API filters out internal properties.

By default, \Drupal\jsonapi\JsonApiResource\ResourceObject::extractContentEntityFields() calls \Drupal\Core\TypedData\TypedDataInternalPropertiesHelper::getNonInternalProperties(), which relies on \Drupal\Core\Field\FieldConfigBase::isInternal() to determine whether a field should be exposed.

That method checks the field definition for the internal key. If it’s missing, it falls back to isComputed(). This means any computed field without an explicit definition is treated as internal and therefore excluded from the JSON:API output.

Since \Drupal\computed_field\Entity\ComputedField does not provide a definition, it always ends up flagged as internal purely because it’s computed.

To work around this, I patched ComputedField so that it returns a definition from ::getFieldStorageDefinition(), and I propagate the internal flag from the plugin definition.

• By default, internal = FALSE, because most field properties are intentionally public.
• Developers can still override this via the plugin config (or extend the plugin settings form) if they want to explicitly hide a computed field from JSON:API.

This approach ensures that computed fields are no longer discarded automatically, while still respecting Drupal’s intent around the internal flag.

Good find!!

So do all computed fields from this module show in JSONAPI with this patch?

What's the magic getting needed for?

And also, could you make this a MR please?

Small adjustment to previous patch. Removed parent::_get() in ComutedField.php as it does not exists in FieldConfigBase

I'll create a MR when i'll have time.

This is my first MR so let me know if I need to do something different.

Yeah, you've put your commits and the MR on the wrong branch.

Leave 4.0.x as is.

Put your commits on the feature branch which you've created -- computed_field-3353839/3353839-show-computed-field

Also, a kernel test would be nice!

Hopefully I've done the MR correctly this time.

I don't think I'm the right one to write the test. I don't use this feature and I provided the MR as a low hanging fruit for me to learn how to create MR's and I believe if I post an issue I should at least try to help out in another issue.

I tried to address the review feedback on MR !22 locally.
I’ll push the update to the issue fork if access is available, or open a follow-up MR if needed.

This needs a test before it goes anywhere -- I'm frankly a bit confused by the interplay between plugin / config entity / field definitions.

I tried #22 and my computed fields still didn't show up in JSON:API.

The problem is that JSON:API asks the field definition whether the field is internal. The field definition never asks the plugin, it just uses the core default, and the core default hides all computed fields. So the new flag from #22 never gets checked.

I rerolled #22 and added an isInternal method to the field definition so it asks the plugin. Now computed fields created in the UI show up in JSON:API.

Tested on Drupal 11.3 with 4.0.0.

Tested the patch from #23 (3353839-23.patch) on Drupal 11.x, PHP 8.3. Without it, isInternal() always returns TRUE because the field definition never asks the plugin — so JSON:API strips every computed field no matter what the plugin actually wants. With it applied, isInternal() follows the plugin's internal attribute like it should, and the field shows up in JSON:API.

@joachim asked for tests above, so here's one: 3353839-24.patch adds a ComputedFieldInternalKernelTest covering both cases — a plugin that doesn't mark itself internal, and one that does. Checked it fails without #23's patch and passes with it.

One more thing: MR !22's branch has actually regressed since this was last tested. The "Remove fallback value" commit deleted ComputedField::isInternal() entirely instead of just trimming it, so it's back to the same bug. It still needs at least return $this->getFieldValuePlugin()->isInternal();.