Replace absolute links with relative links

[ghost]

This is a trivial issue that I should have realized much earlier. Copy and pasting links "as it is" i.e. from the address bar works, but this will cause broken links when repo transfer is made in the future.

I hope to replace all absolute links with relative links instead.

Justifications

It is known that GitHub automatically redirects those invalid URL from old_username/repository to new_username/repository. No further action is needed. But the appearance of link remain to appear "as it is" with old_username/repository, which might confuse users.

The affected files including README.md in the repository and pages on Wiki (Sigh, documentation clean up again... my mistake anyway). I will probably update to relative links in master branch only.

The difference

To understand the difference between the two types of link, see the following examples.

Write: [absolute link](https://github.com/clearkimura/Customizer/issues/126) or
Write: https://github.com/clearkimura/Customizer/issues/126

Result: absolute link or #126

Write: [relative link](126) or
Write: #126

Result: relative link or #126

Thanks to GitHub, the results are indistinguishable (Hover your mouse over the links to see any difference; There isn't any). Except, when repo transfer takes place, the relative link will be updated automatically with username of new owner. In contrast, the absolute link will show the same URL thus, rendered invalid and will be redirected to correct URL (misleading and delayed page visit).

The limitation

One thing to be careful is to ensure that the keywords are relevant to the relative link you wish to create. For example, this issue 126 is located at .../issues path of URL and this is why just typing 126 will result as .../issues/126 in the generated link.

Another way is to write #126 that will result as .../issues/126 in the generated link. Always preview the resulting text before applying the update.

However, writing with the same keyword 126 or #126 at somewhere else i.e. Wiki and repository won't give the same result. In either case, the result will be #126 in plain text. For linking from the repository, use either absolute link or relative link as one would normally do.

Must use relative links only in Wiki and future release 4.2.0.

[ghost]

Created Test page on Wiki for testing purpose.

Based on what I have tested by trials and errors, I have summarized the results into the following usage of relative links used in GitHub Wiki, GitHub Issues and Repository.

Relative links in GitHub Wiki

[126]: ./../issues/126
[Wiki]: ./../wiki
[contributing]: ./../blob/master/CONTRIBUTING.md

• From wiki to issues, use ./../ (dot, slash, two-dots, slash).
• From wiki to wiki, use same as precending.
• From wiki to repository, use same as preceding with additional blob/branchname.

Relative links in GitHub Issues

[126]: 126
[Wiki]: ./../wiki
[contributing]: ./../blob/master/CONTRIBUTING.md

For working relative links in this page:

126 or #126 ... links to #126
Wiki ................ links to https://github.com/clearkimura/Customizer/wiki
contributing .... links to https://github.com/clearkimura/Customizer/blob/master/CONTRIBUTING.md

• From issues to issues, use issue_number or #issue_number without link syntax.
• From issues to wiki, use ./../ (dot, slash, two-dots, slash).
• From issues to repository, same as preceding.

Relative links in GitHub Repository

[126]: /../../issues/126
[Wiki]: /../../wiki
[graphs/contributors]: /../../graphs/contributors
[contributing]: ../../master/CONTRIBUTING.md

• From repository to issues, use /../../ (slash, two-dots, slash, two-dots, slash). --- untested
• From repository to wiki, same as preceding.
• From repository to repository, use ../../ (two-dots, slash, two-dots, slash); this doesn't seem to require blob/branchname.

Whew, that took some time and efforts to discover and understand by myself. All relative links noted in this comment are valid as 2017.01.03.

P.S.: This is tricky! There may be corrections from time to time.

P.S.S.: Culprit: "Preview" gives false result. This will easily deceive and confuses you that you have made the "correct" edit. Don't trust "preview" when updating relative links!

[ghost]

@fluxer @kamilion
Mentioned for quick reference of relative links on GitHub. Besides relative links in readmes, I have not found any official documentation by GitHub to this date. See my findings in earlier comment above.

[ghost]

This issue shall be closed, because "old stable" will be deprecated. Links have been fixed in repository, but not in Wiki. No longer relevant anyways.