Overview of the Issue
Before 4.0.0, WPML attempted to have the trailing slash match the incoming URL during the conversion. Unfortunately, this logic is not adapted for all cases.
Starting from 4.0.0, the converted URL will match the standard WordPress behavior which is as follow:
- When there’s no path and no query, WPML will try to match the incoming URL (e.g. http://wpml.com => http://wpml.fr, or http://wpml.com/ => http://wpml.fr/). However, WordPress usually outputs the home URL without any trailing slash.
- When there’s no path but there’s a query, we will always have a trailing slash (e.g. http://wpml.com?foo=bar => http://wpml.fr/?foo=bar).
- When we have a path (not a file), the trailing slash depends on the permalink format.
- When we have a path pointing to a file, no trailing slash should be added (regardless of the permalink format). Example: http://wpml.com/wp-content/uploads/hello.csv.
Workaround
This issue is fixed. Updating to the latest version solves it on your site, so you only need this workaround if you can’t update yet.
This change can have some unexpected side effects in themes or 3rd part plugins.
We strongly advise avoiding string concatenation to build URLs and make use of functions like:
- add_query_arg (opens in a new tab) to build the URL query.
- http_build_url (opens in a new tab) if this function is available on the server (however WPML provides a polyfill).
- trailingslashit (opens in a new tab), untrailingslashit (opens in a new tab) to add or remove trailing slashes.
For example, the following code:
$url = get_home_url() . '/' . $path;
Should be replaced by:
$url = trailingslashit( get_home_url() ) . $path;
Still Seeing This Issue?
If updating doesn’t fix it, ask a support question and we’ll look into it with you.
Ask a support question