Moving website is fragile

[PonchoPowers]

Logging here due to ability recreate issue quickly. Will log in the Core project too if need be.

I have a website that runs under the root of a website in IIS (/) and on my local machine I work on lots of different websites so I run then under virtual directories.

When using LinkProperty, paths are stored in the database based with the inclusion of the virtual directory the application is hosted in.

Upon migrating the website to a different virtual directory, all LinkProperty Url data stored in the database needs to be updated.

When there are lots of pages, this manual process of updating them all is quite labour intensive and time consuming.

The LinkProperty should not store the virtual directory information in the database and instead this should be resolved during execution of the page to make migrating the website easier.

If a fix is implemented, this will be a breaking change so requires a discussion to work out how to deal with this problem.

[PonchoPowers]

This only applies to Page and File LinkType links.

[PonchoPowers]

Having thought about this a possible upgrade path is to have a flag in the database which specifies if the virtual path was included and by default we assume all existing URL's contain a virtual path and any new URL's don't, then we can update the code so that any new URL's will be relative to the application, and we add some code to handle both scenarios, obviously this means any existing URL's will still break when migrating the website but new URL's will at least work.

[fschultz]

This is a legacy design flaw I'm afraid, which also affects the HTML property.

I'll have to think about what would be the best solution to come to terms with this, but my initial thought is to add a scheme that stores the references to the pages rather than the URL. That way it could support both the new format as well as existing links and a tool could be added to scan through all existing properties and convert links found into the new format to help migration from virtual directories.

Conversion from the reference format to a proper URL at run-time could be implemented before caching which would benefit performance and in the same time abstract the URL from the link.

[PonchoPowers]

We could create a new controller called RedirectController which redirects GUID's to pages.

We can then use the following in the CMS as the scheme:
<a href="/redirect/guid/01020304050607080910111213141516">Other page</a> (where 01020304050607080910111213141516 is the page GUID)

And then using a global action filter this can be changed to the following when output:

<a href="/other/page">Other page</a>

If someone was to manually visit /redirect/guid/01020304050607080910111213141516 they would be redirected to /other/page

As a side note, this provides the future opportunity of using the redirect controller for other things such as permalinks and tiny URL's if need be.

With what is currently stored in the database, I think it will be hard to write a tool that will covert URL's without any problems, there is an assumption within the CMS at the moment that if a path matches a path within the website it will be handled by a controller and action but this is not always the case but I think this should be logged as a separate issue.

[fschultz]

Using a redirect handler would be a good way to solve this in combination with converting the URLs in the earliest possible stage. Once I've finished the browser issue in 1.2.3 I will look into this more.

On a side note there's a couple of (not yet documented) features in the CMS that could be interesting to know about;

• There is existing support for tiny URLs through the ShortUrl property of any CMS page that generates paths initiated with a "!" followed by an encoded ID. This property only returns a relative path and the value returned needs to be prefixed with a domain/protocol, like "http://example.com/" + currentPage.ShortUrl
• In order to prevent any broken links due to renaming or moving pages, there's a redirect table that stores previous URLs and redirects to the current location. This feature could also be used for instance by inserting custom paths connected to particular pages.

[PonchoPowers]

We can't use any of the undocumented features because they are clearly there as there are links in the CMS and the redirects are likely going to be used already if a page has been renamed or pointed to another URL.

The RedirectController is preferable as it can be extended to allow redirects as mentioned, but to elaborate more, it can also be used to allow users to create pages within the CMS that redirect to another location. Useful for setting up navigation bars without having to host content under that path.

I've already done some work around this area, I'll send a PR to show you what I'm on about when I get a chance.