Which version of the 301 URL Tracker are you using?

Yes sorry. 301 Url tracker v1.5 and Umbraco v4.9.0.

/Rune

Well the problem for me is; I've tested it on a clean umbraco v4.9.0 installation and I can't look into yours, so it's impossible for me to tell you what's wrong at this point.

Yep, I'm aware of that. I was hoping that you knew some other bonehead like me who couldn't make it work :)

Should there be anything in the web.config specific for your package?

/Rune

Nope, as long as the assembly is in place and the 404handler is configured, it should work.

• What is the old url of your page? 
• Does this old url have an entry in SQL in the 301infocaster table?
• If so, are there any differences between the url you're requesting and the url in the table? Like traling slash?

The old url: http://bestpractice.teasolutions.dk/page1/

Yes, it gets created in your database table and it looks like this:

NodeID    OldUrl    IsCustom    IsRegex    Message    Inserted
1064    /page1/    0    0    This document was renamed    2012-10-12 12:23:58.953

/Rune

Could you check if the 301 URL Tracker is called by viewing the Trace information?

It looks like it does:

notFoundHandler    Trying NotFoundHandler 'umbraco.SearchForAlias'...    0.011691    0.000036
urlAlias    'page1'    0.011836    0.000144
notFoundHandler    Trying NotFoundHandler 'umbraco.SearchForTemplate'...    0.012075    0.000240
notFoundHandler    Trying NotFoundHandler 'umbraco.SearchForProfile'...    0.012182    0.000107
notFoundHandler    Trying NotFoundHandler 'InfoCaster.Umbraco._301UrlTracker.Handler301URLTracker'...    0.012272    0.000090
notFoundHandler    Trying NotFoundHandler 'uComponents.NotFoundHandlers.MultiSitePageNotFoundHandler'...    0.023574    0.011302
notFoundHandler    NotFoundHandler 'uComponents.NotFoundHandlers.MultiSitePageNotFoundHandler found node matching page1 with id: 1108    0.023958    0.000384

So far so good. So now it looks like it cannot find the database entry.

/Rune

This is really weird, I'm afraid there's only 1 option; to find the problem it has to get debugged.
The source is available on the front page, so you could have a go for yourself if you'd like.

Otherwise, the only 'solution' would be to give me a zip file containing the umbraco instance; filesystem and SQL db.

I will have a go at the source code myself. I should be able to find the problem.

Going on vacation today though, so it might be some time before I have a result. I will post it back here when I have it.

/Rune

Oh, and thanks for the help so far! I really appreciate it.

/Rune

Aight, no problem.

Good luck and please do reply when you've found something.

Hi Kip,

Finally I got the time to debug this, and I found the problem.I think it's a problem anyways. It seems that your Handler301URLTracker.cs checks the domain rootnode against the "real" root node of the node tree. Lines 100 and 101:

Node rootNode = n.FindRoot();
if (rootNode.Id == root || root == -1)

My site does not pass this small test, and therefore can not be redirected to the correct page, which is found and everything.

I'm not sure what to do about this, and why that check is there in the first place. You cannot expect the domain to be set at root level. My tree looks like this:

What to do? I could delete the step and use my own forked version, but if you can fix it in general others could benefit as well. :)

/Rune

Yes I can see why it goes wrong in that situation.
We've always worked with rootnodes, that's why I've never thought about it going wrong ;-)

The reason I check the 'rootnode', is because of multiple websites in one umbraco installation. I know this check is for when url's are relatively saved.
But with the new Umbraco versions I'm not sure if that's still the case when 'useDomainPrefixes' is set to true.

I'll have to check this out to think about a fix, but I'm not sure when I'll have time to do so.
Ofcourse you can fix it for now in your current situation, but I will look into fixing this.

Cool. I'll make a fix for myself and then I can update when you get to look into it. My solution will probably be to remove that check all together. Can't se what I can use it for. :)

Thanks for the quick response.

/Rune

I'm dealing with the same issue. Did any of you implement a fix for this?

Hi Arjan,

Yes I have fixed it in my version of the source code. Here's my version of the dll:
http://dl.dropbox.com/u/20891897/Infocaster%20301UrlTracker/InfoCaster.Umbraco._301UrlTracker.dll

/Rune

Thanks! It seems to be working, kinda...

