[wp-trac] [WordPress Trac] #17048: URLs delivered to the browser should be root-relative

[WordPress Trac]

#17048: URLs delivered to the browser should be root-relative
-----------------------------+-----------------------
 Reporter:  dmole            |       Owner:  edwardw
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:
Component:  General          |     Version:  3.1
 Severity:  normal           |  Resolution:
 Keywords:  close            |
-----------------------------+-----------------------

Comment (by dd32):

 Replying to [comment:29 dmole]:
 > Replying to [comment:28 dd32]:
 > > ... You'd be far better off implementing this as a plugin...
 >
 > It this actually within the reach of a plugin?

 Definately is possible, although not using your current approach of
 flaging at call time whether it's a link type that can have a root
 relative link, Using the methods i mentioned (see below)

 > > One example for reasons a absolute url is easier, is when moving the
 site to another domain, You can simply replace all the site url's. With
 this solution, You can't reliably move it between directories,
 >
 > This is wrong; please see comment# 3, or provide an example.
 >

 Original: http://clients.dd32.id.au/client1/; New: http://client.com.au/

 Original: http://client.com.au/; New: http://clients.dd32.id.au/client3/

 > > Long story short, to me, It's not a problem that needs fixing, In the
 sense, that there are other solutions available already which fill the
 needs mentioned in this ticket. the output buffering items mentioned above
 are one method,
 >
 > As mentioned the output buffering is not a solution, if you have a
 method that addresses comment# 14:
 >
 > 'with more testing it becomes clear that the ob_start options are
 unusable because it misses headers like those used in redirects to wp-
 login.php, and it gets urls it should not like the "siteurl" setting
 itself.'

 Redirects and url's within emails are not captured by output buffers.

 > >my favourite method is to dynamically define WP_SITEURL/WP_HOME, or
 filter the siteurl option, or filter the
 site_url()/admin_url()/includes_url()/home_url() returns to respect the
 current hostname, etc.. there's always a method which suits the
 site/environment in question.
 >
 > I'm not sure how one would do this can you provide an example?
 {{{
 add_filter('site_url', function($url) {
  if ( /* some logic to tell if you want to apply to this url, ie.
 whitelisted/blacklisted url endpoints, or apply to specific-type link
 hooks (they all have a hook) instead of site_url */ ) {
    $url_parts = parse_url($url);
    $url = $url_parts['path'] . (array_key_exists('query',$url_parts) ?
 '?'.$url_parts['query'] : '');
  }
  return $url;
 });
 }}}
 (Yes, That, in it's current form would apply to redirects and emails too.
 Perhaps you'd be best to check to see if the page is currently being
 output, ie. if ( did_action('wp_head') ), or language_attributes action,
 or similar)

 If it's just different domains you want, and all generated links need to
 be domain-specific, You can do something like the following (I use it in
 conjuction with a few specific filters on some link generation types, from
 memory, i filter the themes and uploads (uploads to a CDN, themes to a
 common domain, static files from the theme to a CDN domain)) :
 {{{
 define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/');
 define('WP_HOME', 'http://' . $_SERVER['SERVER_NAME'] . '/');
 define('WP_CONTENT_URL', 'http://' . $_SERVER['SERVER_NAME'] . '/wp-
 content');
 // Add WP_PLUGINS_URL, THEMES URL, whatever else your particular setup
 needs
 }}}

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17048#comment:30>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software