.htaccess
is unlikely to be sufficient (of course, in principle .htaccess
is just a place for local configuration, it depends on which modules are available too).
EDIT: (more details on why mod_rewrite
/redirect) doesn't work)
Assuming that by .htaccess
you're referring to the usual mod_rewrite
/redirect directives, this will not work because the browser will be redirected, so the actual (redirected) URL will be visible in the location bar (http://mydomain.com/clientsdomain.com/wordpress
), not the one initially requested (http://clientsdomain.com/
).
Redirect
and RedirectMatch
will of course perform an external redirection: this will not maintain the old domain in the URL as requested.
mod_rewrite
and RewriteRule
provide two options for external links (see table at the end of the documentation (and the documentation about the flags):
^localpath(.*) http://otherhost/otherpath$1
http://otherhost/otherpath/pathinfo
via external redirection
^localpath(.*) http://otherhost/otherpath$1 [R]
http://otherhost/otherpath/pathinfo
via external redirection (the [R]
flag is redundant)
^localpath(.*) http://otherhost/otherpath$1 [P]
http://otherhost/otherpath/pathinfo
via internal proxy
The external redirection option (no flag or [R]
) will be equivalent to Redirect
and cause the URL in the address bar to change.
The internal proxy option ([P]
) will not cause the URL in the address bar to change, but, unless the server behind the internal proxy is aware it needs to change the base URLs in the links it serves, this will cause problems with the links embedded within the page (this is what mod_proxy_html
can address).
There are at least two possible options to keep the requested URL in the location bar:
iframe
Keeping the original URL is typically done with an iframe
. You could write a quick script (e.g. in PHP) that takes a URL (or part of it) as a query parameter.
For example, http://clientsdomain.com/redirect.php?location=some/page
would create a page simply containing an iframe for http://mydomain.com/clientsdomain.com/wordpress/some/page
. To make all the pages redirect from http://clientsdomain.com/
, you could use a rewrite in .htaccess
to redirect.php?$1
.
In this context, http://clientsdomain.com/some/page
would be rewritten as http://clientsdomain.com/redirect.php?location=some/page
, which would contain an iframe pointing to http://mydomain.com/clientsdomain.com/wordpress/some/page
.
One of the downsides is that, whenever a user clicks on a link the location bar will not change. It might also confuse some JavaScript scripts relying on the fragment (#
).
mod_proxy_html
Another solution, possibly harder to install especially if you're on a shared host, would be to use mod_proxy_html
to reverse proxy http://clientsdomain.com/
to http://mydomain.com/clientsdomain.com/wordpress
.
This might be doable with .htaccess
only (provided the module is installed), but I'm not sure: it depends whether its configuration directives are allowed in .htaccess
or need to be in the global configuration. Either way, you'll almost certainly need full access to the Apache Httpd installation to configure this, so whether it's in .htaccess
or in one of the main config files shouldn't really matter at this stage.
(A plain reverse proxy with mod_proxy_http
without mod_proxy_html
would allow you to proxy the requests, but wouldn't replace the links within the pages.)
Adding to this, you'll probably need mod_header
on top of this (with any of the mod_proxy_*
). The Location
headers are absolute URLs according to the HTTP specification, so any redirect sent by the proxied server to itself (even simply for adding a trailing slash, for example) will have absolute URLs to itself. You can fix this problem using something along these lines (check whether the regexp and paths are correct when deploying):
Header edit Location ^http://mydomain.com/clientsdomain.com/wordpress http://clientsdomain.com/
(This being said, if the target Wordpress server is not to be used with its initial address, there may be an option or plugin to set its base URL to the new one, which could make mod_proxy
handling easier.)