WooCommerce Memberships is a large and complex plugin, but we’ve built it with the aim of being extensible and developer-friendly. This is an overview of how data is stored in the Memberships plugin, which can be accessed via WordPress core methods, WooCommerce methods, or via methods within the plugin.
Our frontend hook reference, admin hook reference, and function / conditional check reference are useful for specific filters, actions, checks, or global functions that will help you while extending Memberships, while this guide provides basic insight into how data is stored.
Membership plans are stored as a custom post type:
Each plan is a post within this post type, so you can easily query all available plans using WordPress core functions, such as
Some pieces of plan data are stored as post meta for the plan’s post, and you can also easily add your own meta for customizations with WP functions. Here are a few meta key / values of interest:
|META KEY||DATA TYPE||STORED VALUE|
|_product_ids||serialized array||product IDs that grant access to the plan|
|_access_length||string||length of access (ie 1 years); not set for unlimited memberships|
|_members_area_sections||serialized array||enabled member area sections for the plan|
Even though plans each contain restriction rules, these rules are not stored as part of the plan’s post meta, and are stored together as an option.
Restriction and discount rules are stored as options for performance reasons. Mosts hosts cache options, they’re persistent on each page load, and they can be accessed easily.
Searching for option names that contain
wc_memberships in your database will yield all options for both Memberships settings and restriction rules.
User memberships are each posts in the custom post type:
This is done to prevent dumping all plan details into user meta (which helps to avoid using serialized data, as it’s not easily query-able) and to improve flexibility.
As memberships are posts, you can easily query membership with
get_posts(), and can leverage postmeta for custom data.
Each user membership post is a child post of the associated membership plan. For example, User 1’s Silver Membership is a child post of the Silver Membership plan.
The member is assigned as the author of the user membership post, and members can be the author of more than one post (which means they can have access to more than one plan). Checking the author of a user membership post will give you the member’s user ID.
The post object contains some membership data, such as the membership status, which is the post status. However, rather than using WP method to get this data, a better approach would be to use the user membership data accessors as outlined in our function / conditional check reference.
A quick example: in the case of the membership status, this will return the status name rather than the post status, which includes the
wcm- prefix in the slug.
The rest of the plan data is stored as post meta for the user membership post, as post meta and can be accessed, changed, and added easily via WordPress core methods.
|META KEY||DATA TYPE||STORED VALUE|
|_product_id||int||product ID purchased that granted access to the membership|
|_order_id||int||order ID in which the membership was purchased|
|_start_date||string||the start date of the membership as YYYY-MM-DD hh:mm:ss|
|_end_date||string||the end date of the membership as YYYY-MM-DD hh:mm:ss; 0 for an unlimited membership|
|_subscription_id||int||if tied to a subscription, this is the ID of the subscription that grants access; not set for memberships purchased via other product types|
|_paused_date||string||the date a membership was paused as YYYY-MM-DD hh:mm:ss; removed when the membership is reactivated|
Membership notes are stored as WordPress comments for the user membership post. Their functionality is very similar to WooCommerce order notes. If a comment was sent to the member, then the commentmeta for that comment will have
notified set to:
Table of Contents
All done here? Return to documentation overview →