Only works for nodes, not taxonomy terms?

Some extra info: I enabled domain access for taxonomy terms through the module "Domain Access Entity" (domain_entity).

The domain data is saved in a field named "domain_access" (not "field_domain_access").

Suggested some changes in the issue fork to make the module: A) also check field "domain_access" and B) work for taxonomy terms by also checking for taxonomy terms in the "domain_unique_path_alias_entity_presave" hook.

I think this issue is definitely an important one, but the scope still seems too small.
I wonder why it should be limited to nodes and taxonomy terms at all, all content entities should be valid here.

I'll see if I can cough up a solution for that.

I had to open a new branch because the existing one (1.x) created issues for me locally, due to it having the same name as the main module's git branch.

This attempts to make the functionality as 'global' as possible, by retrieving most stuff dynamically.
Please take a look and feel free to test it.

There is an edge case where this could "not work", which is when the route parameter in `entity.[entity_type].canonical` is not the same as the entity type machine name... But I can't think of a single instance where that would be the case.

Hoo wee.. Something seems very wrong with this merge request, it targets the initial fork branch rather than the module's branch 🤦🏻‍♂️

randalv → closed merge request !16

Welp.. Sadly I have no idea how to fix that mess.

Instead, here's the patch as a file.

A small fix applied to new entities being saved, they shouldn't be processed in that presave hook.

A small fix in this patch: when checking whether the alias is unique, two faults were present in the code.

1. The REQUEST domain was used, not the ENTITY domain, this meant that with entity saves via CLI (e.g. drush), the domain context was always the main domain... So aliases for other domains were saved with `-0` or `-1`
2. When checking if the alias is reserved, the source was not given, meaning if the alias previously existed in the database with the current source then it's marked as 'reserved' even though it's not.

This latest patch solves all of that.