Inicio › Toolset Professional Support › [Resuelto] Can I create a complex membership + marketplace site with Toolset?
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Hoy no hay técnicos de soporte disponibles en el foro Juego de herramientas. Siéntase libre de enviar sus tiques y les daremos trámite tan pronto como estemos disponibles en línea. Gracias por su comprensión.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
- | - | 14:00 – 20:00 | 14:00 – 20:00 | 14:00 – 20:00 | 14:00 – 20:00 | 14:00 – 20:00 |
- | - | - | - | - | - | - |
Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)
Etiquetado: Types plugin
Este tema contiene 7 respuestas, tiene 3 mensajes.
Última actualización por Beda hace 5 años, 1 mes.
Asistido por: Beda.
Hello guys,
We started using Toolset recently and I've almost finished to lay the foundations for all of our Information-CPTs like the Glossary, Customizations and Promotions sections. These are pretty straight-forward, publicly available sections and our admins will just add/edit content as needed now that it's all setup.
This will complete our Phase 1 of update and I'd like some guidance for what's to come as we're now getting in the "juicy" part of our update phases:
> Phase 2: Beta membership
--> Add a way for users to register as Creators (User Role)
--> Add "Creator Profile" menu in WooCommerce dashboard (requires Creator user role)
--> Add "My Creations" menu in WooCommerce dashboard that list product SKUs linked to the User
> Phase 3: Fundraisers
--> Develop the Fundraiser plugin to allow Creators to use their Creations in a Fundraiser Campaign
I will discuss about a lot of things below and I'll do my best to keep things organized and hopefully not too confusing.
---
Obviously, Phase 3 is outside of the scope of the support you can provide but I wanted to mention it so you understand where we're going with this.
Regarding Phase 2, I have an idea on how to approach that but I'd like your feedback as well.
To put you in context, the Creator User Role will have multiple Levels, the first one being the Free level so anyone can create their Creator profile. Users will be able to upgrade their Creator membership according to their needs. In the Beta version, there will only be a Free level with no upgrades available. You will have to create a Creator profile to start a Fundraiser Campaign. The user flow would be as following...
1) Visitor creates an account
2) User can now create a Creator profile via a separate registration form
3) Creator profile is automatically generated and the Creator user role and permissions are granted
4) New menu "Creator Profile" appears in WooCommerce dashboard
5) User can now create a Fundraiser Campaign directly from the "My Creations" page.
---
Alright so, there's quite a lot of things we need to cover to get to that user flow...
Ultimately we want that:
A) Users can manage their Creations easily
B) Admins can register Creations easily while processing orders, ideally also able to generate the proper documentation.
---
Q1) Creator profile creation can be done using different approach but since the beta version will only offer free levels with no paid membership, maybe the quickest way to get that out would be to use Toolset Forms.
So far, do you think it's a good approach to use Toolset Forms to assign a custom user role/permissions to an existing user (i.e: "Creator") via a form in a tab inside the WooCommerce dashboard?
Q2) Can we create a CPT entry based on a Toolset Form submission? The way we're seeing this, the Creator public profile should be a CPT the user can edit at will. Does it make sense that the Creator profile is a CPT?
So when the user fill the form to create his Creator profile, an entry in the Creators CPT is added, which automatically creates a profile. Then, we can display a form in a new "Creator Profile" tab that will allow the user to edit his Creator profile. Note that users should only be able to create *ONE* profile per user. Can we do this?
Q3) Now that a user can create and edit their Creator profile, we need to display the "My Creations" tab and I'm unsure how to do that in the best possible way.
Every time one of our customer creates a custom product, our admins will register a Design (if it's a new one) and a Creation. The Creator can edit each Creations visibility to display them on its Creator public profile. A Creation must be processed into a Product to be added to the Creator profile (more details later). Note that we want to limit the number of Creations a Creator can display on his profile on the Free level to four (4) Creations. Once 4 Creations have their Visibility checked, an error message should be displayed.
A "Creation" is basically a custom product that may or may not be an existing product (you can create a custom product without selling it). This CPT contains at the very minimum a Design (CPT), a SKU (Text Only, doesn't need to be an existing WC Product) and a User ID (Default WP User). It's always tied to a User and the user can display the Creation on its Creator profile, so he needs to be able to edit the Visibility. The Creation Visibility is only configurable once a Creation has been processed into a product.
A "Design" is a set of logos/artworks used to make a "Creation". The same "Design" can be used to customize different products which would each be unique "Creations".
Hope this makes sense.
The hierarchy would be something like that...
> User
>> Design (CPT)
>>> Creation (CPT)
> User
>> Creator (CPT)
An important thing to mention is that a "Creation" is not a product. The Creator still needs to process the Creation to make it into a product that can be sold. This is because our admins can't know some details about the product, like the product short description or the selling price. We still need to register the Design and Creation of each custom products we process, but it's only if a Creator wants to sell a product that a Creation needs to be turned into one, so this step has to be initiated by the Creator.
I'm guessing this will involve custom code as we need to ask the Creator what price they want to sell the product, the final product title, the product description and we need to determine the minimum authorized selling price, etc. The way I'm seeing this, on the "My Creations" page where we have a list of the user Creations, there would be a column "Action" where users can click on a button that goes along the line of "Start Fundraiser", "Convert to Product" (similar to the "Action" row in the orders list).
"Convert to Product" will be required to edit the Creations visibility. Once the Creations is tied to a Product, Creators can add them to their Creator profile. If a Creation is not converted, it cannot be displayed on the Creator Profile.
"Start Fundraiser" would trigger our Fundraiser plugin and will take the user through the steps required to create the Fundraiser Campaign.
Can you steer us in the right direction to achieve this "My Creations" page?
Q4) Assuming we've got all the Creators, Designs and Creations CPTs working nicely together and containing all metadata we need to be able to process a custom order, would there be a way for our admins to generate documentation (Purchase Order, Service Order, Production Sheet, etc.) right from the order edit screen?
Something along the lines of...
> New order received that contains a new design, never made before
> Admin add new "Design"
> "Design" linked to User ID of the customer and contains all artwork files, notes, etc.
> Admin add new "Creation"
> "Creation" linked to "Design" and contains additional model information, colorways, etc.
> In order edit screen, in a section "Order Instructions" there could be a button "Add Item" that allows Admins to add the newly created "Creation" and enter the total quantity needed.
> Admin clicks on "Generate documents" and website generates a ZIP containing the required documents (Excel or PDF format).
In the future, if the customer re-order the same product, Admins only have to click on "Add Item" right-away and select from the existing Creations tied to the user, without creating a new Design/Creation.
I know this is probably pushing it for Toolset but that's exactly why I'm writing this post today.
---
I realize this is a considerable post and I'd like to thank you in advance for your help.
Thank you!
I'll try to answer your direct Questions below as good as possible, please let me know if I missed something, or some detail is not clear.
1. No, Toolset Forms should not be used in the backend (which is where the WooCommerce Dashboard is, unless you created some sort of front end dashboard, but in this case I'd need to know precisely how this was built).
Assigning an other Role to a user thru a Toolset Form is not possible in the vanilla way Toolset creates the forms, but you could hook some custom code to the cred_save_data() hook to change or add user roles while submitting the form.
However I am not sure you really need that. You can create a Toolset Form that users (guests) will use to register themselves and the form can set them directly as whichever role you want, so you could skip this step of creating a user, then upgrading the role.
If you require to change the user role with a form, I can later show you an example code, using cred_save_data(), remove_role() and add_role():
https://toolset.com/documentation/programmer-reference/cred-api/
https://codex.wordpress.org/Function_Reference/remove_role
https://codex.wordpress.org/Function_Reference/add_role
2. Making the creator a post type only makes sense if you need to:
- relate many "user" creator to many posts at the same time
- search thru creators like you can search thru posts
Then you should follow this approach:
https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/
Note, the creator will then be a post type, and that is independent from any user role, so #1 above still would either need to be done in a Post or User Form, it does not matter, but changing the user role still would need custom code.
3. Given question #3, I suspect that you will need exactly what I suggested in #2 above:
https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/
This will solve most of the doubts you face in this point.
You will need relationships to this creator and creation posts, as well as to the related design (depending on the nature of the design this could be a taxonomy, or a different template that you apply on conditions, however, you still would need the above mentioned conversion from user to post type.
That Doc also clarifies how to handle unique submissions, and other aspects of such a mechanism.
3a. To make the creator "buy" or "create" a product are 2 different things, however both would be possible with Toolset.
Create products can be done following https://toolset.com/documentation/user-guides/creating-woocommerce-products-using-cred-forms/, and connecting forms to products so the people must purchase that first before they can publish a post or edit it, can be done following https://toolset.com/documentation/user-guides/using-cred-commerce-to-add-payments-to-forms/
4. No, at least, not with Toolset
Again here, Toolset does provide most of it's features for the Front end (display, forms) and in the backend it allows to add fields or taxonomies, but not to fully alter the admin screens of other plugins.
This would need to be done with Custom Code.
A possible approach with Toolset is, to use Toolset Forms notifications.
Notifications can be added to any Toolset Form and they can send data to people outside the site, or users, or submitters, as you choose.
Then You can also send data about the form, the post or user created/edited and even views, so you can send totally "unrelated" data in the notification, or even Posts, that are related to the one currently edited by the Form.
This is not simple to achieve and requires a separated ticket if you need assistance with this, as it is a "whole topic on its own".
You can start reading with the Forms Notification DOC, and experimenting with this:
https://toolset.com/documentation/user-guides/automated-email-notifications-with-cred/
That would be a way to send that data somewhere (not necessarily in PDF or other format, but as a email).
This would not be done in the WooCommerce Admin, but somewhere on the front end.
Hello Beda,
Thank you for the detailed reply and links, this is very helpful.
When I mention the WooCommerce Dashboard, I'm referring to the front-end page where we have the customer My Account page (enlace oculto).
Regarding user roles, this is still a concept I'm trying to wrap my head around in the context of WP, but I'm not sure why WP limit us to have only one role assigned to a user. We use the plugin User Role Editor which allows us to assign additional user roles.
The default user role must always be "Customer" as our Sample Approval System displays a list of Customers in a drop-down menu that our admins can select when uploading a sample for a customer order.
The approach I'm considering is having different user roles like "creator_free", "creator_lvl1", "creator_lvl2". These roles will be used to determine the limitations of each membership so that if a Creator on the Free level tries to enable a fifth product on its profile page, an error message would be displayed, prompting him to upgrade his membership.
In the user "My Account" page, I'd like a tab "Upgrade" that displays our various memberships in a cards-style like so:
Creators Membership
[ Free ] [Premium] [Unlimited]
[ - ] [ $7.00 ] [ $27.00 ]
[ ACTIVE ] [UPGRADE]
Authors Membership
[ Free ] [Premium] [Unlimited]
[ $0.00 ] [ $17.00 ] [ $57.00 ]
[REGISTER] [ BUY ] [ BUY ]
This would be done via custom code. Clicking on Buy/Upgrade would redirect the user to the proper form.
I think the best way to handle the recurring payment would be to use WooCommerce Subscriptions. After reading a bit here I have a question: https://toolset.com/learn/create-membership-site-wordpress-using-toolset-plugins/how-to-use-the-woocommerce-subscriptions-plugin-with-toolset/
Is there a workaround to enable different user roles or what would be the best approach to address our use case?
Assume a user can be a Customer, a Creator that sells products and an Author that publishes blog posts and that Creators and Authors each have different subscriptions and costs.
---
Alright so making the Creators profile a CPT do indeed make sense and I have a path to get that setup with the link you provided.
Regarding the publication of products, here's what the ideal workflow would look like...
1) User has an active account since a few months during which he has made 5 different orders for 5 different custom hats. Our admins have registered these 5 Creations under the User profile, which are displayed in the WooCommerce My Account page under a new tab "My Creations".
2) Now ready to get started with his own brand, User creates a free Creator profile (maybe a WooCommerce Subscription that costs $0.00, would there be any advantage to go through a free subscription rather than just adding the user role?).
3) Now that the User is an active Creator, a new button "Convert to Product" is displayed in the column "Actions" when viewing the list of entries in "My Creations".
4) User clicks on "Convert to Product" on one of his creation and is redirected to the form that will take him through the steps to complete the product creation (Product Title, Product Short Description, Product Price). Note that the product should still be a draft upon conversion and our admins will have to review it before it can be added to a Creator profile. Maybe this can be done with a custom field to flag the status like "approved:0/1"?
During this step, the form should also *ideally* calculate a minimum selling price. The easiest way to approach that would be to have our admins simply enter a value manually when they register the Creation and use that value as a minimum during the product validation. However, in the future we will want to be more clever about that, the most obvious reason being that our supplier prices may change and the minimum selling price for our creators might change, so the value that was entered at the moment the creation was made may not be valid anymore to sell a product.
You said the product creation could be handled by Toolset Forms but I had already planned to have custom development for that as I don't think it can cover that kind of particular scenario. Can you confirm? We are also considering to have a calculator with a slider that the user can drag to determine how much money he want to earn per sale and it'll automatically calculate the selling price.
5) Our admins review and approve the product, then the Creator is notified via e-mail that his product was approved. (Not too sure how to implement an easy way for our admins to notify Creators yet though...?)
6) The Creator goes to the Creation edit screen where he will now be able to access the "Visibility" settings
7) The Creator enables the product on their "[X] Creator Profile". This publishes the product (changes from Draft to Published).
8) Going into the User My Account > Creator Profile tab, a section "Products" displays the product that was just assigned. Users can edit the visibility of their products from the Creation edit screen or the Creator Profile edit screen.
9) User repeats steps 4-5 for all of his Creations
10) On the fifth Creation, when trying to repeat steps 6-7, the User will not be able to check the checkbox (could greyed out & disabled) to enable the Creation on the Creator Profile as the User with role "creator_free" has reached the maximum limit of (4) active products on his Creator Profile. The error message would offer the user to be redirected to the "Upgrade" page.
In this scenario, could you confirm what will be custom development and what can be handled directly with Toolset?
---
Last thing (hopefully) I want to clear out before I start to experiment with all of this...
I'd like some guidance to configure our Designs CPT and its relationships.
I have determined that you do not have to be a Creator to be able to create Creations (every customer that makes a custom product is indeed making a Creation). That tells me that Designs should be tied to Users, not Creators.
A Creator is also necessarily tied to a User, which gives us the following structure:
User
-Creator
-Design
--Creation
---Sample
Sample CPT: Used to register each Sample made for a Creation. There can be more than one Sample tied to a Creation but a Sample can only be tied to one Creation. Contains the different pictures for the Creation, the creation date as well as a flag to indicate if the pictures are an exact representation of the Creation (Yes/No).
Creation CPT: Used to register all Creations that uses a specific Design. There can be more than one Creation tied to a Design but a Creation can only be tied to one Design. Creations are created by our admins when processing orders, if it's a new Creation. Contains the various product data our admins can already pre-fill for the product creation process (SKU, Taxonomy values for our product like Colors, Brands, Sizes, Product Category, etc.). Also contains the "Visibility" settings, which should be locked somehow until the Creation has been processed into a product.
Design CPT: Designs are also created by our admins when processing orders. They contain the design instructions to realize a certain custom product like the artwork file(s) URL, production files, etc. as well as a reference to all Creations that uses this design. When we edit a Design, is it possible to display a read-only list of Creations using the current Design?
Creator CPT: Contains the Creator Profile data (About, Founded in..., Story, Mission, Logo, etc.) as well as a unique reference to the User ID (I'm guessing that would be the Post Author).
So I have all of these CPTs created but I'm still unsure how to configure their relationships.
Currently the "Design" CPT has a relationship many-to-many with WooCommerce Orders. This was done in an effort to connect Designs to the Order back-end so that our admins can create/assign Designs and Creations directly while processing orders. I'm not sure this workflow would work without some heavy customization though so it might be better to get rid of this.
I believe that to make it simpler, our admins should open a new tab when they process an order and register any new Design and/or Creation separately. Then we'll have to figure our a way to develop a document generator based on the data entered. Something really neat would be to have a simple form where you only have to enter the Order ID and the system would pull a ZIP file containing our Purchase Order, Packing List, Production Sheet, Service Order, etc.
Anyway that's another story, let's come back to the CPTs relationship. If I understand well... The Creators CPT has no relationship to the User other than through the Post Author. The way we ensure there's only One Creator <-> One User is through the Loop in a custom view where we will either display a Toolset Form to let the user register (empty results for "Creator" CPT that belong to current user) or we will display the Toolset Form to edit the existing Creator entry (pretty clever by the way).
I have then created a relationship one-to-many from Creators to Designs.
I also did create a relationship one-to-many from Designs to Creations.
... and another relationship one-to-many from Creations to Samples
Now I'm a little bit confused because I was under the impression I would add the Creations as a CPT-onomy in Design, and Designs as a CPT-onomy in Creators but I don't think it's what I've been meaning to achieve.
I re-read the description for a Taxonomy and since Samples, Creations and Designs will not be used to group different posts together (they rather serve a purpose to provide additional information to the Creator object), they probably have nothing to do with Taxonomies and they will be linked through relationships instead.
So far am I making sense with all of that or am I going in the wrong direction?
---
Thanks again for your patience and assistance Beda.
Wishing you a great weekend ahead.
All best,
B
1. Related to the Dashboard, if it's a page that you style with a Content Template or Layout, then yes you can add much more controls to it.
You would work with Forms, and Views, to create a dashboard experience where you list (with Views) things that you can do or edit (with Toolset Forms).
It would not really matter if you want a user to edit a product, create one, or other posts of other types, or connect posts or else enrich content - you can do most with Toolset in the front end, if you combine Forms and Views.
It is a question of management wether you do not prefer to limit access to the existing WordPress dashboards with Toolset Access, or rebuild a similar experience with Toolset Forms and Views in the Front end.
However at this point, this would be a topic, on how to do certain things in the front end that usually are done in the backend or remind of those dashboards.
We would assume a page that is the dashboard and then talk about how to add "menu's" or other kind of interactive elements, but we would require to do this in a separate ticket, because it will include a lot of technical steps, amongst the "how to's" in general.
Generally speaking you can - depending on the amount of time you invest - create almost any kind of dashboard in the front end that will allow highly powerful actions or simple links and menus placed in the layout.
It requires deep understanding of HTML and CSS/JS, and knowledge of how to use Toolset for it. We can help with the latter in a dedicated ticket.
I would start this with the exact elements you want to bring in that dashboard and Support can then guide how to link, edit or else manipulate and interact with in the front end.
2. WordPress or Toolset do not restrict a user to one role only, in fact a user can have many roles, and Toolset will respect those, however neither of (Toolset or WordPress) lets you directly assign many roles to a user. For that other software or code is needed. There are plugins that do this as well, or code:
https://stackoverflow.com/questions/27420705/how-to-assign-multiple-roles-for-a-user-in-wordpress
The thing is, Toolset Forms for users cannot do that (assign many roles) or edit them
You would need 3rd party logic for this part.
3. Related to the membership process you outline, I suggest having a look at this https://discover-wp.com/site-types/membership-layouts/
Install it locally, with Framework Installer, or on a testing site, to see how it's built and the features it covers.
There are more such templates here, https://discover-wp.com/site-templates/, ready to be used or re-used.
They mostly cover details about memberships as you outline them, they do not play with multiple user roles for the reason that Toolset does not "add" those, however, you could always show or hide content depending on several (or just one) role, with Toolset Access, specially with this:
https://toolset.com/documentation/user-guides/access-control-texts-inside-page-content/
It allows quasi fine grained control over each paragraph anywhere you insert the ShortCode and determine who can see what, so you can really fine tune who can see what and when, also combining this with HTML conditionals, that allow to check upon meta data, so for example, amount of posts (if this number is saved in a custom field, or for example, returned by as ShortCode)
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/
4. Related to https://toolset.com/learn/create-membership-site-wordpress-using-toolset-plugins/how-to-use-the-woocommerce-subscriptions-plugin-with-toolset/, there is no tested official way, but I would suggest to ask there:
https://toolset.com/learn/create-membership-site-wordpress-using-toolset-plugins/membership-sites-support/
This is because the support for the learning parts is handled there - and it will be best way to confirm if there is a suggested way to do this (as far I know there is not, for the reason Toolset only adds support for those roles if existing, but does not add them themself)
5. I however think it is not a correct approach to have one user with many roles at different payment levels.
A user should be at one payment level or, if the payment level is different, then that payment should be related to completely different content.
This means, the user is able to have many levels, but not on the same "product" or content, and hence, you don't need to worry about the different roles, but can differentiate the levels already with the "type" of your content.
If a user or role A; B; and C, has access to content of type D, E, F, and each of those payment levels is different, it's not issue to create that as it would (with Toolset) involve 3 forms, each bound to one product, each form targeting different content all-together.
This is something you might want to think about, instead of having the same content, and only separated by user roles levels.
6. The relationships seem to require mostly one to many, according what you describe, see:
One WordPress user abhors one Creator Post
One Creator Post to Many Designs
One Design To Many Creations
One Creation To Many Sample
You can display each data on each other. So you can have a list of Samples on the Creator Post, a link to the Creator on the Sample's list, or a hint of the samples of a certain design of the current creator, whatever you like
The trick here is to understand that you need Views to create lists, and can nest Views inside each other to call related data, and that you can do this infinitely, so you can call parent of parent of parent data, or in other words, related to related to related to data, and so forth.
It's like a "loop that you place in a loop" and the nested loop will act on the one (current) post in the parent loop.
Lists will be output like this for example:
- Parent Item
-- eventual related list item
-- eventual related list item
-- eventual related list item
- Another Parent Item
-- eventual related list item
-- eventual related list item
--- -- eventual related list item to the eventual related list item
- Another parent.
I think this should illustrate that you can display basically any related information at any time in any place.
A little tricker it is to search by, here Toolset offers only a one or 2 layer depth, meaning you can scan a relationship for several steps of relations but not many relations - and also you cannot filter by data of related posts (so for example when you list Designs, you can show related Creations but not search by Creations Fields, in that very list.
You can of course search for that if you would list Creations.
This is a topic that I suggest, if it's not clear how this works, ask in a separate ticket to show this on an example, or you can start with the topic here:
https://toolset.com/documentation/user-guides/using-a-child-view-in-a-taxonomy-view-layout/
https://toolset.com/documentation/post-relationships/how-to-display-related-posts-with-toolset/
These 2 posts are very helpful to understand this logic.
7. Toolset Forms covers a basic scenario of creation and editing of Products of WooCommerce:
https://toolset.com/documentation/user-guides/creating-woocommerce-products-using-cred-forms/
You will need custom code for that but maybe Forms can help to allieviate the design part and eventually you can use the hooks of Toolset Forms to alter the behavior of the forms
https://toolset.com/documentation/programmer-reference/cred-api/
8. Notifications can be sent also with Forms, see this https://toolset.com/documentation/user-guides/automated-email-notifications-with-cred/.
It also has some hooks you can use to customize them with code.
9. I am not sure what you mean with CPT-onomy, if you mean the plugin that makes Post Types be Taxonomies, Toolset does not support that, it will break the post types and relationships most likely.
I suggest either use Taxonomies or Post Types, specially if you want them to be in relationships of Toolset
10. You use taxonomies to cateogorize and CPT to put content in it. In a shelf with jars the jar is the post, the shelf the post type, and the label that say "cherry" or "peer" are the taxonomies. These labels are not on one jar only, but on many, within the same shelf (so, the taxonomy term "peer" is on many posts of type marmelade).
But, in your case that would be Creations, and Designs, etc.
Hence you need to determine what each is (is it something, or does it categorize something?), then create taxonomies or posts.
I suggest, to open a ticket for by each of the above points in case any of them is not clear
These things may all seem related, but it is important to spit them apart in actionable tasks, both for Support and yourself to act upon.
I would suggest, to start with the simplest outline you can imagine of your project, and from there, with each single issue you face, and cannot solve eventually, open a ticket with us, so we can handle each promptly and precisely
Thanks!
I hope I haven't missed anything.
Hello Beda,
Thanks again for your detailed reply, I'm learning a lot through your answers.
Going forward I'll create a ticket for each issues mentioned in this thread so that it's easier to follow-up. There was just so much stuff to cover that it felt counter-productive to open dozens of tickets.
I'd just like some clarification about a few things so that I can go ahead and dive deeper into the rabbit hole.
---
1) Currently, we use the [woocommerce_my_account] shortcode and we use the default WC hooks to alter the content of this shortcode. If I understand well, we could recreate this page entirely with Toolset, correct?
One thing I'm worried about with that approach though is that some plugins rely on the default WooCommerce pages. For example, we have a "Print PDF Invoice" plugin that adds a "Print" button in the "Action" column when viewing the WooCommerce Orders list in the user My Account page (front-end).
Could we use Toolset to display the customer Orders list just like the WooCommerce default loop or will using Toolset to display this necessarily breaks compatibility with other plugins?
---
2) Reading through the link you provided, it seems pretty trivial to assign a role to a user so can you confirm we can fire some custom code when a Toolset Form is submitted? So adding custom code to a Toolset Form should allow us to assign multiple roles.
---
3-4-5) What you've mentioned in #5 has big implications in our memberships structure so it's probably worth getting this right.
You said we should not "have one user with many roles at different payment levels" and "A user should be at one payment level or, if the payment level is different, then that payment should be related to completely different content.". I feel like this needs to be clarified a bit as I'm not sure what you mean.
WooCommerce Subscriptions support grouping multiple subscriptions for the same user (https://docs.woocommerce.com/document/subscriptions/multiple-subscriptions/ and https://docs.woocommerce.com/document/subscriptions/develop/multiple-subscriptions/).
The idea would be to create a Variable Subscription for "Creators" using an attribute "Plan" that has the following values "Free | Plus | Pro | Unlimited".
You can only have one level active at the same time for a given membership. You can't be both on the "Creator - Free" plan and "Creator - Pro" plan so you can't have both roles "creator_free" and "creator_unlimited". You would however have both the "customer" role and "creator_free" role if you're on the Creator - Free level. Also, if you decided to subscribe to the "Authors" membership (which also has levels/upgrades), you'd end up with three roles: customer, creator_free and author_free. Is there something wrong with that?
It's still unclear if we should be better using separate products for each subscription but using variable subscriptions to bundle plans together seems to make more sense.
In term of the content tied to each subscription level, it's pretty much the same on all levels of a given membership.
A Creator on the Free plan vs a Creator on the Unlimited plan both have access to the same pages. One of them is however more limited in term of how many products they can publish. We may want to give access to more analytics and tools to Pro and Unlimited users but that would be entirely relying on custom code, probably based on the user role.
An Author, however, would have access to a new section to participate in our blog that Creators don't have access to. All authors have access to the same section, but their publications would be limited according to their active level.
---
6-8-9) I'll open a new ticket for this.
7) For now that information will suffice. We do not plan to have the Creation->Product conversion user-initiated anytime soon, which is required for our Creators to sell products easily. Our current target is to have the Fundraisers system working smoothly, product conversion will be handled manually, but designs and creations must be recorded properly for this to work.
As always, thank you for the support! ♥
Hi Beda is out for a few days so I would like to jump in and try to help.
1) Currently, we use the [woocommerce_my_account] shortcode and we use the default WC hooks to alter the content of this shortcode. If I understand well, we could recreate this page entirely with Toolset, correct?
If you want to recreate this page with Toolset, you'll be doing so from scratch. That means any integration with other plugins would have to be coded along with your changes. Other plugins won't be plug-and-play here by default. You could create a list of Orders, sure, but it won't be automatically hooked in with other plugins.
2) Reading through the link you provided, it seems pretty trivial to assign a role to a user so can you confirm we can fire some custom code when a Toolset Form is submitted? So adding custom code to a Toolset Form should allow us to assign multiple roles.
Yes, the Toolset Forms API includes a callback that can be triggered when any Form is submitted successfully. You can add whatever code you want to manipulate the post or User that was just created/edited.
Also, if you decided to subscribe to the "Authors" membership (which also has levels/upgrades), you'd end up with three roles: customer, creator_free and author_free. Is there something wrong with that?
Multiple roles makes managing conditions and restrictions more complex. Let me check with Beda tomorrow and see if he had something else in mind. I'll give you an update as soon as I can.
I was incorrect about Beda's schedule - he actually isn't back at work until tomorrow. I've sent him a message and hope to receive some follow up information for you tomorrow.
Hello, I am Back. Let me add some details to what Christian already outlined.
1. I would not suggest using Toolset for this, as Toolset WooCommerce Views is made to customize the Shop (products archive), Product Category archives and single Post Template.
Not the checkout, user account page or other assets of WooCommerce
Especially, I would refrain from experiments in that direction (it is and may be possible to extend Toolset functionality to those areas with custom code), because you already rely on 3rd parties there that in turn rely on native WooCommerce output, so I would not undermine that already working part with this, since it's simply not what WooCommerce Views is built for.
I would use it only for the shop, products and the searches.
2. You can display orders, as Toolset Views adds some code to make them public and hence you can add Views, that list orders, and order/search them by related data. For this, you don't need to alter WooCommerce templates, as you can simply put a View anywhere on your page that does this.
3. It's not the "adding code to a Toolset Form" that will actually allow you to assign more than one role to a existing user. That's just the carrier, the box in which you send your custom code, that fully relies on WordPress API and it's support for many roles.
The Toolset form is the container, that when used (the form is submitted) has a few "hooks" on it (really, imagine it like physical hooks).
Those hooks pop out of the box at certain moments - so one hook will be there when the form is submitted, another when the form actually saves data to the database, another hook is there when this is done, and so on and forth (you can see them all listed in the link provided).
Hooks are generally something that WordPress offers, those hooks are just made by Toolset, as specific to Toolset Forms.
But the Principle is the same as WordPress hooks. https://toolset.com/documentation/programmer-reference/cred-api/
So, once you know at what moment, or what hook you want to "append" your custom code to (usually, it is the moment when data is saved, but that may differ from use case to use case), you create a code, that does exactly what you want to happen.
So, all you do, is take your custom code and "hook" it to that box which is the Toolset Form.
That box then travels thru the process (the form is submitted, for example) and your code, added to the hook, will be executing at that precise moment.
I hope this helps to understand why I say, it's not Forms that adds the roles, it is your code.
The code is added to a form, that's all.
The code could also be added to a save_post action, or literally any other hook offered by WordPress at several moments in the life of a website.
It will always depend on the code you hook (your custom code) if things works, or not. The hook itself, just makes sure your custom applications get fired, that's basically all (and It offers some data for you to use, but that is another topic 🙂 )
This being said, yes you can add multiple roles to the users, but Toolset forms does not offer any inbuilt functions, code or settings, to help you with this. It only offers the hook where you can add the custom logic to do so.
Now, later in Toolset Access it will be very similar.
You have no choice to control how many roles that user has in Toolset Access, however Toolset Access will respect the eventual roles that have been assigned to any user, by above explained (or other) workflows.
This means if you have an user with 2 roles, both rules will be respected by Access. So this user, if he has a role that can see posts, another role that cannot see posts, will obviously always see posts as always the higher role will be applied.
There is no possibility in applying the lower role in access, as there is no method to differentiate as what role the user is supposed to act right now, it only allows to have several roles per the user, but they always act simultaneously.
So the higher limits are "boundaries" to access. (And WordPress, as well).
And concluding, yes you can fire the custom code when the form is submitted, and if crafted appropriately that code will add the desired roles to the users. Note, it will depend a lot on when you do that, so for example, in a form creating users, you must use any Forms Hook that happens after the form submits, and saves the data.
Not before, as there you wouldn't have any user to manipulate yet.
4. Related to using several roles or not, this is surely a question that ends in a different answer for each project.
I generally don't use several roles, or multisite, or in a more general phrase, I do try to not add too many layers to single objects, whenever I build a website.
Of course, sometimes it is required or makes more sense to use those tools like a Multisite offers, or like several roles or subscription models that act on the same object at different levels.
My suggestion here is not a "don't do this", but rather a "be sure you need it".
It can complicate processes quite a lot. Especially with Plugins that handle memberships or subscriptions, they are often already ready to also create the users.
Now, in those cases it is often better to just use that plugin, and not mix in another software that also creates, and manages the users.
For example, Toolset Forms will not offer support to eventual complex fields that a subscription plugin might offer in a WordPress user profile. You could add them with Toolsets control over 3rd party fields to Toolset Forms, but only "simple* fields, and often, it won't work because the 3rd party expects some custom formate to be stored.
Hence my reasoning to always try the minimal possibility, but if the requirement is there, or simply it makes more sense from organizational view, then of course using these features is never wrong.
Please let me know if something remains unclear!