Issues in built-in URL-tracker (Redirect URL Management)?
I just installed Umbraco 8.1.5 including the sample website. While testing a little bit (creating new pages, publishing, moving, renaming, deleting) I think that there is an issue in the "Redirect URL Management" (URL tracker) in the content section. Maybe my understanding of this feature is not right. If so, please let me know!
When moving a published node there is no new redirect created. I expected the following redirect, but there is none (also checked the database table 'umbracoRedirectUrl').
Furthermore, when requesting the "old" page link (/about-us/test-1/) in the browser, I get a 404. So there is no 301-redirect executed.
Can you reproduce this behavior? Does this feature not work as it should? Or do I have wrong expectations? I also searched in the forum and in the web, but could not find anything (related to Umbraco 8.x)...
You're right, there's a bug in the redirect tracking so it currently only records when nodes are renamed. It should also record nodes being moved, and it did in 7.x. Version 8 changed the events that are raised when a page is moved, and the redirect tracker doesn't handle the change. It's in the issue tracker here.
Deleting seems to work OK for me, with redirect entries being deleted when the target node is deleted. I wouldn't expect an entry to be created when a node is moved to the recycle bin, because we don't have a new URL to redirect to.
There is perhaps some slightly odd behaviour while the target page is in the recycle bin, if there's an older redirect entry for a URL:
Create a page at /test/, rename it to /test-1/
/test/ correctly redirects to /test-1/
Create another page at /test/, rename it to /test-2/
/test/ correctly redirects to /test-2/
Delete /test-2/, and /test/ will be a 404. We find the redirect rule for the deleted node, but can't use it.
Empty the recycle bin, and /test/ starts to redirect to /test-1/ again. With the /test-2/ rule deleted, we find the older rule again.
Issues in built-in URL-tracker (Redirect URL Management)?
I just installed Umbraco 8.1.5 including the sample website. While testing a little bit (creating new pages, publishing, moving, renaming, deleting) I think that there is an issue in the "Redirect URL Management" (URL tracker) in the content section. Maybe my understanding of this feature is not right. If so, please let me know!
When moving a published node there is no new redirect created. I expected the following redirect, but there is none (also checked the database table 'umbracoRedirectUrl').
When moving back, still the same: no redirect is created.
When renaming and publishing the node, a new redirect is created (as expected).
When moving this node, the existing redirect is changed (as expected), but there is no new one created.
When deleting a node, the existing redirect is changed (correct), but there is no new one created.
Furthermore, when requesting the "old" page link (/about-us/test-1/) in the browser, I get a 404. So there is no 301-redirect executed.
Can you reproduce this behavior? Does this feature not work as it should? Or do I have wrong expectations? I also searched in the forum and in the web, but could not find anything (related to Umbraco 8.x)...
You're right, there's a bug in the redirect tracking so it currently only records when nodes are renamed. It should also record nodes being moved, and it did in 7.x. Version 8 changed the events that are raised when a page is moved, and the redirect tracker doesn't handle the change. It's in the issue tracker here.
Hi Steve, thanks for your quick reply!
I am a bit disappointed with myself, that I was not able to find the issue in the issue tracker. But glad that there will be a fix.
One question: The solved issue #5050 (in V8.3) does not solve the issue on delete, does it? Does exist another issue for this already?
Deleting seems to work OK for me, with redirect entries being deleted when the target node is deleted. I wouldn't expect an entry to be created when a node is moved to the recycle bin, because we don't have a new URL to redirect to.
There is perhaps some slightly odd behaviour while the target page is in the recycle bin, if there's an older redirect entry for a URL:
is working on a reply...