AI OnAI Off
Problems when saving and publishing a new page
Hi!
I tried configuring the site and edit URL:s to differ and it seems to work for me. Make sure that you specify absulute URL:s for the siteSettings section in episerver.config, for instance:
siteUrl="http://localhost/Head/" uiUrl="http://localhost:90/Head/EPiServer/CMS/"
Jan 26, 2012 11:52
It turns out that this has "nothing" to do with the fact that we use a loadbalancer, but it is because we have a proxy (or reverse proxy) in front of our two webservers.
We have just upgraded one of our solutions from CMS 6 to CMS 6 R2 and we are experiencing the exact same problem with the now upgraded version. The previous version did not have this problem. This new solution also does not have the admin.preprod.no setup, but has a regular edit/admin setup.
In the upgraded CMS6 R2 version we see this extra reload of the page, and this causes problems. The iframe containing EditPanel.aspx removes the https and uses http, and it also adds the port in this redirect.
Linus: Are you sure I should use absolute url's in the uiUrl-setting? This does not seem to work.
May 31, 2012 15:39
I think I have found the error. This seems to be a bug in EPiServer CMS6 R2.
I have done some Reflection, and in the file EditPanel in EPiServer.UI.dll it's a method called "RegisterReloadScriptsForNewPage". The UrlBuilder building up the url for redirecting are using doing this:
UrlBuilder builder = new UrlBuilder(base.Request.Url);
In our case, this cause the url to be http://something.oursite.no:90/ because of our proxy-server.
I think the code should be using Settings.Instance.SiteUrl instead, this will give the correct url.
I can also confirm that this functionality is not the same between CMS6 R1 and CMS6 R2.
Linus, do you have any comments on this one?
I will file a bug with Episerver, hopefully we can get a hotfix for this.
Jun 01, 2012 10:47
Hi!
Yes, the functionality was changed to EPiServer CMS 6 R2. Unfortunately, the method with the bug is private so it's not possible to override it in the markup file. Please report a bug and we'll investigate it..
/Linus
Jun 01, 2012 14:52
I resolved this issue by replacing the code in RegisterReloadScriptsForNewPage with some Reflection code and it seems to do the trick. It's a pretty nice trick when methods are private, internal or whatever:)
Jun 25, 2012 15:54
Hi
Here's the registerd bug number if anyone wants to get a fix:
Bug #81756: Error when creating new page when webservers are behind a proxyserver
Sep 25, 2012 14:24
I getting an issue with HTTPS where a user who edits a Page using the Composer "Edit on page" option can edit content but as soon as they click Save and Publish they are redirected to a Http page and the page is not Saved or Published. The UiUrl and UtilURL are both set up with Https.
Feb 21, 2013 11:21
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
Hi
We are experiencing some problems on our two new sites, (both running R2), when saving or saving and publishing new pages. Editing already existing pages works fine.
To try to explain what goes wrong, these are the steps to reproduce the error:
1. You need a Load Balancer in front of the server (the error still exists even when using only one webserver behind the loadbalancer)
2. The loadbalancer points to i.e. http://preprod.mysite.com and this url are used to visit the site by regular users.
3. The loadbalancer also points to ie. https://admin.mysite.com and this url are used to log into episerver and used by WebEditors and WebAdmins.
4. The website itself runs on another port than 80, i.e port 94.
5. When we log into edit-mode, we go to https://admin.mysite.com. Then we create a new page and choose save and publish. The page will then appear as it should, but after a little while it does a new redirect, and this time to http://admin.mysite.no:94/EPiServer/CMS/edit/EditPanel.aspx?mode=&id=457&selectededitpaneltab=0
As you can see, it removes the s in https and also adds the portnumber.
Does anybody have any idea what could be wrong?
I also want to add that we also have a few sites with this setup running regular CMS 6, and they all work fine.
Could this be a bug in R2 or are we doing something wrong?