AI OnAI Off
Page URL resistant to PageName change
Hm.. if you have a 404 handler (like Geta.404handler) then you can add a redirect automatic in a published event by looking up the previous segment and the new segment, and if it is changed, then add that to the redirect handler. You should most likely do this on MovedEvent too
This will only work if no new article get the old segment as if a new article get the same segment that the 404handler will not get hit
Edited,
Dec 16, 2020 7:36
By default, the URL segment will not change if you change the name of the page.
If you want old URLs to work, even after changing the URL seg ment you can use the 404 handler by Geta, or this lightweight redirect module:
https://github.com/tomahg/RedirectManager
I have upgraded to the new (blue) Episerver UI in this fork. It has support for creating redirect rules when the URL segment is changed, and you can easily adapt this to take effect for article pages only, if that is what you need.
Dec 16, 2020 8:08
WilliamP
- Apr 07, 2021 14:25
Hi Tomas, I have implemented your fork of the RedirectManager package in our project and it seems to be working pretty well. There is just one problem we're experiencing, albeit critical.
When altering the URLSegment of a page which contains child pages, the resulting redirect of this parent page also appears to 'catch' all of the children pages beneath said parent page. This means that all child pages become unreachable.
E.g.
1. Change "Tent systems" to "Tent system" (/solutions/buy-event-space/tent-systems/ --> /solutions/buy-event-space/tent-system/).
2. Visit the old URLSegment of the page, this now automatically redirects to /solutions/buy-event-space/tent-system/.
3. Visit a child page of "Tent system", e.e.. "New page" (/solutions/buy-event-space/tent-system/new-page/).
4. This page now redirects back to /solutions/buy-event-space/tent-system/, making it unreachable.
Do you have any ideas what could be going wrong? I could edit the code to make the adding of a redirect on the publish event recursive when the page has children, but that seems potentially bad for performance...
When altering the URLSegment of a page which contains child pages, the resulting redirect of this parent page also appears to 'catch' all of the children pages beneath said parent page. This means that all child pages become unreachable.
E.g.
1. Change "Tent systems" to "Tent system" (/solutions/buy-event-space/tent-systems/ --> /solutions/buy-event-space/tent-system/).
2. Visit the old URLSegment of the page, this now automatically redirects to /solutions/buy-event-space/tent-system/.
3. Visit a child page of "Tent system", e.e.. "New page" (/solutions/buy-event-space/tent-system/new-page/).
4. This page now redirects back to /solutions/buy-event-space/tent-system/, making it unreachable.
Do you have any ideas what could be going wrong? I could edit the code to make the adding of a redirect on the publish event recursive when the page has children, but that seems potentially bad for performance...
Tomas Hensrud Gulla
- Apr 07, 2021 16:37
Hi William,
I'm sorry to hear you are experiencing problems. Are you using the «Auto wire up» method described at the bottom of the readme, or adding the redirects manually? Either way, you can check the redirects being created in the admin ui - available from the menu in Episerver.
I just tried following your steps, but could not reproduce the problem.
The redirect should only happen if a 404 is hit firsts, so the module should never prevent existing pages from being accessed.
I'm sorry to hear you are experiencing problems. Are you using the «Auto wire up» method described at the bottom of the readme, or adding the redirects manually? Either way, you can check the redirects being created in the admin ui - available from the menu in Episerver.
I just tried following your steps, but could not reproduce the problem.
The redirect should only happen if a 404 is hit firsts, so the module should never prevent existing pages from being accessed.
WilliamP
- Apr 08, 2021 8:25
Hi Tomas,
Thanks for taking the time to respond to my comment. We are using the "Auto wire up" approach. I do in fact see the redirect appearing in the admin UI (with the wildcard flag set to true, as is the default in the package code logic).
Apparently the problem is on our end then, seeing as you cannot reproduce it. I'll take another look at how we've implemented the RedirectKeeper and RedirectService classes to see if we may have broken something somewhere.
Thanks for taking the time to respond to my comment. We are using the "Auto wire up" approach. I do in fact see the redirect appearing in the admin UI (with the wildcard flag set to true, as is the default in the package code logic).
Apparently the problem is on our end then, seeing as you cannot reproduce it. I'll take another look at how we've implemented the RedirectKeeper and RedirectService classes to see if we may have broken something somewhere.
Tomas Hensrud Gulla
- Apr 08, 2021 9:24
Please let me know if you figure it out, no matter where the problem is :-)
WilliamP
- Apr 19, 2021 9:40
Hi Tomas,
We just revisited this and it turns out the issue with child pages no longer being able to be reached (on the new parent URLSegment) after their parent changing its URLSegment had to do with browser cache for multiple redirects which were the result of changing the URLSegment multiple times.
However, there is still an issue with visiting child pages with the old URLSegment of their parent resulting in redirects to the parent (with new URLSegment). Is this something that you are able to reproduce?
To elaborate, I mean this:
1. Change /global/solutions/tent-systems/ to /global/solutions/tent-systems-changed/
2. Visiting /global/solutions/tent-systems/ now redirects to /global/solutions/tent-systems-changed/
3. Visiting /global/solutions/tent-systems-changed/a-child-page/ works.
4. Visiting /global/solutions/tent-systems/a-child-page redirects to /global/solutions/tent-systems-changed/.
The issue is 4), as if external links point to any of the potentially hundred pages underneath /global/solutions/tent-systems/ (the old URLSegment), all those child URLs will result in a redirect to the new URLSegment of the parent (tent-systems-changed).
If this is just how it works, I feel the quickest solution would be to add a recursive check for child redirects but that feels a bit much honestly.
We just revisited this and it turns out the issue with child pages no longer being able to be reached (on the new parent URLSegment) after their parent changing its URLSegment had to do with browser cache for multiple redirects which were the result of changing the URLSegment multiple times.
However, there is still an issue with visiting child pages with the old URLSegment of their parent resulting in redirects to the parent (with new URLSegment). Is this something that you are able to reproduce?
To elaborate, I mean this:
1. Change /global/solutions/tent-systems/ to /global/solutions/tent-systems-changed/
2. Visiting /global/solutions/tent-systems/ now redirects to /global/solutions/tent-systems-changed/
3. Visiting /global/solutions/tent-systems-changed/a-child-page/ works.
4. Visiting /global/solutions/tent-systems/a-child-page redirects to /global/solutions/tent-systems-changed/.
The issue is 4), as if external links point to any of the potentially hundred pages underneath /global/solutions/tent-systems/ (the old URLSegment), all those child URLs will result in a redirect to the new URLSegment of the parent (tent-systems-changed).
If this is just how it works, I feel the quickest solution would be to add a recursive check for child redirects but that feels a bit much honestly.
Tomas Hensrud Gulla
- Apr 19, 2021 9:43
Yes, the redirect to parent is because of the wildcard redirect.
To fix the issue, you must:
- not add wildcard redirect
- add redirect for all descendants
To fix the issue, you must:
- not add wildcard redirect
- add redirect for all descendants
Thomas,
is this module available to editors or is it something you can restrict access to?
I forgot to mention that client wants to change URL segment to match the page name within the ContentPublishing event. That entails following problem: editors who do not have access to admin or in this case redirect manager would need to notify admin of that change implying that admin now gets up to 200 requests per day to maintain 'broken' URLs.
I believe that having a content ref in url (either as an trailing param or as leading param before the acctual page name) would solve this demand.
Dec 16, 2020 12:50
You could control access to the module GUI. Redirects can be added automatically when the URLsegments changes, you do not need to add redirects manuallu.
You can of course also solve this by adding the content id to the url. I have seen it done successfully.
Dec 16, 2020 13:01
Hi,
there is demand to have a safe way of changing a name of article page (and article page only) so that newly generated URL still could be resolved with the old URL that might have been sent in a mailing list.
I thought of including a content reference in a part of url so that custom URL resolver could pick that up and do a 301 to a newly named page, but so far I didn't get far.
There was a blog that used custom override of url rewriter implementation but that approach is now deprecated and Episerver encourages use of routes.
Approach with custom routing and placing {id} in any part of the standard Episerver {language}/{node}/{partial}/{action} gets me to 404 in any case.
Has anyone here done something similiar and if so what approach did you take?