websavers

Thanks for the confirmation on that Marko!

Thanks @rymerakristel !

Forgot to mark resolved, doing so now.

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.

Hey @nawawijamili no worries! Easy enough to have it disabled until it’s fixed up ??

 [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.

No prob! Send the debugging code updates over – I appreciate your willingness to continue troubleshooting.

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

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.

Thanks for the clarification and consideration!

Same here even after clearing browser cache and trying 3-4 other browsers. In some cases it weirdly didn’t work for one person consistently no matter which browser, while everyone else could. (Weird).

Rolled back to version 1.15.2 which is linked here to see if that person could see them again, and no problems with that version for anyone – including the one that couldn’t get it to work no matter what on the latest version.

Thanks for the quick fix!

Solution appears be to edit line 1618 to this:

if ( class_exists('OrderUtil') && OrderUtil::custom_orders_table_usage_is_enabled() ) {

• This reply was modified 10 months, 2 weeks ago by websavers. Reason: typo

We were encountering this issue with WC 8.4.0. Even running cron manually wasn’t updating the prices.

Updated to 8.5.2, manually triggered the cron event via Crontrol plugin and the sale prices updated.

Appears to be fixed in 8.5.2.

• This reply was modified 1 year, 1 month ago by websavers.

I’m quite certain the issue stems from this Divi file: core/components/Portability.php with this function:

        protected function prevent_failure() {
                @set_time_limit( 0 );

                // Increase memory which is safe at this stage of the request.
                if ( et_core_get_memory_limit() < 256 ) {
                        @ini_set( 'memory_limit', '256M' );
                }
        }

I’m betting that 1) this is hooked in late and so other parts of WP don’t see it because the limit hasn’t been set yet, and 2) it’s failing to get the current limit properly.

If you ask me Divi should absolutely not be doing this. If they’re encountering memory limit issues they should warn the user that the limit is too low, not try to force a new limit… that itself is too low. I find this typical for Divi programming though: trying to be too user friendly and shooting itself in the foot.

Also, I know it’s Divi because deactivating the Divi Builder plugin completely resolved the issue. Also made the entire WP admin and loading uncached pages way faster.

• This reply was modified 1 year, 1 month ago by websavers.
• This reply was modified 1 year, 1 month ago by websavers.