easy-digital-downloads
easy-digital-downloads copied to clipboard
awesomemotive
Customer not assigned to manual orders - edge-case/issue
Bug Report
Expected behavior
When I manually add an order and assign a new (or existing) customer, I expect the order to be completed with the customer assigned to the order.
Actual behavior
The order is added but the customer is never assigned. It does not matter if it's a new or existing customer record.
I am unable to replicate this locally, but I have seen this issue on 3 separate client sites with almost nothing installed other than EDD 3.0.
In some cases, they never had EDD 2.x prior either so it's not a backwards capability issue per-say. Regardless, it's breaking All Access passes and other things which require the customer ID (for obvious reasons).
I am going to investigate this further, but it was worth dropping an issue here because I am seeing this relatively often.
Information (if a specific version is affected):
PHP Version: mixed (7.4 or 8.0).
EDD Version (or branch): 3.0.4
WordPress Version: latest
Any other relevant information:
Hey @davidsherlock Just to confirm something here, the issue is that the Customer is not being assigned to the order or the User? Also if you have access to the customer's database can you compare the structure of the edd_customers table against the one on your local?
I am going to take a look at the weekend, haven't had a chance as of yet to compare the tables and see what is going on.
The issue is with the orders not being assigned the customer.
Can't replicate this locally :( check the customers and customer_meta tables and see if perhaps they are missing a field. Is it the same with just EDD on their sites or is there other extensions involved?
Yeah, I wasn't able to replicate it either tbh. But I have seen it a few times on completely different sites...
Here is the thing - no AJAX errors, no extensions enabled, etc..
It's been completely different client projects as well, so I am not sure what is going on. I will update this issue as I discover the potential cause of this.
I have actually discovered a bug with the All Access extension, but I am not able to add it to GitHub as I don't have access to those repos.
If you create an order and assign an access pass as a product, then save the payment the access pass will show as "invalid". I was able to replicate this on my local setup, as well as client sites so it's definitely an issue.
If I purchase the pass normally, everything works. It's just manually adding a payment that causes the issue.
We have that fixed in the next release for All Access! It only seems to affect manual orders from the admin side.
Great, is there any ETA on that one? My client manually processes payments and then adds the passes so it's an important one to get fixed :)
Thanks for the update, @mihaijoldis!
I'm seeing this as well, but I'm not seeing a customer created for any of my orders since updating to EDD v3.x (from 2.x).
If it helps, I use filters and action hooks to remove the first/last name as required fields (or have them in the UI). I believe I copy/pasted this from some code Pippen shared years ago.
After checkout, an email address is added, the order is completed, and customer emails are sent, but no actual Customer database record is created or assigned to the order.
I had these problems after the update to 3.0, too. But with the newest updates for edd, all-access and manual-purchases it works fine, again.
I'm currently running 3.0.4. If there's a newer version, I'm not being prompted to download it.
@matt70 no, I'm not running the all-access plugin at all
Could you please send a ticket to our support team via our website and we will take a closer look at this. We would require some more information and we can't ask for that publicly here.
@cferdinandi forgot to ping you.
@mihaijoldis Done, and no worries, GitHub is great about sending me emails to all updates here. Appreciated, friend!
@cferdinandi did you sent your ticket via https://easydigitaldownloads.com/support/ ? I haven't seen anything come in yet.
Yes, actually a few minutes before you told me to, because I realized I should have gone through support first. I can resubmit, though.
@mihaijoldis Resubmitted! I never got a confirmation email the first time, so I think I messed up. Just got one now, so should be good to go.
@robincornett I noticed that this is marked as being a resolution of an 'edge case' for manual order creation, is that correct? It's just changing how the existing tables are adjusted?
@cklosowski I know it says edge case in the issue title but I think the 2.x-3.x upgrade for the customer tables could be handled more reliably. Since the tables can be adjusted by downgrading to 2.11.x, and then need to be adjusted again when coming back to 3.x, it seems possible for something to be missed. I think the change we made to the CLI upgrade (to run the maybe_upgrade methods before migrating) was a good start, and updating the maybe_upgrade checks helped as well.
I don't know that I want to close this yet, but I don't think it has to go into 3.1.0.3. We can wait and see if we have more reports of affected tables--if not, the changes we've made may be sufficient. In testing my PR I had to willfully and manually mess up the tables to "replicate" which isn't a true replication.
