We've had an issue in EDD for a while where customers would disappear in EDD and could not be created.
Today I finally figured it out. EDD sets the email address column for the customers column to a really short 50 characters. However, emails can be longer than this, in fact, WordPress allows for a VARCHAR(100).
What happens if a user enters an email address > VARCHAR 50 atm is the order goes through, but the customer isn't created and then thus not associated with the order due to a silently handled failed DB insert (COLUMN VALUE EXCEEDS SIZE RESTRICTIONS) into the edd_customers table.
Changing this column to a VARCHAR 100 will solve this problem for the future.
We however will also need:
Ideally this should be done before EDD 3.0 to allow for data normalization.
Title is an ode to the Pippin's White Whale ticket.
This where the current VARCHAR is set (and where it needs to be updated): https://github.com/easydigitaldownloads/easy-digital-downloads/blob/master/includes/class-edd-db-customers.php#L589
@JJJ Ping for EDD 3.0 please? Make sure we make this part of the DB class. I'm going to get something together for the current releases.
@cklosowski we also need the a process that finds orders where the EDD email address meta key value is > 50 characters, and for each of those orders, if an attached customer is not there, then create & associate the order. part as otherwise, a lot of things in EDD are currently broken for those users.
The good news is this should just be a simple db paged routine like others in EDD and it should be quick, only affecting a couple dozen of each 1k orders.
@chriscct7 ah yes. good call. I'll work up an Upgrade routine that only shows up if there are payments with an email address over 50 chars.
Actually, I think we should hold off here. I know it's a bug...but with 3.0 we'll be doing a TON of db upgrades, and new table formatting classes. Since we'll have to itterate over everything to migrate the payments, we should just take care of the customer creation during that. Instead of pushing a fast fix, i'd rather go for the solid fix where we're already going through each paymetn with a fine tooth comb.
Closing out as this is due to be addressed in #6310.
Most helpful comment
Actually, I think we should hold off here. I know it's a bug...but with 3.0 we'll be doing a TON of db upgrades, and new table formatting classes. Since we'll have to itterate over everything to migrate the payments, we should just take care of the customer creation during that. Instead of pushing a fast fix, i'd rather go for the solid fix where we're already going through each paymetn with a fine tooth comb.