Iteration of membership subscription module
For the platform CMS I built myself, the membership subscription part has always been "simple to implement". This weekend I restructured this part and developed the core part.
1. Method
Generally speaking, membership subscription mainly includes three parts: membership subscription plan and purchase, member permission control, and member management.
1. For membership subscription plans and purchases
Just prepare to make some extensions based on the existing mall system.
2. For member permission control,
This needs to be mentioned in particular. We are not planning to do it based on a role permission system, but a separate member-controlled system.
Based on the role authority system, members are made into a role series, and each type of member is made into a role in this role series. It sounds reasonable. However, in this case, it is very troublesome to do or use, especially when there is a lot of business, the various logics will be very complicated, and all kinds of confusion will be caused if you are not careful. And it's not flexible enough.
Moreover, in fact, the membership subscription part of many excellent systems is not role-based. Instead, permission control is implemented based on "marks" or orders. Many well-selling membership subscription plug-ins, including WordPress, are done in this way.
Based on "user tags":
In essence, it is the same principle as the character system. It is to define some "marks" of members. Users who purchase the membership subscription plan associated with this "mark" will be "marked with this mark", so that the control of member permissions can be achieved.
Based on order:
Purchase a membership subscription plan and form an order. After payment, the expiration time will be written into the order. Therefore, you can judge based on the order whether the user is a member, what kind of member it is, and whether it has expired. This way you can control member permissions.
I have done an order-based method before, and this time I plan to use "user tags".
There is nothing wrong with being based on orders, but the order system of the platform CMS I am building now supports many order types, making the order model relatively "large". I don't plan to "add weight" to it anymore, so I chose Based on "user tags".
3. Member management
Based on the existing user management extension, we do not plan to do member management alone.
2. Applicable scenarios
1. Basic scenario
The entire product has one or several subscription plans, which users purchase and enjoy membership services.
Define membership tags globally. Each membership tag contains at least three fields: name, slug, and associated subscription plan id.
When a user purchases a subscription plan with a membership mark, the membership mark and expiration time will be written into the user's meta data.
2. Platform/multi-tenant scenario
For platforms and multi-tenant SAAS, there is a very important scenario: the subscription plan provided by the vendor itself.
Define the supplier's membership tag in the supplier's user's meta data. The key of the supplier's membership tag cannot be the same as the key of the global membership tag.
When a user purchases a subscription plan from this provider, the corresponding membership tag and expiration date will be written to the purchasing user's meta data.
This iteration only implements basic scenarios, but it must be able to be extended to platform and multi-tenant scenarios.
3. Determine whether the membership has expired when logging in
When the user logs in, it is judged whether it has expired. If it has expired, update the member mark in the meta data to false and the expiration date to false.
