The official GiveWP development blog

We want to keep everyone in the loop with what’s going on with the database updates within Give 2.0 which is now moving into the final testing phase. These are the following donor related updates we are doing in Give version 2.0 with backward compatibility:

The donor related tables is renamed:

{wp-prefix}_give_customer → {wp-prefix}_give_donor

{wp-prefix}_give_customermeta → {wp-prefix}_give_donormeta

The Give_Customer class is deprecated. Use the Give_Donor class instead.

We are only storing donor ID to payment meta instead of user ID.

Moving forward we are going to store donor metadata to {wp-prefix}_give_donormeta instead of WP’s {wp-prefix}_usermeta

Current donor metadata stored in the usermeta table will be copied to the donormeta table using an upgrade routine.

Previous donor metadata stored in the usermeta table will not be deleted. This is for backwards compatibility and a failsafe should the data migration be interrupted.

Address updates:

The donor’s billing address is currently (pre-2.0) only being saved to the donation payment meta. Moving forward in 2.0 the data is now saved to both the payment meta and the donor meta.

If a repeat donor returns and enters a different billing address then it will save like before to the payment meta and add the new address to donormeta. In this case, the new address would be called “Billing Address 2” within the donor’s profile.

The donor can now have multiple types for addresses.

Add-on like Gift Aid will now store the additional “Gift Aid Address” to the donor meta.

This paves the road for the future enhancement of allowing the donor to have both a billing address and physical address should admins want to collect the additional information.

You can access all donor addresses from the Give_Donor object.

A Give_Donor can connect to a WP_User for a variety of reasons including, but not limited to:

Providing the user access to donors by using WordPress core functionality

To increase the extensibility of Give with third-party plugins that creates user roles. Examples include:

Membership plugins

LMS platforms (course, study material)

Content restriction plugins

Ecommerce platforms

If you have any questions be sure to ping us in our Slack community or in the comments!

Does this changes the way we add our own custom fields through code? Specifically, do we need to start changing our code to put custom fields into separate donormeta key value pairs or do we still put them in a single payment_meta array that is simply moving from usermeta to donormeta?

Be sure to put big, obvious warnings in the change log and elsewhere when 2.0 comes out so customers who have custom code for form fields don’t unknowingly break anything before consulting with their development partners.

Moving forward, we recommend you store each meta value within it’s own meta key. Regardless of whether it’s payment or donor meta. In 2.0 we are breaking apart the payment_meta array into separate key/value pairs.

We’ll be sure to put some obvious warnings in the change log and here, social media, youtube, shout it from the rooftops, etc prior to release. 🙂