RelativeRoute
Returning 404
Introduction
Recently I used the RelativeRoute attribute on my custom widget controller like I had many times before. But this time the functionality just did not work. I got 404 errors and it only worked if I hard coded the page name into my relative route. To make matters worse when I deployed it to my server it did work. If others got the project and tested it, it failed for them too. If I tested other projects where I used the RelativeRoute attribute they still worked. I racked my brain but really had no explanation.
By all accounts it appeared to be an issue with my project since other projects were fine and the problem traveled with the project to other developer machines. Still, building and deploying it onto the server fixed the problem. So just what sort of crazy was going on here?
My Code
Nothing new here. With this implementation I expect that what ever page this widget is on that if I browser to /my-page then the 'not found' view is displayed. If I browse to /my-page/voyage-name then the voyage will be displayed by looking it up based on the UrlName of the voyage.
[HttpGet] [RelativeRoute("")] public ActionResult Index() { return View("Voyage.NotFound"); } [HttpGet] [RelativeRoute("{urlName}")] public ActionResult Index(String urlName) { return View("Voyage.Detail", this.model.GetViewModel(urlName)); }
Multilingual
Just by chance, as I was showing the problem to another developer he mentioned something about the URL. I can't even recall if it was relevant to the problem but it did lead me to look and consider my multi-lingual set up.
My site had two languages installed and they were based on the domain name. A .com and a .co.uk. My project was set to browse the site as the usual localhost.
What appeared to be the issue was that Sitefinity RelativeRoute has a dependency or a relationship on the multi-lingual URLs. I had to change my project to run under the .com URL and when I did this the RelativeRoute attribute started acting exactly as expected.
Because this configuration was in the project it explained why the problem traveled to other developers. It also explains why it worked on the server because the IIS bindings were using the correct domains in that environment.
You can see how my site was set up and how to configure the multi-lingual domains for your local project from a previous post I wrote.
Hopefully, if you get this issue you find this post in your searches because it was only by luck I worked this one out. Still, you may be one of the many smarter than me people out there and work this out yourself.
Thanks for reading and feel free to comment - Darrin Robertson
If I was really helpful and you would buy me a coffee if you could, yay! You can.
Leave a comment Load more commentsMake a Comment