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

Language variants (v8) through culture and hostnames #17

Open
jessevdp opened this issue Dec 9, 2019 · 7 comments
Open

Language variants (v8) through culture and hostnames #17

jessevdp opened this issue Dec 9, 2019 · 7 comments

Comments

@jessevdp
Copy link

jessevdp commented Dec 9, 2019

Umbraco 8 introduced Language Variants. The "Adding language variants" section in the "Creating basic site" tutorial on Our Umbraco mentions that hostnames configuration is required to output the language variants of a content node (scroll down to "culture and hostnames" which is boldly printed somewhere in the article 😄). Consider the culture and hostnames configuration below.

culture and hostnames configuration

After some (limited) experimentation I've concluded that HeadRest does not take the hostname configuration into account. Attempting to access a content item at an alternative URL results in a 404 error. I've tested both, a config in which the alternative URL has a different language, and a config where the alternative URL is in the same language.

I suppose that making HeadRest work with the hostnames config makes it work with language variants as a result. If not inherently, then I think it should be reasonable to add on top. (Note that I'm not familiar enough with the codebase to know for sure.)

@jessevdp
Copy link
Author

jessevdp commented Dec 9, 2019

What would it take to implement this kind of functionality? What are the roadblocks?

@jessevdp
Copy link
Author

jessevdp commented Dec 9, 2019

Note that #13 suggests manually adding every alternative route to HeadRests mapping. But that doesn't scale...

@mattbrailsford
Copy link
Owner

Ahh, I think I might have identified the need for this in a previous PR on a different subject, but I think the route handler would need updating to handle the "domain" entries https://github.com/mattbrailsford/umbraco-headrest/blob/develop/src/Our.Umbraco.HeadRest/Web/Routing/HeadRestRouteHandler.cs and possibly the URL provider too https://github.com/mattbrailsford/umbraco-headrest/blob/develop/src/Our.Umbraco.HeadRest/Web/Routing/HeadRestUrlProvider.cs

I'd need to look into this to determine exactly what would need to happen, but I don't really have time atm. If someone wants to investigate, I'd happily provide guidance as to whether it sounds like you are on the right path. Otherwise it'll have to wait till I have some time free.

@jessevdp
Copy link
Author

Thanks for the pointer. I'm going to see if I can make some time.

So in the route handler, the path variable contains whatever path is entered after where HeadRest is mounted? Considering a base path of "/api" and a request to http://headrest.local/api/foo/bar it would contain something like: "/foo/bar".

var path = requestContext.RouteData.Values[HeadRest.RoutePathKey].ToString();

The code then moves on to build an xpath based on the path entered and retrieves the node from that path if it exists.

I guess it would be possible to rewrite this method and see if the path matches any of the URLs of any of the content nodes.

That would break the rootNodeXPath option of HeadRest though. So the code would need to keep that in mind. (Maybe just look at content nodes starting from the content node at the root xpath?)

@mattbrailsford
Copy link
Owner

@jessevdp I think so yes.

I think there might be need to look into the core Domain entities where the hostnames are registered and whether we need to do some lookup based on those paths. I seem to remember having to do this for a content finder some time ago, but I can't fully remember what I did. I'll see if I can dig something out later.

@readingdancer
Copy link

@jessevdp I am currently developing VueJS based community site NC COVID Support that I am looking to shortly port across to use Umbraco as it's back end ( the site's data currently comes from a Google spreadsheet via their JSON API )

I was just looking to see if Matt's package would suit our requirements, I noticed this thread about multilingual usage of the API. I wondered if you had managed to make any progress with this?

@mattbrailsford - As always, a great looking package 🥇

Cheers, Chris

@jessevdp
Copy link
Author

jessevdp commented May 6, 2020

As far as I know, no progress. I was hoping to pick this up as part of an internship I was doing at the time. Never got around to it due to time constraints/priorities.

Note that this issue is in regard to Umbraco 8 language variants. You can still achieve an Umbraco 7 like multi-language setup if you like. (Separate content trees.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants