Hi @websavers, thank you for bringing this to our attention. We’ve identified the issue causing the error with enabling the “Support Remote Diagnostics” option. Our team is currently working on a fix, and it will be included in an upcoming release. We appreciate your patience, and please let us know if you have any other questions or need further assistance in the meantime.
Hi @websavers, thanks for your patience. We just wanted to check back with you to see if this was still a problem with our latest plugin (v5.0 at the time of this post). Please let us know when you get a moment, we’ll be happy to help troubleshoot further if necessary.
Not fixed I’m afraid. I don’t get the warning anymore in the logs, but Remote support still fails to activate. After checking the box, a POST to admin-ajax.php occurs, which returns a 200 HTTP success code, but the actual response content is:
{
"success": false,
"data": {
"error": "Server Error",
"opt": 0
}
}
There are no logs in the apache server logs when this occurs, even though one would certainly think a ‘Server Error’ would generate such a log entry.
Plugin Support
KJ
(@kjvextras)
Oh boy – We apologize for the inconvenience – Our devs are looking into this.
Plugin Support
KJ
(@kjvextras)
Hi – We have a new plugin v5.1 – Have you given it a try? Do you still get errors? Let us know.
@websavers Could you please check to see if you have a firewall enabled that might be preventing this from reaching your site? We have a special User Agent header that will say Mailchimp Support if you don’t mind adding that to your configuration allow list.
Hey @ryanhungate
Thanks for the reply! I tried disabling the web application firewall entirely, and no dice. Same result – a 200 code in the server logs, but your plugin saying there was a server error.
I also tried installing it on a totally different site, on a totally different server. Connected mailchimp to our account, and then attempted enabling the very same option and that worked fine. I tried enabling similar options in the hosting control panel as well (same PHP version, same nginx caching settings, etc), and yet it still worked fine on that test site.
I suspect this has to be a plugin conflict, but I’m afraid I can’t easily just start disabling plugins on the live site.
Are there any specific hooks or function calls that this particular code makes which could be where the issue lies? I can search other plugins on the site for those hooks/functions to perhaps narrow it down.
Most likely it’s a plugin that utilizes wp_ajax_example_ajax_request
@websavers in an effort to help speed this debugging session up, I would actually recommend that we make a slight change to your plugin manually to see if we can spot the issue. Basically the fix is going to be to add some additional logging into that specific function so we can see the request, and the response. Are you comfortable making a couple very small PHP changes to a function or two while we try to diagnose this? We could of course add this into the next version of the plugin which will make it easier, but depending on how fast you would like to get this resolved, we might need to do something manually first. Let us know if you would rather wait, or if you want to try this first 🙂
No prob! Send the debugging code updates over – I appreciate your willingness to continue troubleshooting.
@websavers this is the change that was made just recently if you would like to simply change that one function. The concept would be “enable the DEBUG logs” in the plugin and then try to enable the support again, so it will show you the details of the request / response. This will help us diagnose things.
[status_code] => 500
[protocol_version] => 1.1
[success] =>
[redirects] => 0
[url] => https://tower.vextras.com/admin-api/woocommerce/enable/66d9ea724b946
[history] => Array
Just a snippet – I’m emailing the whole thing to ya.
Now fixed, thanks to @ryanhungate 🙂
This was a result of the local domain’s SSL certificate missing an intermediary certificate in the chain between the domain and the CA. I have to assume web browsers already had this particular COMODO intermediate certificate installed, since the site loaded with no SSL errors.
If someone else encounters this issue, you can verify it by checking your site URL with an SSL Certificate checker like https://www.sslshopper.com/
The solution, as with all intermediate certificate issues, is to re-download the SSL certificate’s CA certificate bundle, reinstall the bundle on the web server, and of course reload it. Immediately after doing so the remote support option worked as expected.
Forgot to mark resolved, doing so now.
Glad to hear that fixed the issue @websavers! If anything else pops up, don’t hesitate to reach back out to us. We appreciate you using the plugin.
If you’re happy with this integration, please consider leaving a 5-star review. Your feedback helps other WooCommerce customers find this integration and helps support future development.
