Relative URLs in WordPress

3 Views

I’ve always found it frustrating in WordPress that images, files, links, etc. are inserted into WordPress with an absolute URL instead of relative URL. A relative url is much more convenient for switching domain names, changing between http and https etc. Today I discovered that if you define WP_CONTENT_URL with a relative url then when you insert files into posts they use the relative url for the src instead of absolute url. Just what I’ve always wanted! But the official WordPress documentation says that you should use a full URI if you are defining WP_CONTENT_URL.

WordPress codex says:

Read More

Set WP_CONTENT_URL to the full URI of this directory (no trailing
slash), e.g. 

define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');

Everything seems to work fine when I use a relative URL, e.g. 

define( 'WP_CONTENT_URL', '/my-content-folder');

But is there some problem with using a relative URI? I’m just thinking that there must be a reason for WordPress stating that it should be defined with a full URI.

Post Views: 3

Related posts

Leave a Reply

6 comments

  1. 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.

  2. <?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

  3. 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.

  4. 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:

  5. 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.pdf’.

    I’m not sure if it makes all links relative, e.g. to posts, but at least it handles media, which probably is what most people are worried about.

  6. What i think you do is while you change domain names, the sql dump file that you have you can replace all instances of old domain name with new one. This is only option available as there are no plugins that will help you do this.

    This is quickest way ..