A few pages fail to load and show Cloudflare error 520. It only happens if all of this applies:
* The language is German (the default English pages are fine)
* It includes one of our custom shortcodes
* The user is logged on
* The Borlabs Cookies plugin is activated
After a lot of research, I found the below code in the shortcode to be the problem. It retrieves taxonomy terms in the required language. It first sets the language, then executes the query, then sets the language back to the original.
if ($current_language_code != 'en') {
do_action('wpml_switch_language', 'en');
}
$my_terms = get_the_terms($myID, 'taxonomy');
if ($current_language_code != 'en') {
/* Line causing the issue: */
//do_action('wpml_switch_language', $current_language_code);
/* Alternative, not causing an issue: */
switch_to_locale($current_language_code);
}
For some reason, in very specific circumstances, the second do_action causes the issue. Omitting that line or using the alternative solves the issue, and doesn't seem to cause other problems on the page. Borlabs can be activated again and all works fine. It seems like wpml_switch_language is setting a cookie, that somehow conflicts with Borlabs, only in this specific situation. It could be a timing issue perhaps, where Borlabs blocks the cookie when it shouldn't. Although deactivating WP Rocket (with javascipt delayed load etc) doesn't solve this either.
Do you know what the actual problem could be, and if there is a better solution than the one I found?
can we get access to your staging for some further tests initializing the above-mentioned code?
I would like to request temporary access (wp-admin and FTP) to your site to take a better look at the issue. It would be better to a testing site where the issue is replicated.
You will find the needed fields for this below the comment area when you log in to leave your next reply. The information you will enter is private which means only you and I can see and have access to it.
Maybe I'll need to replicate your site locally. For this, I’ll need to temporarily install a plugin called “Duplicator” or "All in One WP Migration" on your site. This will allow me to create a copy of your site and your content. Once the problem is resolved I will delete the local site. Let me know if this is ok with you.
IMPORTANT
-Please make a backup of site files and database before providing us access.
-If you do not see the wp-admin/FTP fields this means your post & website login details will be made PUBLIC. DO NOT post your website details unless you see the required wp-admin/FTP fields. If you do not, please ask me to enable the private box. The private box looks like this: hidden link
This is only possible to guess with the actual error. 520 is not the actual error. You can get the actual error from the server or PHP logs (where the website is hosted, not CloudFlare).
However, from the code you are using to switch to the original language on 2nd line. You can also use
do_action('wpml_switch_language', null);
to restore the original language. Does this work for you? If not, please provide us with your debug.log.
The log file doesn't contain anything useful, please see attached. It shows some warnings for bbPress and Advanced Ads. But if these plugins are deactivated, the issue still occurs. The page itself works, if the visitor is logged out. I think the problem is related to cookies.
Interestingly, using your suggestion, the problem is solved and the page seems to be all fine:
do_action('wpml_switch_language', null);
I also tried this but that caused the same problem:
do_action('wpml_switch_language', 'de');
Note that these are German pages while the default site language is English. The problem only occurs on the German pages, if logged in.
Any idea why your suggestion works, and explicitly setting German to switch to doesn't work?
right now, we can't say why it's not working. If you want us to investigate further, please provide server and PHP logs because the error on CloudFlare itself is insufficient to find the root cause. We suspect a problem related to compatibility and cookies, but this needs further investigation to see why it works on your installation only using the original language via "null".
Ok, so it changes back to English with that code. It's unexpected to me that when the code is running on a German page, I nevertheless do not see any English content on that page. That's what I'd expect if the codes switches to English and not back to German (I've seen it before). But in this case, the whole page seems fine, all in German.
Also, switch_to_locale() should not work properly when given only the language code. If you want to debug this further, please provide a site copy for local debugging as described here: https://wpml.org/faq/provide-supporters-copy-site/. But please note that our debugging of custom code is limited via our support policy.
we found something more about this issue: Something strange happens - some pages - even admin pages - return the same error after some tries.
I tried to reproduce this locally - to see if there is an issue of a sort - but I am unable to do it.
In the Cloudflare guides: hidden link
it is mentioned:
While the 520 error can be triggered by unique and seemingly strange edge-case scenarios, they are generally caused by: Connection resets (following a successful TCP handshake), Headers exceed the Cloudflare header size limit (over 8kb), An empty response from origin, An invalid HTTP response, Missing response headers from an HTTP response, or the Presence of multiple Content-Length headers.
What triggers our curiosity is that the headers might be too large, perhaps - but this is just a guess. We need your help to debug this. Please temporarily disable Cloudflare and save the HAR files (as outlined in this example hidden link) with disabled Cloudflare and with enabled Cloudflare .
Additional note:
Whether or not calling switch_to_locale with parameters like 'de' or 'en' or whatever - is never going to work -> https://developer.wordpress.org/reference/functions/switch_to_locale/ - it expects a locale and not just a language code - you have to convert it to a locale - e.g. en = en_US; de = de_DE; and so on. If switch_to_locale('de') works for you - then it is as good as commenting out that code and not executing it at all.
Thanks again. I have double-checked that line of code with "get_the_terms" but can't see what could be wrong with it. I also tried wrapping it in this to be sure, but no difference:
if (isset($product_link_vendor->ID)) {
I spent a long time with the hosting to get additional PHP logs. There's nothing useful in there if you ask me: hidden link
Based on your comments about "switch_to_locale", I replaced this:
if ($current_language_code == 'de') {
switch_to_locale('de_DE');
}
That solves the issue too. Perhaps that's the safest workaround?
I have also seen the 520 error in the admin area several times. But only after the frontend error occurred. I don't think I've seen it again now that I "solved" it with the workaround.
I reproduced the error with Cloudflare enabled and in pause mode. Here are the HAR files: hidden link
I hope this is useful. If you still need the entire site, I can try it with Duplicator. But it's a large site, I think it has failed in the past with Duplicator.
Thanks a lot, I appreciate it. As for Cloudflare still being enabled: I had the choice between developer mode, which only bypasses the cache, and pause mode which should disable everything. But traffic still flows via their servers. I guess the only way to prevent that is to change the DNS and point it straight to the origin server.
Anyway, this is getting too complex for my tech skills, so to make sure I understand:
1. The root cause is not WPML or Borlabs, it's just that if we do not use the WPML function or deactivate the Borlabs plugin, the HTTP headers are small enough to not cause issues.
2. It's likely NGINX settings that can solve this, because right now it closes the connection in case of headers that are longer than the current maximum, and the Cloudflare error is only a side effect of the closed connection.
This would also explain why it all works fine for anonymous users visiting those pages: the headers are likely much smaller for them.
