We're often asked how data is handled and stored/retrieved in MemberPress. MemberPress relies on the WordPress database for all of its data storage. We use many of the built in WordPress tables, and we also add a few additional tables as well.
MemberPress relies completely on the WordPress API for creating, storing, managing, and authenticating Users. Therefore members are stored in the typical WordPress users and usermeta tables. This also means that a MemberPress User would not need a second account to login to other plugins that also rely on the WordPress API for user management such as BuddyPress, bbPress, WooCommerce, etc.
MemberPress custom field values that your members fill out when registering or updating their account pages can be found in the usermeta table. These values can be grabbed using the standard WordPress usermeta calls like get_user_meta().
MemberPress uses multiple Custom Post Types to store various data. Because we use Custom Post Types, the data for these objects is stored in the WordPress posts and postmeta tables. We use the following Custom Post Types:
Memberships – Memberships are stored as a public custom post type (capabilities of a Page by default). The custom post type key is memberpressproduct
Groups – Groups are stored as a public custom post type (capabilities of a Page by default). The custom post type key is memberpressgroup
Rules – Rules are stored as a hidden (non-public) custom post type. The custom post type key is memberpressrule
Coupons – Coupons are stored as a hidden (non-public) custom post type. The custom post type key is memberpresscoupon
Reminders – Reminders are stored as a hidden (non-public) custom post type. The custom post type key is mp-reminder
Courses – The Courses from MemberPress Courses add-on
Lessons – The Lessons from the MemberPress Courses add-on
Files – The Files from MemberPress Downloads add-on
MemberPress stores most of its options in the WordPress options table in a row with the option_key of mepr_options. The options are serialized and stored in that row. Various other options and settings are also stored in the options table. Their option_key‘s start with mepr_ or mp_.
Our various add-ons may also store some information in the usermeta or options tables as well.
The MemberPress database version is also stored in the options table with an option_key of mepr_db_version.
Additional MemberPress Tables
MemberPress tables will try to mimic the character set and collation of your regular WordPress tables. This is most typically utf8mb4_general_ci or utf8mb4_unicode_ci.
MemberPress relies on secure payment tokens or ids when creating and managing subscriptions. No Credit Card or other payment data is stored in your WordPress database with exception of the last 4 digits and expiration date so reminders can be triggered when Credit Cards are expiring on automatically recurring subscriptions. All other meaningful payment data is stored securely at the gateway level (Stripe, PayPal etc).
The mepr_subscriptions table is where we store the objects for Automatically Recurring Subscriptions. These objects are essentially containers for managing automatically recurring payments and associating Transactions that belong to this subscription together.
The mepr_transactions table is used for storing all of a user's payments (free or paid). MemberPress uses the Transactions to determine if a user has access to a Membership, and for how long. It does this by looking at the expires_at date of the Transaction, and if it's status is complete or confirmed.
A Transaction with an expires_at date of NULL or ‘0000-00-00 00:00:00' is considered to Never expire.
Both One-Time and Auto-Recurring payments are stored in the Transactions table. If the transaction has a subscription_id, then it is considered to be part of an automatically recurring subscription.
Transactions of type “subscription_confirmation” with a status of “confirmed” are hidden in the UI, and are used as a way to provide free trial periods and the 24 hour grace period on a recurring subscription signup.
The mepr_members table is purely for speed/convenience in some of the MemberPress queries. Anytime a member triggers some event, like signing up, being refunded, cancelling a subscription, renewal payment etc. Certain information about that member is calculated and stored in this table. All of this information can be gathered by inspecting the users, usermeta, mepr_subscriptions, and mepr_transactions tables as well, however we consolidate it also in this table to help with some of the MemberPress queries and CSV exports.
The mepr_events table is used to store a log of events that have happened. Such as a user logging in, new signups, renewal payments, reminder notifications etc. This table can grow quite large over time, so it would be okay to trim events that were at least a year old. We don't recommend trimming events that aren't at least a year old, especially if you rely on a number of reminders that span large time periods.
The mepr_jobs table is used for storing background jobs (via WP Cron) that need to be completed such as Background email sending. MemberPress has utilities that Developers could use to schedule their own background jobs if needed. For example, maybe you want to integrate a new payment gateway, but it doesn't support auto-recurring payments, so you need background jobs to make sure the payments happen manually on schedule.
Rule Access Conditions
Although Rules are stored as Custom Post Types the mepr_rule_access_conditions table is used to store what memberships or members have access to the content the Rules are protecting.
Corporate Accounts add-on adds a mepr_corporate_accounts table for associating parent accounts to their sub-accounts.
MemberPress Courses add-on adds wp_mpcs_sections and wp_mpcs_user_progress tables.
MemberPress PDF Invoices add-on adds wp_mpdf_credit_notes and wp_mpdf_invoice_numbers tables.
MemberPress Downloads add-on adds wp_mpdl_file_downloads and wp_mpdl_file_stats tables.