Somehow the 301 URL Tracker works as some sort of regular 404 page handler: it returns a 404 status for the mapped URL, and then loads the page it was mapped to, but without redirecting the browser.

So I have a page in Umbraco /nl/oplossingen, and in the 301 URL Tracker property I added a custom mapping: /paginas/16-oplossingen

http://www.domain.com/paginas/16-oplossingen should redirect (with status 301) to http://www.domain.com/nl/oplossingen but instead it doesn't redirect, it just shows the page "transparently" without changing the URL in the browser. So it basically operates as a umbracoUrlAlias instead of 301 redirect.

Any ideas?

@Arjan

Seems like the 301 URL Tracker didn't do it's job, in other words; it didn't match the requested url.
I can't give you a reason, that would require debugging with your situation...

@kipusoep

When I change the following code (line 115-118 of Handler301URLTracker.cs):

_redirectID = redirectId;
HttpContext.Current.Response.Status = "301 Moved Permanently";
HttpContext.Current.Response.AddHeader("Location", n.NiceUrl);
return true;

to:

_redirectID = redirectId;
HttpContext.Current.Response.Status = "301 Moved Permanently";
HttpContext.Current.Response.AddHeader("Location", n.NiceUrl);
HttpContext.Current.Response.End();
return true;

then the 301 status is correctly returned.

Of course everything after Response.End() isn't processed. If I leave out the Response.End() the code somehow returns a 404 status instead. I'll have to do some further debugging to find out what code overrides the 301 status setting, but maybe you have an idea what to look for? Btw, I have disabled all other NotFoundHandlers, so the 301 URL Tracker is the only handler that's being triggered.

I found the same bug yesterday and I fixed in the source with Response.End(), but haven't released it yet ;-)

Did you add the Response.End() at the same location I did? Or did you make additional changes? I'd like to compile a fix right now, and deploy to one of our clients' sites.

Yes exactly the same location, no additional changes.

Perfect, I'll compile and deploy right away.

Btw, while you're at it, you might want to add a Response.Clear() too:

_redirectID = redirectId;
HttpContext.Current.Response.Clear();
HttpContext.Current.Response.Status = "301 Moved Permanently";
HttpContext.Current.Response.AddHeader("Location", n.NiceUrl);
HttpContext.Current.Response.End();
return true;

It's working:

*thumbs up*

@kipusoep

Will you release a new version with the fix soon? I have the same problem with the version 1.5.1 :-/

@Esben: Until there's an official release, here's the altered 1.5.1 version I'm currently using:

https://dl.dropbox.com/u/103449/InfoCaster.Umbraco._301UrlTracker.dll

@Arjan H.

Thank you :-)

@Esben

I'll make sure a new version will be here soon.
Meanwhile; Arjan thanks for the assistance! 

That's sorted it for me too. Shouldn't this be updated on the package download page ASAP as it seems pretty critical to me. 

First of all thank you very much for a great plugin, works sweet.

I had the same experience with receiving 404 instead of 301 and it helped with the latest dll you have in your dropbox. I think the regex redirects are still returning 404?

All the best, Mads

I just noticed my altered .dll also triggers another issue in v4.11.3. The thumbnails/previews in the Media section aren't loading anymore. I just see that animated loading GIF, and nothing happens. Using the original InfoCaster.Umbraco._301UrlTracker.dll fixes this issue, but then we're back to square one regarding the 404-instead-of-301-redirect issue. :-(

@Arjan H

Not sure if this is the problem but your DLL is compiled against .Net 4.5 instead of 4.0 (you'll get a lot of YSOD if you try it on a server without 4.5 installed). 

Also as already reported the same ending the response fix will need added to the MatchRegex method (until U4-1441 is resolved).

Are there any plans to release an official fix for this?

Sure, I'll create a new release right away.

I've uploaded v1.5.2 which should fix this issue.

Does this new release also fix the MatchRegex issue?

Maybe you could provide more information about what you mean with 'the MatchRegex issue'?

See the comments made by Mads Rode and Doug Mackay in this thread.

Well as you can see in the source, the MatchRegex method also contains HttpContext.Current.Response.Clear() and HttpContext.Current.Response.End().
So yes, that should be fixed too. 

Ah, hadn't had a chance to check the source yet. :-) Awesome!

Looks to work great, thanks for the updated version.

Thanks for the quick turn around :)

is working on a reply...