To fully remove WPML and its data you will need to go to WPML->Support->Troubleshooting->RESET WPML
This will wipe the database and remove any additional content created from WPML.
If anything is left such as page/post you will need to manually remove it. It seems that possibly WPML wasn't tracking these pages due to removing the old original language, there could of been a mix up in the database.
Hi – regarding this thread we have still persevered with WPML.
Having some success setting up new content for a new language. However the system has once again crashed. It seems to happen whilst trying to either edit a page 'independently' of a duplicate or if you try and delete a translated page. As you can see the site has hit a 404 error: hidden link . In the backend we get 'Updating failed. The response is not a valid JSON response.' upon trying to edit with Elementor on a page.
I can supply a login within a private reply. This glitch is worrying because the live site will do the same should our client try to repeat the actions above.
The issue is coming from your htaccess file, which is being rewritten with the directory within it
# BEGIN WordPress
# The directives (lines) between `BEGIN WordPress` and `END WordPress` are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /gb/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /gb/index.php [L]
</IfModule>
# END WordPress
Ah ok, thanks – although can you indicate how to fix the site now WPML has clashed with another plugin. Do we change something in htaccess file, or apply the temporary code to the functions php from the link you provided (why is this temporary?). We will need to find that third party culprit to ensure this doesn't happen to the live site. Are you able to advise?
1. Apply the code in the functions.php file of the theme
2. Fix the htaccess file, as it has /gb/ within it causing a redirection, you can see what a standard htaccess file should look like (NOTE: Just for the part of WP excluding the workforce additions)
Additionally, you can try to locate which third party plugin might cause this but the above steps will help you resolve the issue now.
If you locate the plugin then we recommend reaching out to their developers as this is not caused by our plugin, rather our plugin is affected by it along with the site.
That should fix that issue, and you can apply the same solution on the live site as well.
Thanks for the guidance Bobby. Although those procedures haven't resolved the staging site from being down. I wonder could this whole issue be down to an A record pointing incorrectly?.. to just the /gb site? Our client instructed the host previously so i'm wondering why the htaccess had changed.
The language url format (seen in the screenshot attached) isn't letting us click 'languages in directories', which i believe is what we need for the site. The client requires language code after the main url – ie, /gb or /au etc.
Although... reviewed the live site, the url format is set to 'language in directories' without the error message, and the htaccess file is as it should be. So potentially the test site is an isolated issue... but one that needs to be resolved because it will override the live site once fixed.
