Tobin Fekkes

@agent365?

I can implement that for you if you want to reach out to me next week.

@afzalpansuvi

I understand the sentiment behind creating a new topic, but this isn’t an issue with websites being built differently or running in different environments. The core ShipStation plugin authored by WooCommerce has a very simple bug in it, regardless of the site or environment.

@afzalpansuvi

@elaraweb

We are experiencing this as well. It’s not a WooCommerce issue; the issue is the recent release of the ShipStation plugin, version 4.4.0. The changelog says the version was just an update to WordPress coding standards, which is why I updated it without looking too deep. But there are updates to the logic as well.

I’ve fixed all my stores locally and submitted a support ticket with woocommerce.com detailing out the problem and how to fix it, but this needs to be updated and pushed out ASAP. All I got from Woo Support was a disappointing and unhelpful AI-generated response.

The issue is that the Shipnotify->request() method previously got the $order_number value directly off the $_GET[‘order_number’] query parameter. However, the recent update moved that inside a $can_parse_xml if statement. But on the ShipNotify action, there is no XML because all the data is passed through the query parameters, not XML. So the XML is false, the $order_number is not populated, and the action to complete the orders never runs because it can’t find the order number. To fix it, move line 212 of “wp-content/plugins/woocommerce-shipstation-integration/includes/api-requests/class-wc-shipstation-api-shipnotify.php” outside of the IF statement (to line 173, for example).

• This reply was modified 11 months, 2 weeks ago by Tobin Fekkes.
• This reply was modified 11 months, 2 weeks ago by Tobin Fekkes.
• This reply was modified 11 months, 2 weeks ago by Tobin Fekkes.
• This reply was modified 11 months, 2 weeks ago by Tobin Fekkes.
• This reply was modified 11 months, 2 weeks ago by Tobin Fekkes.
• This reply was modified 11 months, 2 weeks ago by Tobin Fekkes.
• This reply was modified 11 months, 2 weeks ago by Tobin Fekkes.

@ellovee,

I had the same issue, which was particularly problematic for the upcoming holiday season! Gotta have gift cards!

So we built our own block to use the WooCommerce Gift Cards plugin to work with the new Checkout Block. Below is a screenshot on our checkout:

https://user-images.githubusercontent.com/6226162/141381958-15cc5e4b-03f5-4bce-a343-a54d7924f8ef.png

Email me and I’ll send it to you ??

Hopefully you have a staging site to test it on with your other plugins and store settings.

tobin at lunatechnw dot com

Tobin Fekkes

@sanjaydabhoya

Thank you for the response.

I’m sorry, but that is not an appropriate fix to this issue. There is absolutely no reason a WordPress site should allow, or even ever need, 2 gigs of memory. That’s simply preposterous, unacceptable, and even irresponsible. I am running massive, complex eCommerce stores on way less than 1 gig, so if your tiny, simple, one-feature plugin requires 2 gigs of memory, it’s a problem with your code and queries, not with my server’s memory. There are a handful of ways to fix this on your end by optimizing queries and filtering results rather than blanket-loading the whole user table in a page load. If you don’t know how, then stop publishing plugins, or fix it on your end, rather than put it on me to fix.

Thankfully, I run my own server, so I was able to quickly debug and fix the issue, and delete your plugin. However, not every WordPress user has that flexibility (particularly on shared hosting), so they deserve to know this beforehand so you don’t take down their site and brick it for longer than they care to have it go down.

This immediately breaks my entire site, and I already have memory up to 1024M, with only 26k users.

What exactly is going on, are you loading/parsing every single WP user object on every page load? Just to see if they’re blocked or not? I do far more database-heavy transactions than user-blocking to run the store, reports, etc, so this seems totally unnecessary.

Thankfully I tested it on a staging site first. But come on, WP should not require > 1024M to run a basic plugin. I have my own server, so it’s fine to increase my memory limit; but it’s WordPress: most people do not.