Root Relative URLs
Plugin is truncating an external/remote URL (5 posts)

  1. GermanKiwi
    Posted 3 years ago #

    I'm using the excellent SlimStat plugin from http://wordpress.org/plugins/wp-slimstat/ along with Root Relative URLs.

    SlimStat loads a small .js file with each page load to collect analytics (similar to how Google Analytics works), and it also has an option for loading that .js file from a remote CDN server. When that option is enabled, the following line should be added to the source of each page:

    <script type='text/javascript' src='http://cdn.jsdelivr.net/wp-slimstat/3.2.1/wp-slimstat.js'></script>

    However, when Root Relative URLs is running, it seems to think this URL is a local one that needs truncating, and so the line is changed to this:

    <script type='text/javascript' src='/wp-slimstat/3.2.1/wp-slimstat.js'></script>

    Obviously this is incorrect, and it causes SlimStat to fail to work.

    Why is Root Relative URLs treating this URL as though it's local and in need of truncating? Can this be fixed please?



  2. Jason Crouse
    Posted 3 years ago #

    Thank you for troubleshooting this issue!


  3. GermanKiwi
    Posted 3 years ago #

    Hi Marcus,

    I've found another problem, similar to the above.

    On the Media Settings page, there is a field called "Full URL path to files" (at least if you're coming from WP 3.4 or older). This field lets you set a different URL for your media - for example, you could have your media files stored at http://www.example.com/media (ie. in the /media folder off your root location), but you could then create a subdomain like http://media.example.com which points directly to the /media folder, and you would enter that subdomain into the "Full URL path to files" field on the Media Settings page.

    However, in doing so, the Root Relative URLs plugin removes this subdomain (media.example.com) completely from the path of each media file, which makes each media (eg. each image) not visible.

    Eg. if I had an image located at /media/picture.jpg - that SHOULD be the correct "root relative" path for displaying it in the Media Library. However, when I change the "Full URL path to files" to "media.example.com", the image path then gets changed by your plugin to simply "picture.jpg" instead of "http://image.example.com/picture.jpg" which it should be now using. The plugin should not truncate this URL because it's not the main URL - it's a subdomain - and the whole point of having an alternative domain for the media is so that the full URL can be used in that case (there are apparently some speed benefits of using an alternative URL for the media files).

    I've tried adding http://media.example.com to the RRU blacklist, but that doesn't help.

    Can this be fixed please?! :)


  4. wp_timmiller
    Posted 3 years ago #

    The first problem can be fixed by adding a single line of code to the top of the proper_root_relative_url function:

    if (stripos($url, @$_SERVER['HTTP_HOST']) === false) return $url;

    This prevents the function from monkeying with any URL that is not internal to the site. This should fix the second problem as well, but I haven't tested it. I'm not sure if this is the best solution, but it should at least provide people a work-around until the plugin author implements a fix.


  5. mark_at_kaazing
    Posted 3 years ago #

    I've run into a similar issue for these URLs:


    I attempted to use the Blacklist function for URLs (briefly mentioned in http://plugins.svn.wordpress.org/root-relative-urls/trunk/readme.txt) which points you to: /wordpress/wp-admin/options-general.php or WP Admin: Settings > General

    Scroll down to see the Root Relative Blacklist text area, which has a label with some more instructions.

    My attempts to add these Blacklist URLs did not trigger immunity from Root Relative URLs, sadly:


Topic Closed

This topic has been closed to new replies.

About this Plugin

  • Root Relative URLs
  • Frequently Asked Questions
  • Support Threads
  • Reviews

About this Topic


No tags yet.