Replies: 6 comments 10 replies
-
|
Wow! It would be great to be able to give a language-based redirect! Most of the URLs I currently have active lead to pages and downloads on multilingual sites, if you implement the language-based redirect I will finally be able to switch to Shlink and transfer all the existing URLs too! (I'm already using a non-open source system with redirects based on language and other conditions, but would like to go open source with Shlink) |
Beta Was this translation helpful? Give feedback.
-
|
Can I ask what service are you currently using? I would like to see how others solve this problem. |
Beta Was this translation helpful? Give feedback.
-
|
Certain! I happily use openmylink.io, using only language-based redirection individually. I also use Short.io with satisfaction, which allows redirects with multiple conditions, but I use the free version and I have no possibility of testing multiple conditions. |
Beta Was this translation helpful? Give feedback.
-
|
So I guess I will have to add support to import links from those services into Shlink 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Don't worry, I only have a few (but important) links that use language-based redirection: I'll do everything by hand, the important thing is that I can already configure the links before moving the domain pointing. 😁 Instead I have lots of links on Short.io, but unfortunately using the main domain shortcm.li, which I don't think I can move: I will have to reprint all the material little by little. 😭 They are both great services. |
Beta Was this translation helpful? Give feedback.
-
|
Just FYI, language-based redirects will be finally included with the overall rule-based functionality in Shlink 4.0.0. See this comment for more context. |
Beta Was this translation helpful? Give feedback.
-
|
No update regarding Dynamic rule-based redirects? |
Beta Was this translation helpful? Give feedback.
-
|
It will still take time, as it requires deep changes. I created this RFC mostly to gather feedback and describe how I would picture it at a high level. These are some related issues, in case you want to watch them. On top of the relative complexity, I'm currently focused on finishing shlink-web-client 4.0, and I won't start working on Shlink 4.0 until that's shipped. |
Beta Was this translation helpful? Give feedback.
-
|
I personally do not have a need for this feature, but I can absolutely appreciate the difficulty in some of the challenges you've listed. In particular with trying to create a good API to represent the rules. I work with other unrelated software which has a rule engine, and they do not let us configure rules via API but can only see a basic summary of them via Perhaps consider this? At least initially, and add I suggest this to help lower the barrier for the initial release of the feature. Food for thought. Not perfect, but I'd say a good API for rule management is probably the hardest one in the list. |
Beta Was this translation helpful? Give feedback.
-
|
I actually didn't think this would need to be supported by the CLI 😅 Regarding the API contract/endpoints, I also thought it might be reasonable to just expose GET and POST endpoints, and enforce all rules to be saved at once. That way there's no need for DELETE or PATCH endpoints, at least for now. |
Beta Was this translation helpful? Give feedback.
-
|
I have finally decided to include rules for language-based and query-param-based redirects in the initial implementation included with Shlink 4.0.0. The initial plan was to leave those for v4.1.0 The reason is that some specific rule is needed to properly test that the overall logic works as expected and performs well. Also, once all the common logic to handle rules, conditions, etc. has been centralized, then the specific part for those two is surprisingly simple. |
Beta Was this translation helpful? Give feedback.
-
|
WOW! I can't wait to test it! 😍 |
Beta Was this translation helpful? Give feedback.
-
Yes, that's correct. |
Beta Was this translation helpful? Give feedback.
-
|
The feature is mostly implemented, with initial support for language, query param and device type conditions. Only a few details are missing, some benchmarking and finalizing the CLI interface is left. The UI is also pending, but that's not part of Shlink per se. Also, I finally decided to not keep backwards compatibility with device long urls, as it added a ton of complexity, and considering this goes in a new major version anyway, it was the time to change it. Thanks to everyone who provided feedback. |
Beta Was this translation helpful? Give feedback.
-
|
The feature was released yesterday with Shlink 4.0.0, and it is also now documented in the website https://shlink.io/documentation/advanced/dynamic-rule-based-redirects-system/ |
Beta Was this translation helpful? Give feedback.
-
|
WOW! |
Beta Was this translation helpful? Give feedback.
-
I have been lately thinking on implementing an advanced system of rules to redirect visitors to different URLs based on a matching combination of conditions and a priority.
This would allow to add more dynamic redirects other than device redirects, with a way to handle condition conflicts and be able to predict where specific users will end-up being redirected.
This would work in combination with the required default long URL, which would always work as the redirect fallback for any users where no rules can be matched.
Context
Historically, Shlink has only allowed every short URL to match a single long URL.
Some time ago, the first rule to dynamically redirect to different long URLs was introduced via device-specific redirects, where you could define Android users to be redirected to a different place than iOS users.
This opened the door to new feature requests to support a similar thing for different languages, different locations, etc.
Problem to solve
The main problem is that this would introduce a lot of complexity, and would require deciding what's the precedence of those rules.
For example, if an Android user whose system language is French visits a short URL which has a long URL for Android and another for French, which one has more precedence?
Because of that I have been more or less pushing back on those requests, but there's perhaps a way to redesign the whole system in a way that can be extended with more rules without breaking existing instances and in a predictable and flexible enough way.
Proposed solution
The solution I'm thinking of is one in which certain rules are supported. These rules represent conditions that can only be checked at runtime, and every Shlink version will have a fixed set of supported rules.
Some examples could be:
Accept-Languageheader).User-Agentheader).When creating/editing a short URL, you would have to provide the default long URL, plus any number of URLs for any combination of rules.
It would also be required to define the priority for a combination of rules, so that in case of conflicting rules, Shlink knows which one to apply.
If none of the rules can be matched for a visitor, they would be redirected to the default long URL (which is Shlink's default behavior since forever).
This could allow a user to define a short URL which has these redirects:
At runtime, Shlink would check these rules and redirect to the long URL for the matching one.
Challenges
Of course this is a relatively complex feature, and comes with a number of challenges to be solved. Some of them would be:
Beta Was this translation helpful? Give feedback.
All reactions