Give 2.0 Database Updates Explained

Give 2.0 makes some significant updates to the database structure running behind the scenes. We’ve included an upgrade routine and are testing all scenarios to ensure that it’s both backwards compatible and runs smoothly going forward.

The following will help you to understand what’s going on with the structure and to plan accordingly. 

New Tables

We introduced six new tables to improve SQL query performance:

  1. {wp_prefix}_give_paymentmeta
    After 2.0 payment meta will be store in this table before it was saving in to {wp_prefix}_postmeta
  2. {wp_prefix}_give_formmeta
    After 2.0 form meta will be store in this table before it was saving in to {wp_prefix}_postmeta
  3. {wp_prefix}_give_logmeta
    After 2.0 log meta will be store in this table before it was saving in to {wp_prefix}_postmeta
  4. {wp_prefix}_give_customermeta has been renamed to {wp_prefix}_give_donormeta
  5. {wp_prefix}_give_customer has been renamed to {wp_prefix}_give_donor
  6. {wp_prefix}_give_log
    After 2.0 log data will be store in this table. Pre-2.0 it was saving in to {wp_prefix}_posts

Database Upgrades

It’s important that you upgrade your database after 2.0 (make sure you back up first) in order to be sure you’re compatible with all the latest changes.

We have following database upgrades in 2.0:

  1. Update form meta
  2. Update offline email related settings
  3. Update payment meta
  4. Renamed core meta keys
    1. _give_payment_customer_id -> give_payment_donor_id
    2. _give_payment_user_email -> give_payment_donor_email
    3. _give_payment_user_ip -> give_payment_donor_ip
    4. Split the _give_payment_meta array to single meta keys:
      1. _give_payment_date
      2. _give_payment_currency
      3. _give_donor_billing_first_name
      4. _give_donor_billing_last_name
      5. _give_donor_billing_address1
      6. _give_donor_billing_address2
      7. _give_donor_billing_city
      8. _give_donor_billing_state
      9. _give_donor_billing_zip
      10. _give_donor_billing_country
    5. Store unique address to donor billing address.
    6. Move payment to {wp_prefix}_give_paymentmeta
    7. Move form to {wp_prefix}_give_formmeta
    8. Move Log data to {wp_prefix}_give_log and {wp_prefix}_give_logmeta
    9. Update donor
    10. Move user address to donor meta
    11. Create new donor meta for first name and last name
    12. Update rename donor table


  1. Each upgrade is unique and logic connect to related upgrade only. Data will keep storing into old table till admin will complete upgrade.
  2. If admin stop upgrade and make change to move data then these new changes will not reflect to new meta.
  3. New logs will not appear on log list page till log upgrades complete.
  4. We are not deleting data during this upgrade for safety.

Payment Meta ( _give_payment_meta )

The following logic is connected to _give_payment_meta:

  1. We have a database upgrade to split this information to multiple unique key to make SQL query easy on them.
  2. Whenever we will update _give_payment_meta it will store into database and it will also split into multiple single keys ( See above: Database Upgrades 2b )
  3. Custom metadata which third party add-on storing into _give_payment_meta will not be affected. You can still get and set custom meta key inside _give_payment_meta.
  4. Post and pre upgrade when somebody gets _give_payment_meta meta key then it will pass through a filter which will overwrite the existing core meta key. That way the meta key will always contain the updated value.

Existing Code Compatiblity

If you have existing code that you’re concerned about compatibility moving forward here’s some information that should help clear things up.

Payment Meta

Currently in core we have following functions to get and update payment meta:

  1. give_get_payment_meta() ( wrapper for Give_Payment::get_meta() )
  2. Give_Payment::get_meta()
  3. give_get_meta()
  4. get_post_meta() (WP Core function)
  5. give_update_payment_meta() ( wrapper for Give_Payment::update_meta() )
  6. Give_Payment::update_meta()
  7. Give_update_meta()

If you are using any of the functions above within your code to store and retrieve payment meta then your code will be compatible with 2.0. If you are not using the functions above then likely you are fetching payment meta with a SQL query or another method which we don’t support.

Donor Meta

In 2.0 we are deprecating the Give_Customer and Give_DB_Customer_Meta classes. However, you can still use the deprecated classes within your code as there is built in backwards compatibility. We do recommend that you eventually update your code as best practice.


Devin Walker

Head of Product and Founder of GiveWP, WordPress enthusiast, WordCamp speaker, mediocre golfer, post-rock obsessed cat lover and aspiring world traveler.


Leave a Comment