I have finished updating the CMSMS and PHP environment (phew) but came across some weird redirect behaviour which I suspect is due to a poor implementation of absolute/relative URL resolution behind the {redirect_url} plugin
The basic steps to reproduce are
1. create a second-level content of type URL redirect, with a relative URL slug, to, say, a PDF file on the server.
2. Observe that the resulting link generated by Navigator works perfectly, with a DIRECT link to the pdf file - ie the actual URL of the redirect object itself is completely bypassed.
3. However, try manually navigating to the URL of the redirect object. This should still work - and I think navigator should probably resolve via this URL in any event. But the redirect fails, since the redirect is then resolved to an URL using the LOCATION of the redirect object as the base.
However, the relative URL slugs should (I expect) be resolved using the {root_url} as the base.
Further effects of this issue can be seen, for instance, by creating a redirect content to a mailto: protocol. Again, this fails since the redirect does not recognise this is an absolute url, and attempts to construct an url using the location of the redirect object as the base.
I've cunningly got around this for the time being by creating a new template with essentially the following content:
Code: Select all
{$resource_url="{content label='URL of resource' oneline='true'}"}
{if "{$resource_url|parse_url:PHP_URL_HOST}" || "{$resource_url|parse_url:PHP_URL_SCHEME}"}
{redirect_302 to="{$resource_url}"}
{else}
{redirect_302 to="{root_url}/{$resource_url}"}
{/if}
However a permanent solution would obviously be preferable:)