Add normalization support for metatag module

Thanks for reporting this, this confirms #2901253: Add normalization support for metatag module.

Gah, I meant #2860350: Document why JSON API only supports @DataType-level normalizers of course. c/p fail, sorry.

As the lead maintainer of Metatag, I am interested in helping to resolve the problem but have no understanding of the best way to help fix it; if it'll take changes to the Metatag module that's a-ok with me :)

Once that is complete the metatag module will need to determine how its format agnostic normalizer Drupal\metatag\Normalizer\MetatagNormalizer will work with jsonapi.

I'm not sure I understand how a normalizer can be format agnostic. A normalizer is inseparable of a format. You normalize to a format.

I'm pretty sure that if a normalizer decides to take precedence and respond to the reserved api_json format, then it should play by the rules in the JSON API module. This is because it will need to be put in a JSON API document output, and it needs to be valid JSON API format and follow the module expectations.

Thanks for reporting this, this confirms […]

Can you elaborate on that? From my point of view these two issues are not related. This one is caused by a normalizer from a separate contrib with high precedence acting on the api_json format. The other one is JSON API not picking up automatically the new core's normalizer.

The Drupal\metatag\Normalizer\MetatagNormalizer class doesn't declare protected $format = ['the_target_format']; like other classes do, such as Drupal\metatag\Normalizer\MetatagHalNormalizer.

That is the core of the problem. A normalizer changes the shape of data into a given format. Therefore Drupal\metatag\Normalizer\MetatagHalNormalizer should not be greedy and should not respond TRUE in supportsNormalization when the $format provided in that call is set to 'api_json'.

The Drupal\metatag\Normalizer\MetatagNormalizer class doesn't declare protected $format = ['the_target_format']; like other classes do, such as Drupal\metatag\Normalizer\MetatagHalNormalizer.

That's really how core is setup, look at any normalizer in the core's serialization module. It's as if `json` is the default. It's how it is and it's not bad per se.. so there's really not an agnostic normalizer but rather a default, and that's always 'json'.

Therefore Drupal\metatag\Normalizer\MetatagHalNormalizer should not be greedy and should not respond TRUE in supportsNormalization when the $format provided in that call is set to 'api_json'.

It's not MetatagHalNormalizer that's being greedy. What's happening is that there's also the regular Drupal\metatag\Normalizer\MetatagNormalizer which defaults to TRUE if no format is set to the normalizer, but that's only because it's based on Drupal\serialization\Normalizer (core). Which is the case in most core's normalizers.

See:

  /**
   * Checks if the provided format is supported by this normalizer.
   *
   * @param string $format
   *   The format to check.
   *
   * @return bool
   *   TRUE if the format is supported, FALSE otherwise. If no format is
   *   specified this will return TRUE.
   */
  protected function checkFormat($format = NULL) {
    if (!isset($format) || !isset($this->format)) {
      return TRUE;
    }

    return in_array($format, (array) $this->format);
  }

i.e. $this->format is not set.

I am not sure again what's the proper fix here. Also I haven't reviewed the fixes and comments on the mentioned core issue to assess if that will really fix the problem.

#6 + #8 + #9 + #10 are duplicating the discussion at #2860350-19: Document why JSON API only supports @DataType-level normalizers through #2860350-23: Document why JSON API only supports @DataType-level normalizers. It's really the same problem. Let's all discuss it there, so we don't have a fragmented discussion.