Support entities that are neither content nor config entities

I had the same issue for 9.5.2 drupal and brightcove module. #Patch 50 fixed the issue, thanks!

Thanks @zakiya !

I had facing the same issue for 9.5.1 Drupal and JSON:API module. #Patch 50 is fixed my issue.

My Error is "LogicException: Only content and config entity types are supported. in Drupal\jsonapi\ResourceType\ResourceTypeRepository->getAllFieldNames() (line 340 of /var/www/html/devportal/core/modules/jsonapi/src/ResourceType/ResourceTypeRepository.php)."

Changes that I have made:

* Created an initial CR draft for this change: #3343351
* Rerolled #50 because it did not apply on Drupal core 10.1.x
* Correct deprecation messages in #50

@thursday_bw I have also experienced the issue that you have mentioned in #59 but only on Drupal 9.4.x. This is a pretty weird one. I did some debugging and I believe this line causes that problem because if I change (correct?) that line to $original = $container->getDefinition($service_id); then the issue disappears. Also, the good new is that this code was removed and deprecated and removed since Drupal 9.5.0, see https://github.com/drupal/core/blob/10.0.3/lib/Drupal/Core/DependencyInj... and #2531564: Fix leaky and brittle container serialization solution → .

I am not sure why I did not expect changes in JSONAPI around content entity normalization since 2019...

9.4.x failures are just deprecations, so they are fine.

  128x: The "serializer.normalizer.content_entity.jsonapi" service is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. You should use the 'serializer.normalizer.fieldable_entity.jsonapi' service instead.
    128x in HelpTopicsSyntaxTest::testHelpTopics from Drupal\Tests\help_topics\Functional

So it turned out that what I was suggested to @thursday_bw in #63 was not a solution, just silenced the problem. With that fix serializer.normalizer.content_entity.jsonapi was not registered therefore field enhancers provided by JSONAPI Extras did not work when an input needed to be transformed. (They worked when the output needed to be un-transformed.)

Something weird is going on with the service container in Drupal 9.4 (and most probably 9.5 and above), or just the way how JSONAPI registers and collects normalizers conflicts with the service deprecation with service alias approach. After changed my code like below, everything started to work again and DependencySerializationTraitPass did not what to be tweaked.

   serializer.normalizer.content_entity.jsonapi:
-    alias: serializer.normalizer.fieldable_entity.jsonapi
-    deprecated: The "%alias_id%" service is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. You should use the 'serializer.normalizer.fieldable_entity.jsonapi' service instead.
+    class: Drupal\jsonapi\Normalizer\FieldableEntityDenormalizer
+    arguments: ['@entity_type.manager', '@entity_field.manager', '@plugin.manager.field.field_type']
+    deprecated: The "%service_id%" service is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. You should use the 'serializer.normalizer.fieldable_entity.jsonapi' service instead.
+    tags:
+      - { name: jsonapi_normalizer }

:fingers-crossed:

Okay, I have no idea currently how to deprecate a normalizer without using service aliases and not triggering deprecation errors...
But that just blocking the merge of this change, just as test coverage, which requires more work than I have expected because fundamentals are still missing in core for building entities that are not content entities or config. (I guess a "skeleton" fieldable entity implementation cannot be accepted, it must be functioning... does it? :thinking-face:)

Back to using an MR... I am tired of generating interdiffs :)

I hope this is a good enough approach to consider that this change is covered by tests without spending more time to get this fix merged.

The last submitted patch, 76: 3042467-MR3548-d63d58cb-without-tests-backport-9.5.x.patch, failed testing. View results →

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Thanks @needs-review-queue-bot, fixed it!

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Surprised the bot hasn't caught this but the MR no longer applies.

What happened again.... :-(

https://github.com/drupal/core/commit/4f183ba36780d1ddbdeca109650ef14ded...
https://github.com/drupal/core/commit/68ef3c4832eb8f257a2eeef1f85a4fe0ba...

Left a review, it needs change message to 10.2 and add deprecation tests

mxr576 → changed the visibility of the branch 3042467-31-deprecated-alias-slug to hidden.

Created a new 10.3.x backport patch from the most recent changes.

Uploading a new 10.3.x backport, because 10.3.4 introduced changes in `core/.deprecation-ignore.txt` (https://git.drupalcode.org/project/drupal/-/commit/83a80f66982d40ea7cb83...) and the patch doesn't apply anymore. I removed all test related changes from the patch, so those won't cause trouble in compatibility.