CK MacLeod

For a temporary fix, until WooCommerce is updated, you can use the above code and comment out lines 69 and 70 (plugin actions in woocommerce/packages/src/RemoteInboxNotifications/RemoteInboxNotificationsEngine.php

Like so:

//HACK Interrupt "phoning home" until WooCommerce is patched
		//add_action( 'activated_plugin', array( __CLASS__, 'run' ) );
		//add_action( 'deactivated_plugin', array( __CLASS__, 'run_on_deactivated_plugin' ), 10, 1 );

There are multiple issues associated with this bug. One is timeouts when adding or editing products, both from the product editor ADD or EDIT screens, as well as from bulk editing. The other noted so far is timeouts when adding, activating, or de-activating plugins.

The suggested filter did not work for us as written, possibly because we had already attempted a different fix from the database/options side (setting autoload on wc_remote_inbox_notifications_specs to false). Also, the filter function did not return a result.

This simplified version of the snippet is working for us regarding products, but not for plugins:

//WOOC BUGFIX
add_filter( 'woocommerce_admin_features', 'pk_woocommerce_admin_features' );
function pk_woocommerce_admin_features( $features ) { 

	unset( $features['remote-inbox-notifications'] ) ; 
	
	//filters should return a result. 
	return $features ; 
	
}

see also https://www.ads-software.com/support/topic/product-save-times-out-to-502-error/ and https://www.ads-software.com/support/topic/cannot-update-products-since-last-update/. Some attempts at fixes or partial fixes, but none that really solves the problems so far.

Seems to be related to https://www.ads-software.com/support/topic/cannot-update-products-since-last-update/

Unfortunately, none of the possible fixes proposed on either thread has solved for us. It does appear to be a problem at multiple WooCommerce sites, but not at all.

• This reply was modified 4 years, 2 months ago by CK MacLeod.

Same issues. What’s more, they are persisting after reversion to WooC 4.8

My pleasure, and thanks for the quick action.

Also having the same problem, also wondering what “got it figured out” entailed.

Tried an automatic update only around half an hour ago (so 2+ hours since your last reply on this thread): Crashed site, with the same error (referencing “line 54 of the file /home/copasoaps/public_html/wp-content/plugins/zero-spam/zero-spam.php”) that someone reported on your reviews page. After I deleted and re-installed, the issue went away. Could be that your updates don’t propagate immediately or evenly.

Still a fan of your plugin, just letting you know. Also, I wonder if you’ve explained somewhere why you’ve apparently dropped Ipstack support.

No big. Thanks. Still a fan.

• This reply was modified 4 years, 9 months ago by CK MacLeod.

OK but up above there you were describing the 4.3 release addressing the problem addressed on this thread. The latest official release is 4.2, which doesn’t, as far as I’ve seen, address the problem. How are you recommending that we deal with the issue?

• This reply was modified 4 years, 9 months ago by CK MacLeod.

Sorry, I thought you’d prefer I add the question here rather than start a new thread for it, since it’s on the same exact topic.

I’m also kind of confused now about what is and isn’t supposed to be in distribution. I’ve added the 4.3 Beta WordPress plugin to my site, after downloading it all from Github, and it seems to be working fine, even if it’s not quite right – in the sense of having unneeded files and not being in accordance with your expectations, apparently.

You’ve got a lot going on over there on Github, and you have a very fine plugin. I’m just trying to keep my site up to date and well-optimized, and to continue to use your plugin, which recently started producing the error and ceasing to function for me, and it’s only today that I had the time to investigate further.

• This reply was modified 4 years, 9 months ago by CK MacLeod.

Glad you’ve addressed this issue – is there a reason that 4.3 isn’t available from the Repo yet, but only on Github?

Sorry to say that Snapcreek support help wasn’t really very helpful this time around. Frankly, I had given up on Duplicator and had resorted to alternative “old-fashioned’ migration tactics, but, as now noted on the SnapCreek thread, I have now confirmed that the issue was the presence of Wordfence with “Extended Protection” in a higher level directory on the server. Once I uninstalled Extended Protection (in Wordfence Firewall settings), I was able to complete installation of a duplicate site.

Though I recall having in the past encountered somewhat similar issues relating to Wordfence, I don’t know why this particular version of it has cropped up now, in this way. As a friendly suggestion: You might want to consider adding some notice or message or instruction or option on the issue, given now popular Wordfence is, and how common I believe this filesystem substructure is for accounts with multiple WordPress sites.

Otherwise, I’ll go back to using Duplicator for all or anyway almost all of my site migration needs.

• This reply was modified 4 years, 9 months ago by CK MacLeod.

Also, I’ll leave this question open just in case you – with your much better understanding and more extensive experience – have any specific ideas about whitelisting Async JS on Wordfence or avoiding this issue in some other way – not that temporarily disabling Wordfence in a higher level installation is necessarily a huge deal. Please feel free to mark it as resolved if you prefer.

Thanks as ever.

No, that’s not it – the problem persisted even after all plugins disabled – but I think I figured it out, though I still don’t understand why the problem affects Async Javascript only, and only on this installation, now.

The problems seems to originate in Wordfence “extended protection” from a higher level installation. The affected site is installed in a subdirectory where Wordfence is in operation in a site installed in the main directory – public_html. When I disabled Wordfence in that site – call it the main site – the 403 admin-ajax error went away in the new sub-site.

When I reactivate Wordfence in the main site, the admin-ajax error comes back, but, when I install Wordfence in the sub-site”, configuring the Firewall to include the higher level one (there’s an option with default to “include”), then I can operate Async JS on both installations, with Wordfence, without issue.

The Wordfence info on setting up the firewall is verbose as usual, but isn’t specific on this type of action. Possibly something in some buried security protocol might have changed sometime over the last few months. In the past, I had some somewhat similar problem with Wordfence in a site structured this way, affecting operation of a different (also widely in use) site migration plugin. It was just a one-time problem encountered during migration, so not something I’ve thought about much since.

I end up installing both Wordfence and Async JS on most sites, including many structured in this way, but, like I said, this is the first time I’ve encountered this particular issue.