I have five domains pointing to the same server/wp installation. the domain names are important and my visitors need to be able to stay on their preferred domain as they surf through my site.
how do I set up wp (or .htaccess or…) so that links all point to the domain/host specified by the visitor?
right now, if I set Dashboard/General/Site Address to site-A.com, and I load the site as site-B.com, the links still point to site-A.com instead of site-B.com; eg, load http://site-B.com/blog/this-is-my-home/
. the links within the loaded page still point to site-A.com instead of site-B.com.
in my old MT system, I was able to define all links as root-relative, so the links all pointed to the current domain. is this possible with WP?
cheers,
Gregory
I tracked the function calls in my theme (a child theme of Oenology by Chip Bennett) and wp-include that generate the links, found the
home_url()
function, and then wrote these functions for my site:I intentionally grep-searched to include the / after the domain so that I could still use
home_url('')
to return the Blog’s specified domain, and specify true canonical url’s to that domain in the<head>
via WordPress SEO using the following functions (i.e., the canonical links will be the same regardless of the domain used to load the page; i.e., no ‘duplicate content’):so far, it works really well but I wonder if it’ll adversely affect Feeds or the e-Commerce solution I eventually implement. comments, notes, tips, warnings are welcome 🙂
Update
a simple
home_url()
(i.e., no path specified) is used throughout the system, so the trailing / in the grep-search couldn’t be used. I had to remove it and find another way to specify the domain in the canonical url’s. so, a little more research through wp-includes, and now the functions look like this:Update 2
it’s harder than it first appeared 😉 my code now looks like this. feeds are affected.
somewhere in the chain of functions that produces the links, feeds seems to be using _SERVER[‘HTTP_HOST’].I’ll have to examine my options there.Update 3 — WPSEO
there’s an option in WPSEO to add text/links before and after RSS posts including the option to use placeholders. one of those placeholders is
%%BLOGLINK%%
. unfortunately, with the root-relative filters in place, %%BLOGLINK%% produced an empty string which was not useful in the feeds. this code fixes that problem (noting that my other choice was to simply hardcode the link in WPSEO’s RSS settings, probably the smarter thing to do 🙂(I have since decided to hardcode my RSS after-post message, so the above filter has been disabled in my theme.)
Update 4 — preg_replace() becomes preg_match()
I’ve updated the
gregory_make_stylehref_relative()
function shown in Update 2 to usepreg_match()
instead ofpreg_replace()
. this is the old code:Update 5 — get_avatar()
another filter, this time for get_avatar() so that the schema and current domain are included in the path to wp’s blank.gif. without these, the gif won’t be found and loaded. without the schema, Gravatar will load it’s own corporate avatar instead.
Update 6 — redirect_canonical()
the filters were causing problems with incoming url’s that involved query strings. the url’s
scheme://domain
would get chopped to just://domain
. it took a few hours to pinpoint the problem, but it was in wp-includes/canonical.php::redirect_canonical() and a filter hook there made it possible to correct the problem. here’s the filter:please note that I have not marked my question as answered just yet, because I don’t know what consequences these filters will have further down the road. more time and testing is required.
cheers,
Gregory
(WordPress 3.3.2)
Reverting to absolute url’s
Implementing root-relative url’s was pretty much doable, but complicated because WP was written to use absolute url’s and expects absolute url’s. I realised that all I wanted was for people visiting my site to be able to see all links using the same domain as the one they specified. This didn’t mandate using root-relative url’s. So I’ve rewritten the code to replace the domains in all relevant url’s with the domain specified by the visitor. The complete code is much simpler!
cheers,
Gregory
(WordPress 3.4.2)