-
Notifications
You must be signed in to change notification settings - Fork 67
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
Dashes in source item breaking redirect #49
Comments
Any other regexes in your IIS config that could be handling that URL before the redirect module? |
Thanks so much for thinking about this and replying. I can have my web consultants look at... but before paying for that, I'm thinking that may be the wrong starting place. If I use the same regex and change the Source Item, it fails. I.e., site.org/HotLink pointing to /PageTest works fine, but site.org/HotLink pointing to /Page-Test fails. If the regex works fine for many cases but fails when a specific character is in the Source Item, why would I look at how the regexes are being handled and not start by looking at the code of the module to see how the Source Item is handled? |
Is there anything suspicious in your site config's |
My developers are familiar with that, but since Sitecore does a lot of swapping out of dashes for spaces they don't want to break the expected behavior. From their initial look they don't think it's there. The main reason being that when you use a non-dash redirect, site.org/HotLink pointing to /PageTest, it redirects. Your browser goes to the new URL, site.org/PageTest. However, in the failing case, when you go to site.org/HotLink, no redirection happens at all. Your browser stays at site.org/HotLink and gives a 404 error. That is leading them to believe that the lookup for the location to redirect to is failing. It looks like in the code, before the redirect is made, the target location is checked. The thinking here is that check is failing (due to dash in target path), thus the redirect module never executes the redirect, it just gives 404 error. Was hoping to avoid the cost, but I need it fixed, so I'm having them dig deeper. The alternatives are worse than the cost. |
There’s likely something in the way the ItemResolver is configured that’s stopping the resolution process before the module can be reached. Wonder if we should jump on a quick video chat to take a look. I’m in Pacific timezone & should be able to do most evenings, what time zone are you in? |
Hey, This is what I found, CheckForRegExMatch goes through the patterns items and once it finds a match, once found it will check if LinkManager EncodeNames is enabled and then perform the following:
This will cause the dash char to be replaced with space, then when the code try to get the redirect to item from sitecore in the following, it return null:
Following are the encoding replacement we have in our instance:
Following what I did in code to fix this:
Is this the best way to resolve this? |
Yep that seems ok. You also can modify the regex you’re using to what it would need to be after the matching. I’d be happy to include this in the RedirectModule if you’re interested in making a PR. |
sure thing! |
Issue #49 : Dashes in source item breaking redirect
We are using the Redirect module heavily for URLs, but are expanding to the Pattern redirects due to social media links. We are using them to make "short links" like site.org/HotLink. We are seeing the redirect fail if the Source Item has a dash. Wondering if anyone has seen this?
WORKS: /sitecore/content/MySiteRoot/DestinationOne
WORKS: /sitecore/content/MySiteRoot/Destination One
FAILS: /sitecore/content/MySiteRoot/Destination-One
Our pattern is pretty simple: ^(.)site.org/hotlink(.)$
The text was updated successfully, but these errors were encountered: