Link enhancer to add Aliased URL for internal links

Very usefull, i'm testing the patch.

Looking at the code i just found this

+++ b/src/Plugin/jsonapi/FieldEnhancer/AliasedLinkEnhancer.php
@@ -0,0 +1,99 @@
+      preg_match("/entity:(.*)\/(.*)/", $value['uri'], $parsed_uri);

Could we use something like Url::fromUri? It return an Url object that already have a method to check if it is external or internal.

I've tested the patch creating a menu with links to several internal and external link.

As it is done now it works just if `entity` is matched in the preg_match, it doesn't works for example for path like internal:/de/group/123.

Attached a patch that works for all the internal and external uri.

The code of UuidLinkEnancher and AliasedLInkEnancher seems very similar.

I'm new to this module and found usefull having the url other than an uri.

Maybe is better make more generic UuidLinkEnancher and add there the url provided by this patch?

This looks good.

Two suggestions:

1. Just like @ziomizar suggests in #8, we should strive for code reuse.
2. We should add a test for this. You can adapt the existing test for the UuidLinkEnancher.

Thanks a lot for your contributions!

Just like @ziomizar suggests in #8, we should strive for code reuse.

Dito. Seems like we could either simply extend UuidLinkEnancher and override 2 methods or generalize that class if that is feasible instead of adding duplicated code to the module.

I've re-rolled the patch to integrate this functionality in the UuidLinkEnhancer.

This reduce the amount of code to 2 lines of code and also group together uri and url in the same enhancer.
I've adapted also the tests for UuidLinkEnhancer to test the alias.

This feature is exactly what my project is in need of. What, for the time being is the recommended workaround until a solid solution is decided on?

An entity can be made into a URL in different ways (by passing the $rel parameter). This solution only takes into account the 'canonical'.

Maybe this should be a completely separated enhancer that applies to links and turns them into links to entities (or leaves them untouched if they aren't entities). This enhancer could then have a different property for different $rel.

Thoughts?

@e0ipso looking better at the documentation seems that url() and toUrl() will be deprecated and the suggested solution is to create a \Drupal\Core\Url object directly.

If we create 2 separated enhancers we have:
1. An enancher that return a more complete output with more properties from the url object like: external, absolute, alias, uri, ecc..
2. Another enancher that return just uri.
That means that with the enancher (1) we can also cover the functionalities of the enancher (2).

Wouldn't be better having just one that is used to enanche all the Urls? Maybe i'm missing the biggest advantage or difference of having this separated.

Hey, I know this is still in the works, but what would you suggest as a workaround?

Also interested in this. Currently having URIs isn't as useful as URLs could be. @TikaL13 - I'm intending to postprocess the data consumed by my client app. Not ideal, but I'm not sure what else can be done?

This patch adds a URL field enhancer that extends the UUID enhancer and simply adds the url string to the array, like the original post is looking for.

Re-roll of #11. Sorry for taking so long to get on board.

I'm taking a different swing at this. I'm adding a new link enhancer to convert internal and entity urls to their alias.

Editors can add links as external, internal, or entity reference. This field enhancer normalizes the output to an absolute or relative url.

Is there guidance from jsonapi or some standard on how links ought to be formatted?

@mortona2k,

Good idea, I've made a small adjustment to your patch. It's a small check eliminating 500 error, when referenced entity no longer exists.

Thanks for the patch! Some comments.

1. +++ b/src/Plugin/jsonapi/FieldEnhancer/UrlLinkEnhancer.php
   @@ -0,0 +1,100 @@
   +      preg_match("/internal:(.*)/", $data['uri'], $parsed_uri);
   ...
   +      preg_match("/entity:(.*)\/(.*)/", $data['uri'], $parsed_uri);
   

   Instead of doing string matches, let's do try {} catch () {}

2. +++ b/src/Plugin/jsonapi/FieldEnhancer/UrlLinkEnhancer.php
   @@ -0,0 +1,100 @@
   +  protected function doTransform($value, Context $context) {
   +  }
   

   Why is this empty?

3. +++ b/src/Plugin/jsonapi/FieldEnhancer/UrlLinkEnhancer.php
   @@ -0,0 +1,100 @@
   +    return [
   +      'type' => 'object',
   +    ];
   

   Any chance we can see the properties in the schema? This schema as-is is not very helpful.

Thanks for the patch! Is this supposed to work with /jsonapi/menu_link_content?

Hi! Any chance that this patch or the code by Ambidex https://www.drupal.org/project/jsonapi_extras/issues/3047044#comment-130... can find its way into the module? They are pretty handy to avoid another call to the API to resolve an alias and worth inclusion IMHO.

If you are interested in sponsoring a feature contact the JSON:API Extras module maintainer. Open Source maintainers are very busy with additional professional and family obligations. Sponsoring will ensure priority in fixing this particular issue.

@druellan this has been blocked for a long time ago on the feedback provided on #26. I'll be happy to review new patches that address those concerns. I agree with you, this would be a pretty important feature.

Thanks @e0ipso. If the author is not around anymore, I'll try and provide a new patch.
In the meantime, I can point out that he worked over UuidLinkEnhancer.php, and except doTransform being empty, the rest of the code is the same with very small changes, so, probably that is the only real concern.

Thanks again for your work.

Applied patch https://www.drupal.org/files/issues/2019-03-08/jsonapi_extras-Field-enha... on 8.x-3.13.

Expected to see the alias exposed via JSON API, but it does not appear.

Is the latest patch supposed to work at the moment?

@e0ipso I like your idea of getting way from preg_match.

I updated the patch to use Drupal's Url class to generate the url.

I also updated the output to be

field_link: {
  uri: "entity:node/21",
  title: "test",
  options: [ ],
  url: "/about-us"
},

I think it is okay that the doTransform function is left empty. I think Link fields should accept all URLs anyways.

At this point, only fuzzy type checking for arrays/objects are being validated.
(\Drupal\jsonapi_extras\Plugin\ResourceFieldEnhancerBase::getOutputValidator uses CHECK_MODE_TYPE_CAST)

But I did update the schema for documentation purposes.

I added the option to always generate Absolute URLs. It is turned off by default.
Also removed unused dependency injection code.

Are this not duplicated issues?

@weri, it seems like they are duplicates, solved in two different ways.
Thanks for pointing it out!

I think the solution in the referenced issue is a more plausible approach than this one. That patch is working for me.

Shall we mark this as a duplicate?

I checked the code and it seems fine for sites with single language. However it won't be working correctly with multiple languages, because you can have different alias per translation. It should be mentioned somewhere or there should be some way to determine if enhancer can be used for this specific field instance.

Hello, reporting that the patch on comment #33 worked well for me in achieving my desired output of path aliases for menu links, but only after I modified the output JSON schema as it was throwing validation errors. Simply removing the 'properties' object allowed it to pass validation.

I was already using the previous patch, hence the addition on this ticket, and not the kind of duplicate one.

I also found out that the translations did not work as intended.
The code in #33 works for single language sites, but when using this on multi language sites, it returns the url in the default language.

I added that when the url is requested, the current language is added.
I suppose this is without dependency injection, as @jonnyeom removed all others, let me know if the language manager should be added using injection or not.

Used #38 patch, added dependency injections and minor code style fixes.

looks good

Awesome everyone, will merge this and release a new version soon :)