Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent url generation when some of the languages do not have domains set #10827

Closed
lauraneto opened this issue Aug 10, 2021 · 7 comments
Closed
Labels
status/stale Marked as stale due to inactivity type/bug

Comments

@lauraneto
Copy link
Contributor

Which exact Umbraco version are you using? For example: 8.13.1 - don't just write v8

9.0.0-rc001

Bug summary

If I have a multi-lingual website, and I publish a node in multiple languages but only setup the domain for some of them, I get inconsistent behavior when trying to retrieve the url (both in the backoffice and by using .Url(culture)).

This is also reproducible in 8.15.1.

Example:
Languages: en-US (main), nl-NL, pt-PT
Domains: Only /nl - nl-NL is set

image

Root node:

  • Backoffice:
    nl-NL: /nl
    en-US: /nl (but accessible through /)
    pt-PT: This item is not published (but if I do .IsPublished(culture) I get true)
  • .Url(culture):
    nl-NL: /nl
    en-US: /nl (but accessible through /)
    pt-PT: /nl

Child node:

  • Backoffice
    nl-NL: /nl/nl-content
    en-US: This document is published but its URL cannot be routed (but accessible through /content)
    pt-PT: This item is not published (but if I do .IsPublished(culture) I get true)
  • .Url(culture):
    nl-NL: /nl/nl-content
    en-US: /nl/nl-content (but accessible through /content)
    pt-PT: /nl/nl-content

Specifics

No response

Steps to reproduce

  1. Setup the languages in the CMS as follows
    image
  2. Create a root node which varies by culture and setup the following domain.
    image
  3. Publish that node in all 3 languages and check the urls for all 3 (both in the backoffice and through code by using node.Url(culture). You can also try to use node.IsPublished(culture) and check that some that have This item is not published showing in the backoffice, are actually considered published).
    image
  4. Add a child node, which also varies by culture, and also publish it in all the 3 languages and check the urls.

Expected result / actual result

I would expect that if I only have an nl-NL domain setup, that my main language would have url / and not the same url as nl-NL, since it's possible to access it through /.
Regarding the rest of the languages, I'm not sure what the behavior should be but I think that showing This item is not published can be misleading and I would expect to see This document is published but its URL cannot be routed instead.
I would also expect to have a simple way to check if the node in a certain culture is routable or not through code.

@emma-hq
Copy link
Contributor

emma-hq commented Aug 11, 2021

Thanks for reporting @lauraneto!

I've labelled v9 so we can get a look at it

Emma

@bergmania
Copy link
Member

Thanks for reporting @lauraneto!

I've labelled v9 so we can get a look at it

Emma

I unlabeled, when it is also a bug in v8. 🙈

@nul800sebastiaan
Copy link
Member

Thanks @lauraneto for your thorough description. Unfortunately I have nothing great to tell you, this is all "expected behavior".

We can not change the way URLs are generated since any change that we make now will break something for someone who is expecting the current behavior. All we can do is workarounds that you seem to have already found.

Now, I apologize but I didn't read every detail of this issue, but I think the only thing you're currently experiencing that is not to your liking is that / and /nl give you the same page. I'd recommend making a URL redirect to /nl if that is what your requirement for this site is.

Did I miss anything else? When you set up hostnames on the relevant nodes, I think you've found that everything that you need to do works, is that correct?

@patrickdemooij9
Copy link
Contributor

The IsPublished(culture) returning true while the backoffice says otherwise might have something to do with this issue: #10695

And I see it correctly, you want your main language to use / and the nl-nl one to use /nl? Wouldn't adding an domain with value / for en-GB do the trick here?

@vsilvar
Copy link
Contributor

vsilvar commented Aug 12, 2021

@nul800sebastiaan I've tried to address the issue in my PR.

It is of course possible that we are breaking some code built around undefined behavior, but if so, we can try to accommodate it. And I think with the framework change Umbraco 9 would be the release to do it.

I think the PR results in behavior that is much closer to what is expectable.
Please let me know if there's any edge case I'm missing.

@lauraneto
Copy link
Contributor Author

@nul800sebastiaan I think the main issues for me here are:

  • If I don't have a domain set for the culture, .Url just picks a "random" url from another domain.
  • In the child nodes, in the backoffice, I get This item is not published, which is not true. I would expect to see This document is published but its URL cannot be routed instead.
  • There is no easy way for me to check if a node in a specific culture is routable or not, since I always get IsPublished = true and Url set to a value.

@patrickdemooij9 Yes, I know that if I add a domain with value / it works for that one, but I think it's fair to expect that if you don't have to (the UI allows it and it's routable) then it should still work regardless.

The above PR seems to fix the random url behavior and it makes the messages in the backoffice behave as I would expect.
Is there anything preventing it from being merged? Does it break any other behavior that people have come to rely on?

jaddie pushed a commit to jaddie/Umbraco-CMS that referenced this issue Sep 7, 2021
@umbrabot
Copy link

Hiya @lauraneto,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.

For example:

@umbrabot still relevant
This bug can still be reproduced in version x.y.z

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

@umbrabot umbrabot added the status/stale Marked as stale due to inactivity label Mar 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/stale Marked as stale due to inactivity type/bug
Projects
None yet
Development

No branches or pull requests

7 participants