The rewrite rule works, however it causes problems with any ajax calls or anything that uses @Url.Action
If for example I was on the following page: "/books/9780334042013/alive-to-the-word"
Then any @Url.Action that was used on the page would point to "/books/9780334042013/umbraco/Surface............" instead of pointing to "umbraco/Surface.........."
Also anything that has a tilde at the start will also point to the wrong URL, for example the following:
Thank you for the response but I do not think that is the case here, the rewrite rule is being applied to things that do not even contains books in the URL for example it is changing what should be this:
This is only the case when using @Url.Action, if I was to manually type the URL above it would not rewrite it (unless I added a tilde at the start).
Also I would not be able to apply your rules because the number part can sometimes contain other characters and the title could effectively just be a number.
I cannot change the URL's either (not without having to setup a lot of 301 redirects) because this is actually an upgrade of a current Umbraco site that has been live for years. The rewrite rules have always worked correctly on the current site using the UrlRewriting.config file but this functionality has now been removed, plus as mentioned above it seems to only be when using @Url.Action in MVC (the old site didn't use MVC).
This article on stack overflow appears to explain the issue and they suggest using Routing instead of rewrite rules, however I am not sure this is possible in Umbraco because I do not want to route to a controller and call an action because I need to open the actual Umbraco node if that makes sense):
https://stackoverflow.com/questions/5801285/incorrect-url-action-when-url-rewrite-is-used
We are having the same problem, it is happening in a master view where we are referencing scripts, I am assuming it is something to do with rewrites as it doesn't happen when I disable all rewrites.
Did you ever find a solution for this? I am back working on the websites that have this issue and need to resolve the problem ASAP because they will be going live soon.
I would rather not have to replace all instances of @Url.Action with the actual URL (without a tilde of course) but it seems I may not have any other option at this point if I want to get my rewrite rules working.
URL rewrite rule causing problems with @URL.Action and also URL's that start with a tilde ~
I have an Umbraco 7 MVC website and I have added the following rewrite rule into the web.config:
The rewrite rule works, however it causes problems with any ajax calls or anything that uses @Url.Action
If for example I was on the following page: "/books/9780334042013/alive-to-the-word"
Then any @Url.Action that was used on the page would point to "/books/9780334042013/umbraco/Surface............" instead of pointing to "umbraco/Surface.........."
Also anything that has a tilde at the start will also point to the wrong URL, for example the following:
Would point to:
Does anyone know how I can resolve these issues so that I can get my URL rewrite rules to work correctly?
Bump
The issue is that your match expression will basically match any URL that starts with books followed by two forward-slashes.
You could tighten it up a bit to match books followed by a number and then a title so it becomes:
(The
\d+
matches one or more digits and the.+
matches at least one character.If you can I'd also add an extra segment into your original URL that makes it more unique:
That way it would only match URLs of form
/books/book/9780334042013/title/
Hi Dan,
Thank you for the response but I do not think that is the case here, the rewrite rule is being applied to things that do not even contains books in the URL for example it is changing what should be this:
To this:
This is only the case when using @Url.Action, if I was to manually type the URL above it would not rewrite it (unless I added a tilde at the start).
Also I would not be able to apply your rules because the number part can sometimes contain other characters and the title could effectively just be a number.
I cannot change the URL's either (not without having to setup a lot of 301 redirects) because this is actually an upgrade of a current Umbraco site that has been live for years. The rewrite rules have always worked correctly on the current site using the UrlRewriting.config file but this functionality has now been removed, plus as mentioned above it seems to only be when using @Url.Action in MVC (the old site didn't use MVC).
This article on stack overflow appears to explain the issue and they suggest using Routing instead of rewrite rules, however I am not sure this is possible in Umbraco because I do not want to route to a controller and call an action because I need to open the actual Umbraco node if that makes sense): https://stackoverflow.com/questions/5801285/incorrect-url-action-when-url-rewrite-is-used
Bump again
Surely someone else has come across this or do people not URL rewrite rules in Umbraco anymore?
We are having the same problem, it is happening in a master view where we are referencing scripts, I am assuming it is something to do with rewrites as it doesn't happen when I disable all rewrites.
I found this but still doesn't work for us.
https://support.microsoft.com/en-gb/help/2905164/tilde-notation-maps-to-the-original-urls-by-using-iis-url-rewrite-in-a
Hi Tim,
Did you ever find a solution for this? I am back working on the websites that have this issue and need to resolve the problem ASAP because they will be going live soon.
I would rather not have to replace all instances of @Url.Action with the actual URL (without a tilde of course) but it seems I may not have any other option at this point if I want to get my rewrite rules working.
Yes this works for a number of our projects.
https://support.microsoft.com/en-nz/help/2905164/tilde-notation-maps-to-the-original-urls-by-using-iis-url-rewrite-in-a
Seems crazy you have to do this though. You will need to sort out the Umbraco global.asax but easy done just search google and should come up.
is working on a reply...