🇳🇱Netherlands @pgrond

pefferen → credited pgrond → .

The answer of @frob is spot on. I will mark this issue as resolved.

Made a issue fork and pushed the patch with @WimLeers issues applied, except for the logic of getCancelUrl(). Didn't had time to test that, and why we need an override in the first place.

This could use some tests though..

pgrond → made their first commit to this issue’s fork.

I've added a fix that clears the entity cache on deletion of an external entity type.

I think the underlying problem is fixed by https://www.drupal.org/project/external_entities/issues/3270683 →

This will be fixed when https://www.drupal.org/project/external_entities/issues/3337903 ✨ Make external entities language aware Fixed is committed.

@gugulamaciek This works great and fixes the issue with multilingual listings https://www.drupal.org/project/external_entities/issues/3249146 🐛 Links in listing do not respect language of external entity Postponed

The only thing that botters me is that we get 3 extra fields in the mapping:

• Language code
• Language object
• Default translation

I think we only need Language code, and maybe default translation, although I don't see the use case right now. I think we should hide these fields from the user, maybe with a hook_form_alter?

The patch does not apply anymore to the latest version.

pgrond → made their first commit to this issue’s fork.

pgrond → created an issue.

I've tested removing an exported config for an external entity type and reimported the config. The external entity type is removed correctly. It is not needed to write a hook for deletion of config entities. #3034742 is about updating entity types, not deleting theme.

I will mark this issue as "works as designed" and open a new bug for the plugin cache issue.

I don't think the yml of the external entity needs the dependencies, but the specific yml of the field, i.e. field.field.external_type.external_type.field_name.yml

When I look to how core this does, fields on a content type have a dependency on the content type config.

Possible solution https://www.drupal.org/project/external_entities/issues/3337903 ✨ Make external entities language aware Fixed

It looks like the plugin cache doesn't get cleared.

I agree that the specific storage client should be responsible for how to decode the repsonse. So I'm in favour of moving it out of the base class and move it to the specific implementation.

Is this still an issue? I see that after some refactoring ->getType() is not called anymore in mapFromRawStorageData().

Can you check if this still is relevant?

Added a simple Kernel test for this.

Looks fine, merged.