Hi John,
Thank you for waiting, while I reviewed the video and your existing website's set up.
Based on those observations and some tests that I performed on my own website, here are my findings:
1. Post relationship - structure:
The main limitation that you're currently facing, is that you can't link posts from one post type with another. The good news is that Toolset seamlessly offers this as a built-in feature "post relationships":
https://toolset.com/documentation/post-relationships/
You can structure these relationships as follows:
a). Post Type "User Profiles":
The main post type that will act as an anchor to link each registered user on the website, with other post types. We'll need this, as a post relationship can only be created between two post types and not directly between a post type and a user.
Here is a useful guide on this topic:
https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/
Note: If your goal is to segregate the website's users and the contributors, you can use two separate post types, i.e. "User Profiles" and "Contributor Profiles". The general idea to connect those users with post types will remain the same.
b). Post Type "Superstacks":
You can continue using this post type to store stack packages, it can have a one-to-many relationship with the "Stack Contributions" post type.
( as one superstack can have many stack contributions )
c). Post Type "Stack Contributions":
You can continue storing each stack item in this post type and as mentioned above, the post relationship will determine which superstack it belongs to.
d). Post Type "Redeem Pages":
I understand these posts represent the sales page for each superstack, so you can create a one-to-one relationship between "Superstacks" and the "Redeem Pages".
( if your goal is to only allow one sales page to link to one superstack and vice versa )
2. Post relationship - connections:
Usually, Toolset Forms are used to connect/disconnect posts (which belongs to post types which are already in a relationship), on the front-end:
https://toolset.com/documentation/post-relationships/how-to-build-front-end-forms-for-connecting-posts/
But in your case, you're using third-party form and checkout process to allow users to buy these superstacks. This means that when a user pays for a certain supertack, you'll need to connect that "Superstacks" post to that user's "User Profiles" post, which would represent that this user is authorized to access to this superstack.
This can be achieved using the "toolset_connect_posts" function from the Toolset Relationship API:
( ref: https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/#toolset_connect_posts )
You can consult the documentation or support of your checkout plugin to know about a hook that can be used to fire a certain function after every successful checkout/purchase.
3. Content Protection:
Again, in usual Toolset based website's setup, the Toolset Access plugin is used for controlling content's access:
https://toolset.com/documentation/user-guides/setting-access-control/
https://toolset.com/documentation/user-guides/access-control/limiting-read-access-specific-content/
https://toolset.com/documentation/user-guides/access-control/access-control-texts-inside-page-content/
But since your requirement involves, purchased package based access restriction, you can use a slightly different approach.
Basically you'll need to check:
- if the current user's "User Profiles" post is connected to a particular "Superstacks" post or not.
-- If it is connected then that user should be allowed to access this superstack (and it's components).
-- if not, then this user will have to purchase this superstack first.
For this purpose, nested post views and conditional output features can be used and protected content can be wrapped within those conditional checks.
Post Views:
https://toolset.com/documentation/getting-started-with-toolset/create-and-display-custom-lists-of-content/
Showing related posts:
https://toolset.com/documentation/post-relationships/how-to-display-related-posts-with-toolset/
Conditional output:
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/
Note: this last part about the conditional check using the views can sound a bit complicated, but once that data elements and post relationships are in place, this shouldn't be very difficult.
( I'm not going into more details on this particular point in this ticket purposefully, to keeps things simple )
What important is that this is achievable, and once the rest of the set up is complete, you can open a new ticket, if you're having any challenge in accomplishing these conditional checks.
4. Custom Fields:
Your observation is correct about the existing custom fields and there is an option available to let Toolset take control over them:
https://toolset.com/documentation/user-guides/custom-content/convert-existing-custom-types-and-fields-to-types-control/
It is important to note however that, this will work only for simple text-based fields as other custom field plugins can store complex fields ( e.g. Multi-line, select, radio, checkboxes, image/file etc), in a different format/syntax than Toolset.
In case a large amount of custom fields data is involved and manually re-entry is not an option, you can keep it stored in those existing fields. You'll still be able to show that data in views, using either that plugin's own methods or through direct PHP code. But you won't be able to use those fields for view's operations like search filters, sorting etc.
I hope these findings will help and please let me know if any point is not clear.
regards,
Waqar
