Custom field: Link

[boazpoolman]

Feature request

Summary

As of now custom fields are still in Alpha, though when the custom fields are stable I think this plugin could benefit from registering one of it's own custom field types: Link.

Why is it needed?

This plugin effectively attaches a URL to a record in Strapi. So when you want to link from one page to another, you're gonna be looking at the URL path to link to. Having said that it makes sense to have a "Link" custom field type that is a reference to a specific URL path record. This field can for example be used as a button field to link to another page.

Having it set up this way when you start changing URLs the links keep working, as it is still a reference to the same URL path record that belongs to a specific page.

Suggested solution(s)

A custom field type named "Link" which is a reference to a URL path.

[Alexnortung]

I would really like this feature too, but how do you think this could be implemented. The current state of custom fields does not allow for usage with relations.

I think this could be solved by just saving the id of the url alias as a number, but this gives another problem, when fetching the entity which uses the custom field, you would also need to fetch the actual url alias by id. Else it should somehow be automatically populated, but I am not really sure how this would work.

What do you think?

[boazpoolman]

I've thought about this before, and think I have a decent solution. Curious what you think about it.

Proposal We register a custom field of type string. This field should allow "hard coded" links as it's value, simply storing a string like https://strapi.io. Also it should allow a value which establishes a relation to the URL alias.

I suggest we introduce a specific string format to establish this relation. The field value would be something like wt-link://3 where 3 would be the ID of the specific URL alias.

In the admin panel, the custom field will act as an autocomplete. Allowing you to select an URL alias by referencing it's corresponding content entry. If an entry is referenced, the field should save it's value in the wt-link:// format. If no entry is referenced the field should just save the value that was typed into the input field.

On the API side we can use an entity service decorator to rewrite the wt-link:// value to be the url_path of the corresponding URL alias.

Downside This would mean that we will have to rewrite any find query recursively to alter the field value. Performance wise this is not ideal and frankly bittersweet, as we've just moved away from this approach for URL aliases by using native relations.

On the contrary I think we can't get around this with the current custom relations field restriction. And also allowing both URL alias relations and just hard-coded URLs is something that wouldn't be able at all with a relation field. So for that feature I really don't see any other way.

@Alexnortung let me know what you think.

[Alexnortung]

I like the idea and I can definitely see that it could work. I have some thoughts that we might need to take into consideration.

We are kind of introducing a new concept of hard coded urls (and external urls) which I think is very nice for this plugin. But I think we should think about storing those as individual entries in the database as well, maybe something similar to wt_url_alias. I think this for two reasons:

1. The custom field can be stored as an integer instead of a string
2. Redirects may also redirect to hard coded paths or external urls However, this may make cleaning up old paths just a bit harder.

In regards to the find decorator, there might be some ways to check it pretty quickly if we already know the possible locations of the link components. We could determine the possible locations of the link components during register or bootstrap and just store it as an object, which can then be used by the decorator.

We should also consider if the links should be populated by default. I think that there are some cases where you don't necessarily need the link, however I am not sure the tradeoff is worth it.