You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we are using subdomains there are a few challenges. The default WordPress needs to be configured for a set, single url. Practically speaking this means we need to make some decisions about how to approach this.
Option 1) Add a proxy that handles the multiple domains and sets a single domain for WordPress. The downside here is that the other domains will only be visible to the client. Backend processes like prerender will not be aware of the different domains. If backend processes are not required, this is not an issue as most of the plugin works solely from the client.
There's a few workarounds in this case. You will need to pass the language code from the proxy. This means that language code detection HAS to occur on the proxy. Then it can be passed back to WordPress as a query param or a header (if done as a header...be aware of any proxies that might interfere with this).
Option 2) Add all of the domains directly on WordPress. This allows for the most granular configuration however also means that WordPress has to be aware of these domains. The best way todo this is to use WordPress multisite. If all of the sites are localized subdomains, the plugin can be network activated.
There's a few workarounds in this case. If you want to avoid a full WPMU setup, there are a couple of hack approaches by either making the WP configuration dynamic (adds a security risk) or by using a relative path (this could cause backend issues if a FQDN is expected).
The text was updated successfully, but these errors were encountered:
When we are using subdomains there are a few challenges. The default WordPress needs to be configured for a set, single url. Practically speaking this means we need to make some decisions about how to approach this.
Option 1) Add a proxy that handles the multiple domains and sets a single domain for WordPress. The downside here is that the other domains will only be visible to the client. Backend processes like prerender will not be aware of the different domains. If backend processes are not required, this is not an issue as most of the plugin works solely from the client.
There's a few workarounds in this case. You will need to pass the language code from the proxy. This means that language code detection HAS to occur on the proxy. Then it can be passed back to WordPress as a query param or a header (if done as a header...be aware of any proxies that might interfere with this).
Option 2) Add all of the domains directly on WordPress. This allows for the most granular configuration however also means that WordPress has to be aware of these domains. The best way todo this is to use WordPress multisite. If all of the sites are localized subdomains, the plugin can be network activated.
There's a few workarounds in this case. If you want to avoid a full WPMU setup, there are a couple of hack approaches by either making the WP configuration dynamic (adds a security risk) or by using a relative path (this could cause backend issues if a FQDN is expected).
The text was updated successfully, but these errors were encountered: