Multilingual Website with different domain/folder structures and sharing content

You should avoid having redundant data that needs to be synced. It is possible to dynamically set the site’s domain name for every request by adding code to wp-config.php that defines WP_HOME and WP_SITEURL constants with the requested domain name, taken from $_SERVER data such as “HTTP_HOST”. For security, the domains allowed to be used this way must be whitelisted.

By doing this, you can have a single installation respond to different domain requests, appearing to be different sites with identical content without the need to sync data.

Getting different headers and footers to be used based on the current domain name is also possible, but doing so does require customizing your theme’s templates. Customized templates are best implemented in a child theme that you can create.

The suggestion to solve everything in a WordPress instance and to do without synchronisation sounds very good to us. Is that feasible with Elementor?

Is there a code example that we could use to get to grips with the issue? At the moment, it is completely unclear to us how we should solve this exactly and which requirements have to be met on the server beforehand so that we can translate the page and then have it delivered to the users via the dynamic domain.

I don’t know Elementor very well. I’m pretty sure it’ll be fine though. Any media inserted into content will have the domain of whatever is current at insertion time, regardless of which domain is subsequently used to view the content. Browsers will see this as cross site requests, so you might need an appropriate Content Security Policy (CSP) header indicating that this is OK to do. WP doesn’t typically send a CSP header, so it might be unnecessary. If needed, one can be added via the “wp_headers” filter. To be clear, these are HTTP headers, not to be confused with a web page’s header.

There used to be good dynamic domain code in the Codex, but that particular page is no longer available. This accepted SO answer is the gist of it, but as I mentioned, the $_SERVER[‘HTTP_HOST’] value should be checked against a whitelist for better security.

Themes typically load header templates (a web page header now, not HTTP headers ?? ) with get_header(). In the user notes towards the bottom of the linked page, there’s an example on how to load different headers based on a condition. In your case the condition would be the value of WP_HOME. A PHP switch/case structure is good for matching a number of possible conditions. Better IMO than the if/else logic in the example. A similar concept can be used for the get_footer() call.

If your theme is subject to periodic updates, you should introduce customized template code via a child theme.

We were able to set up a test environment where two domains point to the same wordpress instance. This also works wonderfully with Elementor.

Using our own shortcode, we can read the variable $_SERVER[‘HTTP_HOST’] in the Elementor header in a similar way to what has already been described and insert the appropriate header template accordingly (with another shortcode to load the corresponding Elementor templates).

This already solves many points on our list of problems.

At the moment, we still have the question of how we can make it so that the English-language content of the main domain can be displayed when calling the co.uk domain without requiring a directory in the URL. At the moment, the page is called up via domain.co.uk/en, but we would like the page to be called up via domain.co.uk. We use Translatepress for translation. However, we were told by the plugin developer that the plugin is not compatible with this requirement.

Is there a suggestion for solving this problem? Or a suggestion for a translation plugin that we can use instead of Translatepress and that could meet our requirements?

• This reply was modified 2 years, 3 months ago by Hingucker GmbH.

I don’t know TranslatePress (TP) at all, but I have some thoughts on what might work.

Maybe give TP what it wants internally, but leaving the browser address as you would prefer? A relative rewrite rule in .htaccess should do that. Similar to how the default WP rewrite rule goes to index.php, yet the browser address remains the requested permalink.

The difference is WP makes no attempt to capture the permalink in its rewrite (it gets the permalink from other $_SERVER data). In your case, you’d capture the requested permalink and insert an “en/” in front of it if the request involves the .co.uk domain.

This might not work if TP also takes its cues from $_SERVER like WP does. If that’s the case, look in its source code to see where it’s getting the requested URL. In the same wp-config.php code where you define WP_HOME etc., alter the $_SERVER value used by prepending “en/” to it.

Another possibility is outright set the query var that TP would eventually use. Try using the “request” filter to discern what that query var is and cause it to be set for English any time WP_HOME’s value is the .co.uk domain. Hook this filter with a very large $priority arg just in case TP is also hooked into the same filter. This give TP a chance to do what it thinks it should do before you override it.