I second this post. Except for the last bullet.
I had this but after todays update I can't reproduce it anymore.
+1 For this.
at least this one is fixed in 7.18 ;)
External link of LinkItemCollection is not saving the link with query string "id"
/K
This one is killing us as the client on us about how to resolve the problem without waiting for a fix from episerver. If anyone has any suggestions on how to allow a domain with a querystring of anytype to be allowed would be great. they are trying to shortcut the page to an external site and any url with a querystring is being thrown an error saying it is not a valid "http://", "mailto:", etc. Thanks everyone
@Joshua – I know exactly what you're talking about. It is very uncomfortable to tell clients to wait for fixes in EPiServer.CMS.UI 7.18.0 just to experience that all their linking issues still remain unsolved. According to the release notes for EPiServer.CMS.UI 7.18.0 some linking isses are said to be fixed and tested, but many issues still remain unsolved (like the ones in my original post). I updated to the latest version (update 47) yesterday but that did not help either.
I can't understand why External link is not treaded just as a plain string value. We had to do our own "Link Page" to resolve the issue.
We have the same issue in our project. Customer complains that content editors don’t have the possibility manually edit parameters in query string.
Is it possible to switch off automatic link parsing?
It also seems like it does not handle the pattern "/?", as in http://someurl.com/?queryParam=foo.
We're aware of the shortcoming in the link dialog when it comes to custom parameters and hope to adress them in a not to distant future. In the meantime the problems with removed query parameters for internal (routed) links should be resolved in version 7.18 of EPiServer.CMS.UI, and version 7.18 of EPiServer.CMS.Core made it possible to link to actions with parameters.
The automatic parsing of routable urls can't be turned off, and the conversion to internal url's is hopefully the lesser evil. Keeping internal links as static unparsed url's would make them break if pages are renamed or moved. We would also miss out on the use count when deleting or changing content.
If you turn on the original tinyMCE link dialog you're able to edit the url as a plain string.
Also I found if url go to internal virtual page, cms can't found corresponding page and crop url to start page.
Example:
http://mysite.com/search?query=test
cropped to
http://mysite.com/?query=test
@stefan - are you saying that converting of explicitly entered external links to internal ones (stripping all parameters and hash tags on the way) is intentional an will not be fixed? If so we need to convert a lot of Url properties to plain strings, and that is not by far less evil. There are several real world scenarios where an editor needs to make a link to a page, and at the same time pass some parameters. Be it query strings after a "?" or hashes after a "#". How would you go about it?
When explicitly selecting "External link", you're effectively saying "this is part of another site, and has nothing to do with this site". Why is this in any way passed through the internal routing? It should really just be a simple string without any validation. If someone enters an invalid URL, it's super easy to track that back to them. And it also allows for whatever they feel like (mailto, tel etc) in there.
Most people copypaste URL's into such fields anyways.
@Tarjei - Converting url:s to internal when possible is intentional, but stripping the parameters when doing so is not desirable and is considered a bug. We're also aiming to add the possibility to edit custom parameters. As you point out, there's a need for parameter handling both on internal and external links.
@Arve - Though you have a point, we're currently using the same dialog from different places and the type selection is more of a user convenience since the backing field is a Uri/Url with nothing stating whether that pasted internal link is to be considered external or not. If we look past the problems with lost parameters, is there a real world situation where you don't want to recognize valid internal links?
It's a fair point to recognize it as an internal resource. But when it isn't, it should be treated more or less as a plain string, I'd say. Or in the very least be treated correctly as a URL. (I think I had some issues with a copypasted facebook-URL not being "a valid URL" because it ended with /? or something like that)
Might, of course, bring some challenges to how it's handled back end - but the user shouldn't suffer.
Yes, the client side validation is way too strict. The aim is to more or less remove the client side validation and let the back-end determine what's valid. Unfortunately we ran into some problems with how System.Uri throws from its getters but is just fine with setting invalid values. The result was that you could save a bad link just fine but things blew up when trying to read it back.
Therefore we temporarily post-poned this change to instead revisit it together with the other shortcomings mentioned.
We still have problems trying to link to other languages, running EPiserver 8
We have disabled the language prefix /sv /en and have two hosts mapped in site host settings for each language.
If I choose to add the link as an external link, EPiServer tries to get smart on me and remaps it as an internal page and gets linked to the wrong language.
If I choose to link to another language using the language selector, it only works when I am logged in.
I have managed to link the Swedish site to the English but I cant link the English site back to the Swedish site this way.
If someone enters an URL as external please don't meddle wit it, don't try to get smart and do a lookup just let it be!
Please help, we cant link between languages!
We're also having the same issues. This is something that needs to be addressed.
I'm also having the same issue, can't insert a link with a querystring, frustrating.
The validation in the link dialog should be fixed now: Link validation is too strict in new link dialog
The issues with linking between sites on different languages are fixed in the upcoming EPiServer.CMS.Core 8.3 and are currently being tested by our QA:
Linking between sites with different host to language mappings renders invalid links
Linking between sites with host to language mapping does not work
Tried to link to www.mypage.com/searchpage/?query=something&category=fruit using the field external link and the editor replaced it with the page "searchpage" (stripping the params)
After talking to EPi-support I got the answer this is expected behaviour but that they have submitted a feature request #127002
Let's hope that we get a field that let's us link to internal pages with query-params =)
Has there been any update on the feature request for linking to internal pages with query params? (looks like the link is broken).
Hello Everyone,
I have found a Fix for on of the issue mentioned by Tarjei Olsen and others:
Issue: "
"
We faced the similar problem when adding the External link in TinyMCE it get automatically converted to Internal link ( adding from /lv and link was in /en). i just changed the language from Automatic(Default) to english and it worked.
Solution:
Episerver converts the external link to internal since it find the page within the page tree of the CMS.
Also when the page or the link is between 2 different languages i.e in /en and /sv and you are linking any page as and external link (which episerver converts to internal link).
You need to change the language from Automatic to English(or the language in which the content exists)
I'm having several problems with external links and page shortcuts. There has been several forum posts and bug reports regarding this, but the issues remain unresolved, so this is to sum up and call for some attention:
EPiServer – any idea when these issues will be addressed? I'm trying to put off converting Url properties to strings and doing proper validation myself, but I kind of don't want to do that as this should be built in to the CMS.
Tested today with these nuget package versions:
EPiServer.CMS.Core.7.18.0
EPiServer.CMS.UI.7.17.0
EPiServer.CMS.UI.Core.7.17.0
EPiServer.Framework.7.18.0