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 {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.


Give 2.0 Donor and User Meta Database Updates Explained

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:

  1. The donor related tables is renamed:
    1. {wp-prefix}_give_customer → {wp-prefix}_give_donor
    2. {wp-prefix}_give_customermeta → {wp-prefix}_give_donormeta
  2. The Give_Customer class is deprecated. Use the Give_Donor class instead.
  3. We are only storing donor ID to payment meta instead of user ID.
  4. Moving forward we are going to store donor metadata to {wp-prefix}_give_donormeta instead of WP’s {wp-prefix}_usermeta
    1. Current donor metadata stored in the usermeta table will be copied to the donormeta table using an upgrade routine.
    2. 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.
  5. Address updates:
    1. 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.
    2. 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.
    3. The donor can now have multiple types for addresses.
      1. Add-on like Gift Aid will now store the additional “Gift Aid Address” to the donor meta.
      2. 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.
    4. You can access all donor addresses from the Give_Donor object.
  6. A Give_Donor can connect to a WP_User for a variety of reasons including, but not limited to:
    1. Providing the user access to donors by using WordPress core functionality
    2. To increase the extensibility of Give with third-party plugins that creates user roles. Examples include:
      1. Membership plugins
      2. LMS platforms (course, study material)
      3. Content restriction plugins   
      4. Ecommerce platforms

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


Support for Per User Language Settings Coming in Version 1.8.9

WordPress has supported per user language settings since version 4.7. This allows users to set their preferred language under their profile settings. If you are running a multilingual website, this is a vital feature for those users who don’t speak the site wide language setting.

Up until now, Give has only supported the site wide language setting. This means that if you changed your profile’s language setting to another language, all core WP menu items would update but Give would still be using the site’s language setting. With the upcoming release of Give 1.8.9 this is no more. Now your users can enjoy Give in the language they prefer, providing that there is a translation available for that specific language.

How it Works

If you are using WordPress 4.7+ (and you should be) then your site users can now change the language to their preference in wp-admin:

Per User Language Setting

Per User Language Setting

When I change the setting to Deutsch, you’ll see Give’s menu update as well:

Prior to 1.8.9 this menu item would have been in English, the site setting.

As well, the donations forms will also respect the user setting:

Frontend Give for In German, the User's Language Setting

Frontend Give for In German, the User’s Language Setting

More i18n Extras

  • WPML has been fully audited for support with the help of their developer Vuk Vukovic. Thanks for that! You can also see our page here on their site:
  • Simplified load_textdomain() method within the main give.php file – the use of unload_textdomain() allows for the per user language setting to work.

Don’t See Your Language? Help Us Translate Give

We’re always looking for help supporting more languages with the plugin. If you are multilingual, please consider helping translate our plugin!

Help Translate Give »


What’s Coming Up in Give Core Version 1.8.9

Right now we’re in the middle of working through Give version 1.8.9 and it’s shaping up to be a pretty significant point release. Within this release there’s going to be a number important updates to the core codebase that we’d like to bring to your attention.

Deprecated Classes and Functions for Better Donation Terminology

If you’ve ever spent time working with our codebase you may have noticed words like “customer”, “store”, and “sale”. This is because when we first developed the plugin a lot of our code was previously being used for eCommerce transaction. Now, of course, it’s used to accept online donations. Hence, the code should reflect the appropriate terminology for its job.

To meet the goal of having a donation and nonprofit friendly verbiage we are deprecating many core classes, hooks, and functions. What’s this mean? Well, if you have WP_DEBUG turned on and an add-on or code you have implemented uses a deprecated hook or function you will see a notice telling you the function has been disabled and

Using a deprecated class will not trigger an error for backwards compatibility reasons and to prevent output errors like the header’s already sent.

Deprecated Classes

The following classes are being deprecated. The old classes will still work, and we’ve written unit tests to ensure that, but please don’t use them anymore within your code.

  • Give_Customer => Give_Donor
  • Give_DB_Customer => Give_DB_Donor
  • Give_DB_Customer_Meta => Give_Donor_Customer_Meta

Deprecated Hooks and Functions

There are a number of functions that are going away in 1.8.9. We initially tested our method for deprecating functions in the 1.8.8 and were happy with the smooth rollout. So, in 1.8.9 we’re deprecating a larger number of functions and hooks.


  • give_get_payment_customer_id => give_get_payment_donor_id
  • give_get_total_sales => give_get_total_donations
  • give_count_purchases_of_customer => give_count_donations_of_donor
  • give_get_purchase_stats_by_user => give_get_donation_stats_by_user
  • give_get_users_purchases => give_get_users_donations
  • give_has_purchases => give_has_donations
  • give_count_total_customers => give_count_total_donors
  • give_purchase_total_of_user => give_donation_total_of_user
  • give_delete_purchase => give_delete_donation
  • give_undo_purchase => give_undo_donation
  • give_trigger_purchase_delete => give_trigger_donation_delete
  • give_increase_purchase_count => give_increase_donation_count
  • give_record_sale_in_log => give_record_donation_in_log


More Insight: To keep up-to-date on the deprecated classes and functions you can refer to this issue on GitHub. We took the first baby step to completing this issue in version 1.8.8 and now version 1.8.9 is a much larger step. The goal is that by version 2.0 all the terminology will be updated, including within the database.

Core Notice Urging Customers to Upgrade from PHP 5.2

Like our friends over at Yoast, we’ve decided it’s time to give our users a friendly nudge away from PHP 5.2 by asking them to update to at least version 5.6. In fact, Give runs great on PHP7 and ideally, that’s the version you want to be on. However, we understand there can be some conflicts still with some WordPress plugins.

In 1.8.9+, if Give is installed on a server running PHP 5.2:

  1. A dismissible notice will appear in wp-admin urging users to update
  2. Give core will still continue to work in PHP 5.2 but most add-ons will not
  3. If dismissed and the Give core remains active, the notice will reappear after 24-hours

Depending on how this goes, we may urge users using less than PHP 5.6 to update in the future. Note that Give core 1.8.9+ will work fine on PHP 5.2, we’ve fixed one bug preventing it from running that was introduce in version 1.8.

Additional Improvements and Bug Fixes

  • Strong passwords are now required to register a user with Give #1305
  • Added compatibility with XML Sitemap generator plugins (like Yoast SEO) when disabling single give forms views #1690
  • Better sorting of donation forms by amount #1253
  • Improvements to the “File” and “Media” field types #1758

That’s it for now! Check back or subscribe for more updates.

Want more? View the Complete 1.8.9 Milestone


Introducing the GiveWP Developers Blog

We’re excited to announce the launch of our brand new developers blog. Up until this point, most of the product development discussion has been on Github and Slack. While those means of collaboration are important, we felt there needed to be a more public place where our development announcements and updates could live. Enter this blog.

We are now going to post important development news, announcements, and code updates here to ensure everyone has access to the discussion. We think it’s important that our users and developer community know what’s going on under the hood. This is our effort to keep you in-the-know regarding GiveWP development.

What to Expect

Starting today, we’ll be posting regularly about changes within GiveWP’s core plugin and add-ons. The information will be valuable to both users and developers. If you want to engage further, we encourage you to join the conversation on our Slack channel.

A Few Notes

While we love supporting our plugin, this blog is not meant to be an additional support channel. If you have a question, or need support, please check out how support works.