JSON:API error for localgov_review_date field

[Polynya]

When trying to use Entity Share, I hit this error:

_Symfony\Component\HttpKernel\Exception\UnprocessableEntityHttpException: The attribute localgov_review_date does not exist on the node--localgov_guidespage resource type. in Drupal\jsonapi\Normalizer\ContentEntityDenormalizer->prepareInput() (line 65 of /var/www/html/web/core/modules/jsonapi/src/Normalizer/ContentEntityDenormalizer.php).

The error is caused by localgov_review_date being missing from EntityFieldManager->getFieldMap(), which I think this is due to it being added using hook_entity_bundle_field_info()

I'm not sure what the best solution is. We could use bundle classes but that could mean coordinating changes across the LGD modules to add a class for each content type.

If helpful, I can post a PR for my workaround which uses hook_entity_base_field_info() instead. This adds the field to all bundles so I hide it on non-scheduled bundles with a form alter.

If this issue hasn't been seen before then I assume:

1. Cumbria didn't have LocalGov Review Date enabled https://cumbria.localgov.blog/2022/05/31/using-entity-share-with-localgov-drupal/
2. No one has used JSON:API for anything similar

[finnlewis]

@nccchris had this issue and hacked around it by changing the JSON API normaliser, if hitting this field type, continue and don't try to process it.

@Polynya has tried changing hook_entity_bundle_field_info to hook_entity_base_field_info, which has some possible side effects.

Is it possible that JSON API does not invoke the hook_entity_bundle_field_info when serving up the definitions in entity share?

This post might be relevant https://www.previousnext.com.au/blog/how-create-and-expose-computed-properties-rest-api-drupal-8

[finnlewis]

@stephen-cox suggests that if there is a better way to ignore this field for JSON API / Entity Share use case, we should explore that.

[finnlewis]

This sounds related, linked to from the Previous Next post :https://www.drupal.org/project/drupal/issues/2346347

[ekes]

It does rather sound like that core issue is at the heart of it.

One way round would be to make this a computed base field and exclude it somehow from appearing on bundles that it is not enabled on.

The other, the workaround mentioned by previous next, and also referenced by commerce is https://www.drupal.org/project/drupal/issues/2346347#comment-12205206

<?php

// my_module/src/FieldStorageDefinition.php

namespace Drupal\my_module;

use Drupal\Core\Field\BaseFieldDefinition;

/**
 * A custom field storage definition class.
 *
 * For convenience we extend from BaseFieldDefinition although this should not
 * implement FieldDefinitionInterface.
 *
 * @todo Provide and make use of a proper FieldStorageDefinition class instead:
 *   https://www.drupal.org/node/2280639.
 */
class FieldStorageDefinition extends BaseFieldDefinition {

  /**
   * {@inheritdoc}
   */
  public function isBaseField() {
    return FALSE;
  }

}

and

class BundleFieldDefinition extends BaseFieldDefinition {

  /**
   * {@inheritdoc}
   */
  public function isBaseField() {
    return FALSE;
  }

}

• don't know if it'll work for our issues, but let's see.

[Polynya]

81

[ekes]

81

Should be tested against the issue https://github.com/localgovdrupal/localgov_workflows/issues/80 too. Which requires making a site have multiple languages, add content translation, and then on that admin page selecting all fields for content types such that the review date field is set to translation (might require submitting the form a few times). The other option mentioned above (isBaseField() FALSE) does not work for the translation issue as far as I can tell.

[Polynya]

I think #81 fixes issue #80. Affter saving the translation form, the checkboxes for review date fields are always unchecked. However, I have created a translation of a guide page and set a different review date.