[Resolved] Add trailing slash to standard language hreflang url

Hello and thank you for contacting us.

If I have understood you correctly here, the changes that you want to implement are to the default language URL and you want it to be slashed for the hreflang entries.

We already are aware of such a problem and I have a workaround that you could potentially try - do remember to make backup first.

in wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php - the method: \SitePress::language_url
change from:

	function language_url( $code = null ) {
		global $wpml_url_converter;

		if ( is_null( $code ) ) {
			$code = $this->this_lang;
		}

		$abs_home = $wpml_url_converter->get_abs_home();
		$url      = $this->convert_url( $abs_home, $code );

		return $url;
	}

change to:

	function language_url( $code = null ) {
		global $wpml_url_converter;

		if ( is_null( $code ) ) {
			$code = $this->this_lang;
		}

		$abs_home = trailingslashit($wpml_url_converter->get_abs_home());
		$url      = $this->convert_url( $abs_home, $code );

		return $url;
	}

Hi there.

Our developers are already aware of this issue, as my colleague confirmed above, and there is already an internal ticket where they are working on fixing this and deploying the fix in a future update.

This fix might come in WPML 4.6.9 but I can't guarantee it. When exactly our developers will release an update including the required feature is not up to us, the Supporters, to determine.

Each issue reported is taken seriously into consideration. It is given a high or low priority based on several factors, factors which those with the overview of all things related are in the best position to determine.

What I can guarantee for now is that implementing this change in the code that was recommended above won't affect the site or its functionality in any way and you are already using the latest version that we have available.

The only thing to keep in mind is that, if you update it to a newer version (when one becomes available), the old code will be overwritten so you will have to add it again in the code, in case the fix is not coming with that plugin version, too.

Unfortunately, I don't know of any plans to have this code rewritten so that it could be used as a hook/filter in your theme.

The workaround shared above by my colleague is the only one existing at the moment and when there's an issue, usually that's what our team does: they create a workaround like this one, that can be added to our plugin's code and that fixes the issue until they release a fix in an upcoming version.

I hope that you will find this information helpful.

Mihai