Under Settings => Media, there's an option for 'Full URL-path for files'. If you set this to the default media directory path '/wp-content/uploads' instead of blank, it will insert relative paths e.g. '/wp-content/uploads/2020/06/document.
Rather than including the entire URL for each page you link, relative URLs cut down on the workload and time needed. For example, coding /about/ is much faster than https://www.example.com/about .
Internally WordPress requires absolute URLs in certain areas and processing this is considered a potential area to introduce programming bugs. an accidental link to a test environment version of your site can lead to duplicate content issues by accidentally indexing your test site.
To link pages using relative URL in HTML, use the <a> tag with href attribute. Relative URL is used to add a link to a page on the website. For example, /contact, /about_team, etc.
I think this is the kind of question only a core developer could/should answer. I've researched and found the core ticket #17048: URLs delivered to the browser should be root-relative. Where we can find the reasons explained by Andrew Nacin, lead core developer. He also links to this [wp-hackers] thread. On both those links, these are the key quotes on why WP doesn't use relative URLs:
Core ticket:
Root-relative URLs aren't really proper.
/path/
might not be WordPress, it might be outside of the install. So really it's not much different than an absolute URL.Any relative URLs also make it significantly more difficult to perform transformations when the install is moved. The find-replace is going to be necessary in most situations, and having an absolute URL is ironically more portable for those reasons.
absolute URLs are needed in numerous other places. Needing to add these in conditionally will add to processing, as well as introduce potential bugs (and incompatibilities with plugins).
[wp-hackers] thread
Relative to what, I'm not sure, as WordPress is often in a subdirectory, which means we'll always need to process the content to then add in the rest of the path. This introduces overhead.
Keep in mind that there are two types of relative URLs, with and without the leading slash. Both have caveats that make this impossible to properly implement.
WordPress should (and does) store absolute URLs. This requires no pre-processing of content, no overhead, no ambiguity. If you need to relocate, it is a global find-replace in the database.
And, on a personal note, more than once I've found theme and plugins bad coded that simply break when WP_CONTENT_URL
is defined.
They don't know this can be set and assume that this is true: WP.URL/wp-content/WhatEver, and it's not always the case. And something will break along the way.
The plugin Relative URLs (linked in edse's Answer), applies the function wp_make_link_relative
in a series of filters in the action hook template_redirect
. It's quite a simple code and seems a nice option.
<?php wp_make_link_relative( $link ) ?>
Convert full URL paths to relative paths.
Removes the http or https protocols and the domain. Keeps the path '/' at the beginning, so it isn't a true relative link, but from the web root base.
Reference: Wordpress Codex
I agree with Rup. I guess the main reason is to avoid confusion on relative paths. I think wordpress can work from scratch with relative paths but the problem might come when using multiple plugins, how the theme is configured etc.
I've once used this plugin for relative paths, when working on testing servers:
Root Relative URLs
Converts all URLs to root-relative URLs for hosting the same site on multiple IPs, easier production migration and better mobile device testing.
I solved it in my site making this in functions.php
add_action("template_redirect", "start_buffer");
add_action("shutdown", "end_buffer", 999);
function filter_buffer($buffer) {
$buffer = replace_insecure_links($buffer);
return $buffer;
}
function start_buffer(){
ob_start("filter_buffer");
}
function end_buffer(){
if (ob_get_length()) ob_end_flush();
}
function replace_insecure_links($str) {
$str = str_replace ( array("http://www.yoursite.com/", "https://www.yoursite.com/") , array("/", "/"), $str);
return apply_filters("rsssl_fixer_output", $str);
}
I took part of one plugin, cut it into pieces and make this. It replaced ALL links in my site (menus, css, scripts etc.) and everything was working.
I have always just used get_site_url()
. For example:
<img src="<?=get_site_url(); ?>/wp-content/uploads/2021/05/[email protected]" />
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With