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:
|product IDs that grant access to the plan
|length of access (ie 1 years); not set for unlimited memberships
|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
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
, 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
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.
|product ID purchased that granted access to the membership
|order ID in which the membership was purchased
|the start date of the membership as YYYY-MM-DD hh:mm:ss
|the end date of the membership as YYYY-MM-DD hh:mm:ss; 0 for an unlimited membership
|if tied to a subscription, this is the ID of the subscription that grants access; not set for memberships purchased via other product types
|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
All done here? Return to documentation overview →