I have two problems.
1. In the backend and on uncached frontend pages the performance is terrible. Some pages take up to >30s to load. After careful profiling it is clear that WPML is causing the problems. What could be wrong?
2. Language switching is very slow. When clicked, it can take up to 15 seconds before the redirect even starts, and the visitor gets no indication that the page is loading or that the click has even occurred. What could be wrong?
All plugins are updated, all WPML requirements are met, WP core is updated.
I visited your site. I noticed that switching language to navigate the load times were very long, whereas accessing the same pages directly they loaded very promptly. Checking the browser network requests I see that a ajax request made when clicking the language switcher results—eventually—in a 400 bad request, which accounts for the different loading times depending on how you arrive at a page.
I don't know the cause of that, I'm going to run some tests locally in a similar setup (with different domains for each language) to see what to expect.
Otherwise, the only thing that I note from your debug info is that the memory allocated to WordPress (128M) could be higher, but while that would likely improve performance it wouldn't be transformative.
I'll get back to you when I've done a little more testing.
OK, I can see how it is supposed to work on my local site, and from the plugin code it looks like the language switcher ajax request is failing because of a nonce problem, and I'll need to look into your site to see if I can determine why.
Would it be possible to get access to the back end, and may I add some plugins to aid with debugging the issue? (I can also look at the back-end performance at the same time.)
Let me mark your next reply as private so that I can get log-in credentials from you—you may want to create a temporary admin user for me to use that you can later delete. And be sure to have a current backup of your site.
I see that you are using an atypical set up for WordPress.
I was intending to activate debug logging so that I could modify some of the WPML plugin code just to dump some vars to the log so that I can track what is happening with that particular code. (If I was working on a local copy of the site I'd be using Xdebug to step through the code execution, but that it arduous on remote servers.)
While I can see how your configuration files are set up for the different environments, I don't really want to go editing these myself in such a set up, particularly the production environment configuration.
Could you do that for me? Turn on debug mode for the environment I have access to (production), and confirm where I'll be able to find the resulting wp-debug.log file?
(If you have a staging or development environment where I can see the same issue, naturally that would be better.)
Also, in general the experience in the back end has been very zippy, the pages are quick to load. Do you have examples of some specific pages that are problematic that I should look at?
And, I agree, the speed in backend is good now. This morning, I switched the PHP version back and forth witch seems to have "cured" the backend. Maybe some proceses that where causing this got interupted.
Thanks for that. I've been able to isolate where in the code the problem is occurring, but not the cause.
I'm consulting with my colleagues, so please bear with me a little longer while I await their feedback.
In the meantime, the few lines of code I've added to the site for debugging shouldn't make any difference to your site, if you could please leave the debug.log active for now.
I had another user reporting the something similar, although in their case they had a more conventional WordPress set up, and so I had them check what at first appears to be unrelated but which they confirm has solved the issue.
But on your site this doesn't happen, it is possible to navigate the back end at your secondary domain url. I think that is why the ajax request submitted when clicking the language switcher (which relates to passing session data between the sites) sometimes returns a 400 error, rather than just taking a long time (related to the String Translation issue, which is what happened with the other conventional site).
Anyway, please try that, and let me know how you get on.
