scmsteve

It is a matter of what the integration plugin itself does, and then further what ShipStation may or may not be doing via API calls once it has the connection afforded by the integration plugin.

Again, NOT RESOLVED, at least the question wasn’t fully answered.

I wish y’all would stop marking things as resolved that ARE NOT RESOLVED. You haven’t heard back because it isn’t fixed yet.

They have no logs or so they say.

Saying this is “by design” is not very helpful when you have multiple variations that are substantially different and not having that variation information brought over means you have no idea what the actual item is. Putting this on the “ideas board” is the same as having a funeral for it. I think this should be considered a bug that you are losing the variation information during the process.

Thanks. Woocommerce had said that if it is due to using the v1 API they won’t fix it because it is deprecated. I don’t think that should mean broken, but whatever, that is their call. I know the v3 endpoint was working so hopefully you can make it work with your plugin.

I can verify that if I send this REST request:

/wp-json/wc/v1/products/?per_page=3&featured=1

I get featured and non-featured items.

If I change v1 to v3:

/wp-json/wc/v3/products/?per_page=3&featured=1

It properly filters.

I’m not into block development much yet, but it looks like you are overloading the REST API with a /agwc/v1/products endpoint, and if I try to call that (/wp-json/agwc/v1/products/?per_page=3&featured=1) I am told I cannot list resources.

I don’t know how to test much further to verify if this is a core Woo issue with the /v1/ endpoint not respecting the filter or what.

I don’t understand how GDPR plays into the automation of subscribing, as it seems the privacy of their data, whether it is in our system or MailChimp, is already affected by just putting them on the list. We only do this in conjunction with customers and sales, for which a specific relationship is established and the communications are related to that relationship.

GDPR aside, two particular use cases that affect us, but the most important perhaps is that as part of a purchased subscription users sign up and are/were subscribed to a list in MailChimp that were used to deliver actual items over time directly related to their purchase. Without automatic subscription, this falls apart entirely.

Further, it seems strange that this feature would be restricted on the basis of GDPR, because you are not liable for how a site owner chooses to use the systems, so it would be up to us to handle the data with care, which we do. To take away a rather core and critical piece of how we have used the plugin is a bit frustrating.

Is there any mechanism we could put a filter or hook in to interact with your plugin to restore the previous functionality even if you didn’t make it an easy public option? That way cases like ours where it is rather critical to how the site works could continue on?

It isn’t resolved, too many other things going on that are more pressing. ?? .This is a very occasional issue and seems to have no user impact.

Since I still cannot cleanly reproduce it, nobody believes it is a real problem, but it is still happening now and then.

Before just closing issues, it would be nice if you reached out to verify first.

I have tried, but what plugin should I file it under? We have a lot of paid plugins. This isn’t related to subscriptions from what I can tell, just purchased downloadable items. I think I did try formal support and was basically told that we had too many plugins, disable everything and see if it still happens. Well, since I can’t exactly duplicate the sequence that causes this error, it is very sporadic, it would be hard to know that and I can’t cripple our site in the mean time. Plus, I can’t test on a staging site when I don’t know what action triggers this. That is why I was hoping someone with more knowledge on the internals of what is going on would chime in and give some helpful debugging feedback, like some code to put in at some key point to capture more information than what is being made available.

I did the best I could at the time to narrow down what was happening, it seemed tied to the system trying to retrieve the download count to display in the metabox. It seems that somehow records are created but removed, at least based on the notes above, but it has been a busy month with many other things going on and I can no longer remember all the details. ??

By the way, these downloads aren’t managed by subscriptions (or memberships, or anything else), they are just either purchased or free downloads attached to their accounts.

We are using subscriptions, but all of the associated downloads are still there. Would this be better handled as a support ticket? I regret that it was almost two months ago when I looked at this, and got pulled in different directions and am just getting back to it so my memory is a little bit more spotty…. I had put in some debugging code and that is how I followed the sequence I mentioned above where it was happening at the time of trying to update the download count in the metabox, and at one point in the process the download_id exists as it assigns a permission, but when it gets to the metabox update that is gone. I had contacted support at the end of April, but didn’t get very far, as is typically the case, becuase we have a lot of active plugins (carefully curated and tested) and they insisted it was another plugin and wouldn’t help. Unfortunately I haven’t come up with a specific way to test this, I just see it happen periodically in the logs, and it seems the only side effect is that the download count in the meta box can’t be properly displayed but as far as I know we haven’t had reports of downloads being invalid/inaccessible at all.

Even more, this seems to be happening when our shipper is trying to mark the order ‘complete’. Interesting, and I may not be able to find out why, but they attempted this twice:

Order status changed from Processing to Completed.
April 29, 2020 at 12:59 pm

Order status changed from Processing to Completed.
April 29, 2020 at 12:48 pm

Something during the process of marking the order ‘complete’ is triggering the updating of the download meta box which is hitting the error trying to create a download count entry for something in the download log table but not existing in the download permissions table?

A bit more on this, it seems it may be related to trying to determine previous download counts to put in the meta box, and looking through the wp_wc_download_log table I do see entries for the download permssion_id that is in the backtrace, but yet there are no entries in the wp_woocommerce_downloadable_product_permissions table which is probably what is causing the error to be thrown.

So, how did downloads get created, and logged as being downloaded, and then removed from the download permissions table for a given order? Nothing is reflected on the order that anything was changed.

We are also seeing this error on our site when an order is placed for downloadable products, it is throwing the same backtrace with current versions of all software.

I contacted support and was told it couldn’t be a WooCommerce issue because they have no record of a similar issue in their database so therefore it has to be a site specific or third-party plugin causing it, even though the backtrace is only showing Woo code.

Sounds like you have no resolution, and we certainly aren’t getting any. I’m trying to walk through and debug the Woo code now to figure out what is going on.

BTW: How was this marked “Resolved” when there is no resolution here?

• This reply was modified 4 years, 10 months ago by scmsteve.