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

Dashes in source item breaking redirect #49

Open
MitchT1 opened this issue Mar 6, 2019 · 8 comments
Open

Dashes in source item breaking redirect #49

MitchT1 opened this issue Mar 6, 2019 · 8 comments

Comments

@MitchT1
Copy link

MitchT1 commented Mar 6, 2019

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(.)$

@thecadams
Copy link
Owner

Any other regexes in your IIS config that could be handling that URL before the redirect module?

@MitchT1
Copy link
Author

MitchT1 commented Mar 6, 2019

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?

@thecadams
Copy link
Owner

Is there anything suspicious in your site config's encodeNameReplacements section? I'm referring to the Web.config that's local to your site, not globally in IIS.

@MitchT1
Copy link
Author

MitchT1 commented Mar 9, 2019

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.

@thecadams
Copy link
Owner

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?

@Mohamed-Syam
Copy link
Contributor

Mohamed-Syam commented Mar 12, 2019

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:

path = Sitecore.MainUtil.DecodeName(path);

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:

var redirectToItem = db.GetItem(path);

Following are the encoding replacement we have in our instance:

<encodeNameReplacements>
    <replace mode="on" find="&" replaceWith=",-a-,"/>
    <replace mode="on" find="?" replaceWith=",-q-,"/>
    <replace mode="on" find="/" replaceWith=",-s-,"/>
    <replace mode="on" find="*" replaceWith=",-w-,"/>
    <replace mode="on" find="." replaceWith=",-d-,"/>
    <replace mode="on" find=":" replaceWith=",-c-,"/>
    <replace mode="on" find=" " replaceWith="-"/>
</encodeNameReplacements>

Following what I did in code to fix this:

var pathAndQuery = redirectPath.Split('?');
var path = pathAndQuery[0];
var redirectToItem = db.GetItem(path);
if (redirectToItem == null)
{
     if (LinkManager.Provider != null &&
     LinkManager.Provider.GetDefaultUrlOptions() != null &&
     LinkManager.Provider.GetDefaultUrlOptions().EncodeNames)
     {
         path = Sitecore.MainUtil.DecodeName(path);
     }
     redirectToItem = db.GetItem(path);
}

Is this the best way to resolve this?

@thecadams
Copy link
Owner

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.

@Mohamed-Syam
Copy link
Contributor

Mohamed-Syam commented Mar 13, 2019

sure thing!
#50

Mohamed-Syam added a commit to Mohamed-Syam/301RedirectModule that referenced this issue Mar 13, 2019
thecadams added a commit that referenced this issue Mar 14, 2019
Issue #49 : Dashes in source item breaking redirect
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