Changes in the way WPML handles the trailing slashes in URL conversion

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 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 to build the URL query.
• http_build_url if this function is available on the server (however WPML provides a polyfill).
• trailingslashit, untrailingslashit 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;