Vulnerability in EPiServer.Forms
We have a site where there are a lot of information about educations and the pages lives in the episervertree at one place but the url the customer like to have public differ a lot from that. For example the page at this place in the tree:/educations/educationarea/educationpagehas a public url like/utbildning/[utbildningsort]/[utbildningsområde]/[Namn på utbildning]-[id på utbildning]
We have a working custom routing but when the user press the editbutton they end up edition the (/utbildning)-page. Are there any way to achive what we want and still be able to use the editbutton?
Can you describe your problem a bit more. Since there is no "edit button" (at least not that I am aware of), are you meaning that they are using the quick navigator on the site and gets to the wrong page or are you meaning that they are navigating within the on page edit/preview views in the editorial interface and getting the wrong pages?
Linus, that is true, I forgot what the name was, it is the quick navigation on the top right corner I mean.
And it is exactly as you say, they end up on the wrong page when clicking on the navigation.
Here is a film showing the problem
The logic that was used to determine the page id in EPiServer 7 was the following:
var request = new RequestContext(new HttpContextWrapper(HttpContext.Current), new RouteData()); var urlHelper = new UrlHelper(request, RouteTable.Routes);
var quickNavigationMenu = new QuickNavigatorMenu();
// getting current CMS page, to get pageLink, and append it to the Edit Url var pageContent = htmlHelper.ViewContext.HttpContext.GetService<PageRouteHelper>(); quickNavigationMenu.CurrentPageLink = pageContent.PageLink; // assign the CurrentPageLink property, so the View can get EditPageUrl
The code above has been rewritten in EPiServer 7.5 so you might want to test how your custom routing works there before making any changes. The new code looks like this:
var contentRouteHelper = ServiceLocator.Current.GetInstance<ContentRouteHelper>(); _currentContentLink = contentRouteHelper.ContentLink;
I finaly got it working and I had to do a combination of the differnt way of routing, partial routing and section routing.
At this url we have a page that are listning all education
The request from the client was that if they wrote for example:
http://www.lernia.se/utbildning/stockholm/ or http://www.lernia.se/utbildning/data-och-it/ they should get all the education in Stockholm or in the data/it-area.
Another request was that if they wrote http://www.lernia.se/utbildning/stockholm/data-och-it/ they should get all the education in Stockholm in the data/it area.
To be able to do that we implemented section routing that looked at all the sections below /utbildning/ and added the locations or/and educationareas to the controller as RouteData-values.
The next thing was that the url to the educationpage had to contain all of this and information of the education, so the url to a education in data/it in Stockholm is: http://www.lernia.se/utbildning/stockholm/data-och-it/systemutvecklare-16233/.
First we solved that with section routing but doing that we did not get the fastedit-link to work, so if you were logged in and access'd the url for the education and pressed the fastlink to edit (quicknavigationMenu) you got to editmode for this url http://www.lernia.se/utbildning/ and that was very irritating. Now I have found a way to do it and that is to add a partial routing for all pages with the basetype of education existing below the educationlist-pagetype that sets the "right" url for the education inside EPiServer and that parse the url on request and founds out the id-part and through that gets the educationpage and return it to the browser. One key thing to remember is that we have to fix it in the sectionrouting as well since if the last section in the request after /utbildning/ is the link to the education we have to return false so the sectionrouting (that is called before the partial routing) not handle that request.
A very complicated routing example...... So nice to finaly be able to get it to work!