Did the upgrade with scripts and Nuget update for project, exported package and run the sql scripts manually.
Works fine locally (but this is just one single machine)
But on production (load balanced, 1 CMS and 2 web fronts), the urls somehow now gets absolute..
In the CMS, the edit view works but the preview of a page wants to use the public www url (which is at the top of the list of the websites urls defined).
But the cms url is a special CMS url used only for editors access.
Has something changed since 7.8 regarding Url and routing ?? I cant find anything about this..
So the problem is actually (I think) that the content reference urls rendered now seems to be absolute urls by using the top url in the list from the webiste definition in admin mode.
Problem was that you must have at least one url with wildcard "*" in the list.... didn't know that, is that dcumented somewhere?
I have exactly the same problem after upgrading to the latest EPiServer via nuget.
When viewing the site under any host name except that which appears at the top of the sites host names site (in admin -> Config -> Manage Websites), all links become absolute and point to the top host name in the list, when browsing the site using the top host name all links are relative.
I did have a wildcard mapping in my host names list, but removing it has not fixed the issue for me.
I also have another (even worse) problem now, after removing the top item in the hosts list and saving - I can no longer access the manage websites page in the admin area, it now give a server error, I've included the logs of this error below.
I've raised an issue with the support team and will update when I get a response.
In the meantime any suggestions on how I can resolve this would be greatly appreciated.
2014-08-22 14:34:20,730  ERROR EPiServer.Global: 1.2.5 Unhandled exception in ASP.NETSystem.Web.HttpCompileException (0x80004005): http://server/episerver/CMS/Admin/SiteInformationList.aspx(21): error CS1525: Invalid expression term ':' at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean throwIfNotFound) at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp) at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I have reported this as an issue as well.
We've received your issues in our ticket inbox. We're trying to reproduce on our end. Thanks!
EPiServer has now been a bug raised for the absolute links problem http://world.episerver.com/Support/Bug-List/bug/116903/
Regarding my other problem (Manage website admin page erroring), we've identified this as a problem with the latest EPiServer version using a server-side script delimiter which is new to .net 4.5 (<%#:), we've upgraded our server as a workaround, but i believe this dependency may be removed as episerver requirements state .net 4.0 or 4.5 - waiting for support to confirm.>%#:),>
We are seeing the same issues, we are on 7.13 -
However, we have a wildcard in our site definition settings and we have an actual host name, and the wildcard appears FIRST in the list...
that's how they are ordered, now when i try to get a "Friendly" url for something, it appears that the hostname gets chopped off completely and you get something like: http:///myfolder/somewherelese/here
I'm not sure why this is happening, but this is definitely new after upgrading all the way from 7.0 - I might attempt to move the * down below the www.somedomain.com and see if anything gets alleviated. Does anyone have any ideas? Is this a known bug?
We are seeing the same issues, we are on 7.13.1 -
Fixed in EPiServer.CMS.Core 7.13.3.
I am currently running 7.13.3 and this still seems to be an issue. I access the site with one hostname but get absolute links with a hostname different from the hostname i used in the url. The host i used in the url is on the hostname list with no culture defined, if i define the culture to be english forinstance, it will work, but when switching the site from english do danish (just applying /da to the url) it again will pick the topname from the host list. This worked perfectly fine before doing the update.
@Frank Could you submit this as a ticket and submit screenshots of how your site is setup? We'll try and reproduce it.
Already done. Case-number DI-142679. The screenshots are attached to the case. The representative that i talked to reopened the bug. But it has now disappeared from the bug list? http://world.episerver.com/Support/Bug-list-beta/bug/116903/
I checked the bug status and it looks like it has been closed "As Designed." Here is the explanation from the product dev based on this scenario:
If in Alloy-Tech have following mappings:
when browsing http://local/en/ , links get following url: http://testsite/alloy-plan/
Explanation from dev:
"This is expected, since local and testsite have different language mappings. What should not happen is that it should not change hosts within same language."
Okay this is new behaviour i comparison to how things worked before this update. My question now is: how do i make it behave like before the update? I dont want my links to change from http://local/en/ to http://testsite/alloy-plan. I would also like to know what is the reasoning behind the change?
The bug #116903 http://world.episerver.com/Support/Bug-List/bug/116903/ has now been closed correctly as "Fixed". It's released in EPiServer.CMS.Core 7.13.3.
Has anyone found the correct solution?