Today I received the second question in a row about the fact that the protocol and domain part of the entered URL is removed for links to postings.
This behaviour is a feature of MCMS: In reverse proxy scenarios where requests are forwarded by a proxy to the internal web server it would be bad if the servername would be inside the URL.
Just as an example: the user in internet would enter http://www.mydomain.com/mychannel/myposting to access a specific posting. This request ends at a proxy server which forwards this request to an internal server named MCMSServer. So the request will be rewritten to http://MCMSServer/mychannel/myposting. If the link is generated internally then the link to this posting would be stored in a placeholder as http://MCMSServer/mychannel/myposting. But such a link is not valid in the internet!
In addition if a page can be retrieved using https and http then the links should also be using the current protocol and not redirect back to http. This is a second reason to render relative links rather than absolute links.
For MCMS this come in handy as MCMS stores links in an internal format anyway: The URL is replaced with an internal format which mainly consists of the GUID of the item. When the placeholder content is retrieved from the database again this internal format is replaced with the current URL of the linked item.
This is how the MCMS link management feature works: if you are moving a posting to a different channel the GUID is still the same and links are automatically recalculated correctly.
So by design when MCMS regenerates the link it generates it without the protocol and the GUID if the link points to a posting in the same site.
Be aware that you need to install the following hotfix if this does not work on your site if host header mapping is enabled:
824597 – Absolute URL Is Returned When You Use the Channel.Url Method of the PAPI and Host Headers Are Enabled