Open joelmandell opened 1 year ago
Hi there @joelmandell!
Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.
We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.
We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.
Thanks, from your friendly Umbraco GitHub bot :robot: :slightly_smiling_face:
Hi @joelmandell,
Thank you for reporting this. And not least for the PR 🚀
I can confirm that this is indeed an issue. The problem "only" occurs when working with relative culture/hostname bindings, i.e. a setup like this:
The URL finder assumes that the short URL is always at the root (i.e. //mydomain.somewhere/short-url
), while really it is //mydomain.somewhere/en/short-url
.
Interestingly, the URLs listed under "Info" do contain the correctly calculated short URL:
This is expected behavior unfortunately. When umbracoUrlAlias
was made we were a decade out from having any kind of culture varying like we have today. So this URL has always been meant as: redirect to exactly this URL.
So now, this is a "feature" - changing this behavior will break existing sites that expect this behavior.
So if a change is desired then it should be done in a major version with a proper heads up.
Instead, I would recommend custom code (which would also make it a proper 301 redirect instead of a 302, if you desire that behavior, in general it's not a great idea to have the same content on 2 URLs unless you then also add a canonical URL in your frontend output to please the search engine robots).
As noted on the related PR, we can't change the current behavior of umbracoUrlAlias
, but it would definitely be a great idea to fix the URL displayed under "Info" as @kjac points out.
Additionally, it could be cool to have a datatype that will actually prefix the /en/
part if the ascendants have something like that set up. Maybe the editor can still decided to delete /en/
and put make an alias to the root of the site, maybe they're not allowed to delete it, maybe that could be configurable.
My personal wish for the 4 aliases (https://docs.umbraco.com/umbraco-cms/reference/routing/routing-properties#umbracourlalias) would be to at some point deprecate them and make new ones that are more sensible, probably combined with a proper property editor that will also let the editor know what they're doing ("you're making a permanent redirect from this page, to page/URL xyz".. etc.). That is a bigger feature request that should be discussed and I'm sure we'll then have to talk about the redirect manager again as well.
Anyway, for now, I'll put a specific bug fix here up for grabs to fix the URL displayed on the Info
tab which the wrong URL.
Hi @joelmandell,
We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.
For more information about issues and states, have a look at this blog post.
Thanks muchly, from your friendly Umbraco GitHub bot :-)
@nul800sebastiaan This is bad.... only next major version? We really need this in U12+ :(
@Jalinco1 I am not sure what exactly you need but there are workarounds, I think you'd want to do some custom routing for your specific use case(s). https://docs.umbraco.com/umbraco-cms/implementation/custom-routing
Make sure to get additional help for that on the forum (https://our.umbraco.com) or on our Discord server (https://discord.umbraco.com) in the #help-with-umbraco
channel.
@Jalinco1 I am not sure what exactly you need but there are workarounds, I think you'd want to do some custom routing for your specific use case(s). https://docs.umbraco.com/umbraco-cms/implementation/custom-routing
Make sure to get additional help for that on the forum (https://our.umbraco.com) or on our Discord server (https://discord.umbraco.com) in the
#help-with-umbraco
channel
@nul800sebastiaan
We have several sites using Uskinned sitebuilder where the news section use "umbracoUrlAlias" to create shorter urls for each news created in the system. Also, our news listing pages uses the "short" urls and each news have a "canonical" with the correct news url for SEO. These sites now can't be multilingual (as expected) because the "umbracoUrlAlias" dont have the expected. behavior on multilingual sites. I found several issue posts about this problem here, so I wonder why it can't be fixed, WITHOUT changing the expected behavior for the field? This has not been working in versions 9, 10, 11 and 12.
I don't know how uSkinned have set it up. You're correct, this has not been working in any version, even 8 so it is now expected behavior. If we change it now, people's redirects will behave differently and their SEO will be impacted, which is something that people get very upset about.
Workarounds have always been available and we recommend those. They also provide you a way to do exactly what you need instead of relying on our behavior which is not great for SEO either since it is a 302 redirect instead of a 301 redirect. So even if it did work correctly in multilingual sites, you will still get an SEO hit from it being a temporary redirect.
@nul800sebastiaan its not a problem for SEO if done correct with "canonical" tag as far as I know. Can we expect this bug to be fixed in Umbraco 13 then?
Reopening issue to keep the "Future WIshes" of @nul800sebastiaan listed 😉
Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)
10.2.1 and above
Bug summary
Seems to happen in both 10.x and above, have not tried it out on version 9.x...
When using the umbracoUrlAlias-prop on other culture then on the default, the ContentFinderByUrlAlias class cannot find it because it is not matching with the domain for the culture. I have prepared an PR that fixes this issue. Feedback is appreciated.
Specifics
No response
Steps to reproduce
Imagine you have DocumentType with an Texstring property with alias umbracoUrlAlias. The document type is allowed to vary by culture. You have two cultures, english and danish. English is the default culture. You publish content in english (which is default-lang) for an campaign-page, and have an shorturl set as value for the umbracoUrlAlias. You name it blackfriday2023. The link that is generated is /blackfriday2023. You can browse to that without issues.
Now you publish content for that campaign but in danish. The value is also blackfriday2023 and generated link is based on domain setting: /da/blackfriday2023. But when you browse to that page it is a 404.
Expected result / actual result
It is expected that user should land on the content for that culture when browsing to that umbracoUrlAlias.