Compatibility with wpml

[262media]

I can't make this play along with wpml. maybe because wpml creates virtual directories(ex: /fr/ , /pt/ don't really exist on the server) or any other issue ...
But the fact is that my 301 redirects that include one of this virtual directories results in a 404.
I'm using NGINX (powered by trellis and bedrock).

Anyone have a clue?
Thanks in advance
Rui

[braders]

We have recently had to solve this problem. We found there were 3 steps required to get this working properly:

• We setup the redirects CPT as a translatable post type, and redirects were added to the correct language. When adding the redirects for a subdomain language the language code was commited (e.g. for example.com/es/ the /es/ part was ommited from the redirect paths).
• SRM assumes that subdomain installations will not have a trailing slash when using home_url, whereas WPML will add a trailing slash. We had to use the srm_registered_redirects filter to intentionally break the URL normalisation. (We also used this filter to add proper support for escaped characters, such as Chinese or Japanese kanji)
• Lastly, we had to use WP filters so that the _srm_redirects transient was stored internally as different transients per language. (specifically with the pre_set_transient__srm_redirects, transient__srm_redirects and delete_transient__srm_redirects) filters.

[chelder86]

Same issue here (WPML is very popular!). Could you share the exact code to add to functions.php please? It would be incredible helpful for me...

[teachmeter]

Plugin version: 1.10.0

I've had a simmilar issue.
We are using WPML + some custom rewrite rules. The plugin works as expected and catches a link like
/example/some-slug but it has problems with /fr/otherexample/some-other-slug

to actually fix it I've frozen the plugin source for our case and applied this piece of code in class-srm-redirect.php

$matchesLangCode = preg_match('/^(\/[a-zA-Z]{2}\/)$/m', $parsed_home_url['path']) === 1;
if ( isset( $parsed_home_url['path'] ) && '/' !== $parsed_home_url['path'] && ! $matchesLangCode ) {
    $requested_path = preg_replace( '@' . $parsed_home_url['path'] . '@i', '', $requested_path, 1 );
}

Basically what it does is to not fully delete the requested path if it has a language code.

Otherwise the $requested_path for /fr/something/else becomes empty and it doesn't match properly as it searches something/else/ instead of /fr/something/else which is stored in the db.

I haven't run any tests for it or thoroughly check other cases but this might be a hint for somebody else.

[jeffpaul]

@CPROps @jameswburke looks like you may have crafted a downstream fix, mind pushing that upstream here for others to benefit from?

[slothluvchunk]

@jeffpaul - We (CPR) don't have a downstream fork of this repo that I can see, but it's possible that we inherited something along the way. You may want to check with whomever is maintaining AlleyInteractive's fork.