AI OnAI Off
Links are absolute after upgrading 7.5 => 7.11 (load balanced)
Problem was that you must have at least one url with wildcard "*" in the list.... didn't know that, is that dcumented somewhere?
Edited,
Aug 19, 2014 10:53
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.
Thanks
Dom
2014-08-22 14:34:20,730 [129] ERROR EPiServer.Global: 1.2.5 Unhandled exception in ASP.NET
System.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)
Aug 22, 2014 17:41
We've received your issues in our ticket inbox. We're trying to reproduce on our end. Thanks!
Aug 25, 2014 17:44
Thanks Richly...
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.>
Thanks
Dom
Aug 28, 2014 12:04
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...
so:
* en
www.somedomain.com en
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
instead of
http://www.somedomain.com/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?
Sep 11, 2014 17:21
We are seeing the same issues, we are on 7.13.1 -
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...
so:
* en
www.somedomain.com en
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
instead of
http://www.somedomain.com/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?
Edited,
Sep 11, 2014 17:23
Fixed in EPiServer.CMS.Core 7.13.3.
http://world.episerver.com/Support/Bug-list-beta/bug/116903/
Sep 16, 2014 11:15
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.
Edited,
Sep 26, 2014 15:28
@Frank Could you submit this as a ticket and submit screenshots of how your site is setup? We'll try and reproduce it.
Oct 02, 2014 4:18
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/
Edited,
Oct 02, 2014 9:08
Hi Frank,
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:
* sv
testsite en
local sv
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."
Oct 09, 2014 17:18
Hi @Richly
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?
Oct 13, 2014 13:32
Hi,
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.
Oct 16, 2014 12:23
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
Hi,
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.
regards
Fredrik