[Core] Allow multiple aliases for a single entry

[laurenskling]

Feature request

Summary

I would like to be able to add multiple aliases for a single entry.

Why is it needed?

My use case is a followed: I have vehicles in my Strapi. These vehicles are sold in multiple ways: direct buy, leasing, b2b wholesale. So I create multiple (different layout) pages from the same vehicle entry. I have a relation on the vehicle, in which sales they should exist. So let's say that is a relation called sales. I would like my url_aliases be an array for each sales: ${sales.slug}/${vehicle.slug}. This way I can let different URL's end up at this vehicle. Next step for me would be to read sales.slug in the URL to render the correct page, but that's up the me at the frontend.

Suggested solution(s)

url_alias should become a oneToMany and lots of other magic :)
I wonder if this would break the GET http://localhost:1337/api/webtools/url-alias output. It shouldn't..

Related issue(s)/PR(s)

In some way, this is related to allowing redirect URLs: #28
That would mean aliases should be able to be marked as a primary destination or a redirect.

[boazpoolman]

Hi @laurenskling,

Thanks for the feature request, it is a big one.
The groundwork for this has been laid (url_alias is a oneToMany relation), but it is by no means stable.

For this to properly work we need to connect the alias to the pattern. Because once you have multiple aliases for a single document, you need to know which pattern was used to generate the specific alias. That way if the aliases need to be updated you know which one.

Also something that needs to be orchestrated is a way for you to specify the primary URL alias. Say you want to link from one page to the other, which alias will you use?

[laurenskling]

Yeah this would need some good planning..

Wouldn't a simple delete all / create all be enough? If the aliases are auto generate, it doesn't need specific updates right? You can just re-eval the settings. And with manual alias, no changes are needed anyway.

I guess we would need some sort of priority setting; which orders the list correctly. The first one could always be the primary to link to. But Redirects you would never want to link to. So redirects would b a different type of alias..
If there is only one pattern, that creates multiples aliases because of a relation inside of the pattern, the order of the relation should determine the order of the aliases. Thats another question I guess, are we talking about multiple patterns, or about a single pattern that could create multiple links because of it's relations?

[boazpoolman]

Wouldn't a simple delete all / create all be enough? If the aliases are auto generate, it doesn't need specific updates right? You can just re-eval the settings. And with manual alias, no changes are needed anyway.

Well.. Imagine a scenario where content type has two pattern and we have one of it's documents that has two url aliases. One auto-generated, one overwritten not auto-generated. You then want to bulk generate all the auto-generated URL aliases. Which of the two patterns do you use to generate that single alias?

Thats another question I guess, are we talking about multiple patterns, or about a single pattern that could create multiple links because of it's relations?

How I imagined this to work is what I illustrated above, one pattern makes one alias. So if you want multiple aliases you create multiple patterns.

[laurenskling]

Ah yeah, my mind was somewhere else. I was thinking of creating multiple aliases from a single pattern, because the pattern includes a relation. Looping over all related sales for the vehicle. Creating as many aliases as there are sales relations. This is different from creating multiple patterns.

[boazpoolman]

Ah, that's an interesting use case. We should take this in to account during the design phase of the feature. But yeah, I guess in that case you would want all the aliases to be auto-generated, and prevent a user from setting auto-generated to false.

[laurenskling]

Why would that conflict? Auto-generated false documents would just skip generation when triggered, right?

[boazpoolman]

I think we need to draw this out for it to be clear. Let me make a proposal and if you want we can discuss options.