Relative links can generate "Permission restrictions deny you access to this broken link." [#2264181]

If your site can be accessed via multiple URLs (like example.com, www.example.com) then relative links (like /node/1 ) will generated the "Permission restrictions deny you access to this broken link." error in the broken links report when you access the page from a different host than when the page with the link was scanned (and the link is broken).

It looks like the basic problem is that linkchecker is converting relative/local links to absolute links, and checking those. When generating the Broken Link report, it checks that the link is still on the page (comments say to avoid information linkage in case the page changed with a permission change). If the report was accessed from a different host name then when the links were checked, the conversion to absolute links will differ, and the before mentioned error results.

It would seem that linkchecker could save the link as a relative URL (probably relative to the sites Base URL) these false permission errors could be eliminated. It might be needed to keep both the relative and absolute URLs.

Comments

Comment #1

hass CreditAttribution: hass commented 11 May 2014 at 19:15

Category:	Bug report	» Support request
Status:	Active	» Fixed

This is a known issue. See the readme and set your base url variable, please.

Comment #2

Richard Damon CreditAttribution: Richard Damon commented 11 May 2014 at 21:14

My issue isn't what the README describes, but it does seem to fix the problem. Cron isn't having the problem, and in fact Cron.php is being accessed over the internet from another machine, so it is using a real URL.

I will have to document that I have done this, as it will require a new step in my normal work flow of bringing up new major versions of my sites,
1) Start with site at example.com and www.example.com (because some people just assume you need the www)
2) Build new version of site at new.example.com, keeping old site still running. (perhaps starting from a clone of the site).
3) shortly before being ready to switch, and as an alias to original version, old.example.com
4) Test that old.example.com still works and links keep you on old.example.com (i.e., find any local links that weren't made relative).
5) Perform any last minute migration from old to new.
6) When ready to release, change example.com and www.example.com to the root of new.example.com

I will need to change settings.php when I change domain names, and testing old.example.com will be harder, unless I let Drupal to start to kick people over to old.

Comment #3

hass CreditAttribution: hass commented 13 May 2014 at 09:23

I strongly suggest to run pathologic and for ckeditor the internal link plugin... That saves you 98% of the headaches moving/switching between dev/staging/production systems.