Create a membership site with Toolset – new tutorials available

   Agnes Bury

Announcements

October 19, 2016
64

We have released a series of tutorials on how to create a membership sites using Toolset. Beginners will learn how to create custom roles, custom signup and login forms, lost password pages and how to restrict access for certain pages or custom post types. Advanced Toolset users will see more advanced applications of Toolset features, such as using child forms, to allow members to sign up for different activities.

Topics covered

  • What is a membership site?
  • Setting up user roles
  • Restricting access to content
    • Restricting read access to a Custom Post Type
    • Restricting read access to specific posts or pages
    • Restricting read access to some parts of the articles
    • Restricting access to video tutorials
    • Restricting access to downloadable files
    • Allowing members to sign up for special activities
  • Handling user registration and account management
    • User registration
    • Login form and account management
    • Custom Lost password pages
  • Charging fees for membership
    • Charging fees for time unlimited memberships
    • Handling recurring payments

Visit the tutorial page

Vote for new features

When working on this series we identified several features Toolset is missing.

Here are some examples:

  1. With CRED User Forms it is not possible to change the role. Implications:
    • There is no way to automatically upgrade the subscriptions (e.g. from the Premium to the VIP membership).
    • You cannot approve user signups directly from the front-end (e.g. to change the Subscriber role to a higher one). You need to do this from the WordPress admin.
  2. CRED User Forms don’t have the “expire” feature which Post forms have. Implications: to create time-limited accounts (subscriptions that automatically expire) you need to buy and use the WooCommerce Subscription plugin.
  3. When CRED User Forms are used along with WooCommerce (to charge fees for creating accounts/adding posts) users need to enter some data twice (email, first and last name)
  4. There is no easy way to automatically renew an expired post created with a CRED Post Form if you want to charge fees for doing so.
  5. You cannot create a custom search based on users. Implications: you need to “mimic” user profiles with a CPT, which causes issues.

Developing new features takes time and we would like to use that time effectively. You, as our Toolset users, now better than us which features matter most.

Please use the comments to let us know which of the features listed above you would like to see in Toolset and what other features you find lacking in Toolset for creating membership sites.

If you like the new series, please let us know as well.

 

Comments 64 Responses

  1. Great to see this post.

    I really could have used it weeks ago, but really appreciate it being available now.

    In currently finalising my first membership site, there’s a few really key steps involved that I didn’t previously appreciate; particularly when it comes to managing recurring payments.

    Thanks again for putting this together.

    PS. There’s a minor typo on the “Visit the tutrial page” (sic) blue button on this page.

    • Thanks Stephen,
      you are perfectly right: handling recurring payments matters from the business point of view – if your user is forced to register/post something anew (meaning filling in all the data again) you may lose him/her. Renewing with one click definitely helps.

      Toolset offers some possibilities here as well (you can set expiry date for Post Forms created with CRED) and we are considering providing something like this for User Forms (if a user doesn’t renew the subscription his/her role changes to a “weaker” one (with limited privileges) but the WooCommerce Subscription is more flexible.

      Since our WooCommerce Views plugin integrates well with the WooCommerce we recommend using the WooCommerce Subscription add-on for handling recurring payments.

      • All ok Agnes.

        Actually my use case is to (just) manage annual subscriptions that are linked to custom roles. However, it took me a long time to even work out that this is what I needed.

        Now I realise that my project has evolved into a very customised solution.

        Your post confirms that membership sign-up, annual recurring payments, and links to custom roles CAN be achieved with Toolset and the WooCommerce Subscription add-on. It’s somewhat annoying that the add-on is an additional recurring (annual) cost, but for now I’ll live with that.

        The concept of reducing a role for non-renewal of a membership is not something that I had considered, but will now explore.

        In the meantime, with these new tutorials, I’m more confident of having my site go live in the coming weeks, if not days. 🙂

        Thanks again.

        • The concept of reducing a role for non-renewal of a membership is not something that I had considered, but will now explore.

          Yes, this is how the WooCommerce Subscription handles and this is the feature we consider implementing for CRED User Forms. With CRED you could set it up for each form, meaning that you could set different combinations for different membership plans.

  2. I’d really like to see a business directory tutorial, including options to display membership categories and sub categories, a searchable directory, payment options, business membership entries using cred and a view for each business with business info images and map etc. I bought toolset specifically for this purpose (but I am still very much at the learning phase), so a helping hand in this direction would definitely make me a happy camper!

    • Hi Al,
      good to hear that you are learning Toolset possibilities. I think it’s good to know/understand Toolset features first and then to think how you can use them for your project and specific applications.

      Everyone understands a business directory a bit differently, so if you have any specific questions to ask, please use the Membership support page. Building a business directory comes down to putting different pieces together so knowing all Toolset features, including the ones offered by Toolset Views, is a must in this case I guess.

  4. 5 All day long… mimicking user profiles is a bit of a headache, at the moment users have to register, then I need to use a workaround to ensure that the first time they sign in they complete a user profile form.

    I’m had to put a review membership site on the back-burner while I completed some client work, but I fully intend to return to it, so I am really happy OnTheGo are putting some thought into this. I much appreciate your tutorial.

    I have several useful support threads, where Beda, Luo, Nigel and others patiently led me through many of the problems of Membership sites, however some are more useful than others.

    https://toolset.com/forums/topic/using-author-archives-as-user-profiles-to-be-viewed-by-other-users/
    http://pastebin.com/Y1pWeJnP

    In this thread, Beda helps me with lots of little snippets and the basic save_before_data_ action CRED code for creating a custom post profile at the same using a CRED user registration form.

    There are also some really useful snippets for redirection, ensuring users only create one post type and more.

    I hope others find it useful. One day when I am finished with my site, I will upload every solution I used and all the linked support threads etc… (one day lol)

    • Hi Jeff,
      thanks for your valuable feedback! Before I read that detailed thread, please help me to identify your initial problem – for your ‘book review’ site you needed to display user profile data for all visitors (which turned out to be impossible) and you wanted to display reviews of each author, again for all visitors?

      Your case proves that we should:
      1. either add new features to Toolset to make it possible
      2. or if this is achievable with simple custom coding and snippets, post a tutorial explaining the details

      and you vote for the #5 feature I listed above? Am I right Jeff?

      • Hey Agnes. You are right, my focus was on voting for #5 primarily.

        Anyway, apologies if I muddied the water a little.

        The support thread is old, and the test site is defunct though still up. I created that site really just to test the capabilities of Toolset to see if it was right for me.

        However, in that thread I was discussing with Beda options for Members profiles. A previous thread with Nigel suggested just using User Archives, but I figured that was too limited. I decided to go with Member Profile and ‘book’ CPTs as parents of review CPT.

        The problem with this approach is the need for a user to register, then they need to sign in, then they need to create a membership custom post type before being allowed to do anything else on the site, or things start to fall apart.

        If you have users who haven’t created Members CPTs who start reviewing books, you have a problem.

        So you need to restrict and redirect them, until the Membership CPT has been made.

        If someone signs in, it needs a custom snippet to query if they have a post type, if not conditionally display (using a shortcode) the CRED create post form for Member CPT, while at the same time restricting access to the site, so they basically can’t do anything on the site until the Membership CPT is made.

        It’s all a little convoluted, but Beda provided me with a snippet to check if a custom post type had been made, and snippets for redirection.

        The cred_save_before_data_action snippet allows you to create the membership CPT at the same time as registering with a CRED user registration form, which is amazing. It’s now a one step process, register and create profile at once… wow!

        However, these are quite tough to get your head around, and a lot of us users are (or were) novices, choosing Toolset for it’s potential without knowing much php pr javascript.

        So, yes… I’m sure all the users who are adapting toolset to make membership sites would love it if you, or someone, could create tutorials of using some of the snippets and more advanced actions such as cred_save_before_data.

        Another running support thread I had was with using cred_save_before_data to build star based review systems, writing to the database and performing review averaging maths upon submission of a CRED post form.

        So much is already built into Toolset, especially CRED’s actions already, but some more tutorials to really get the most of it, helping people with examples of these functions working, would be amazing.

        and yes….

        New features that abrogate the need for such workarounds would be equally awesome.

        Like I said though, I am really happy you’ve made this tutorial, and I look forward to more. The potential for toolset with Membership sites is awesome.

        Best

        Jeff

        • Hi again,

          However, these are quite tough to get your head around, and a lot of us users are (or were) novices, choosing Toolset for it’s potential without knowing much php pr javascript.

          You are making a good point here. On the other hand, as you say – providing some examples of these functions working would be great, especially when developing new features takes time. Anyway, we will keep your case in mind when planning new changes (both in development nad new tutorials) because you are not the first one bringing that up. Thanks for your comprehensive comment.

  5. I hope that in time this will challenge the likes of Chambermaster, WildApricot Weblink etc. There is huge potential for Toolset members to provide this platform. I have seen it done to some extent on one of your showcase sites here: http://www.albanydowntown.com/discover/

    So how did they achieve that please? Is it a custom post and then view? I also see that membership is done by a paper form here:

    http://www.albanydowntown.com/members/

    Could cred handle that? User registers and pays, then logs in and is sent to another cred form which includes business info, images, google map etc. The when the form is submitted and perhaps approved, the business name is then added to the directory view and when clicked displays the business view template?

    • Hi Al,
      thanks for your comment. To answer your questions, yes, CRED can handle that.
      User registers and pay -> CRED User Form + the CRED Commerce option
      User logs in -> Views Login Form, you can redirect your user to any page, including a page with another from, this time it would be a CRED Post Form.

      Note that you can also charge your users when adding new items to the directory.

  6. Hi Agnes

    Very happy that Toolset is getting serious about membership sites.

    I’m currently creating a training site based on Toolset. I also have WooCommerce and WooCommerce Membership installed, but I’d love to be able to ditch WC Memberships.

    It seems to me that Feature #1 (changing roles using CRED) is absolutely essential for creating proper membership sites where members can purchase multiple products (in my case, courses) that require varying access rights.

    Without that, I need to stick with WC Memberships.

    Almost as important is the need to be able to set access restrictions based on taxonomy values. This is a very nice feature of WC Memberships which I’d need in order to be able to use Toolset alone.

    I can’t use CPTs to set access restrictions because all courses use the same CPTs.

    And I can’t use Post Groups to set access restrictions, because an item of content can only belong to ONE Post Group, whereas I need an item of content to be part of multiple courses, and hence part of multiple “access restriction” sets.

    The most natural and convenient way of assigning access restrictions to content is therefore using taxonomy values.

    Other advantages of taxonomies is that:
    – You can apply the taxonomy to ANY item of content
    – Editing taxonomy values for a collection of posts can be done easily using Quick Edit, and also in Bulk Edit mode
    – Taxonomy values can be displayed as columns when listing posts in the admin area

    I guess you could implement this in either of two ways:

    EITHER:
    Change ACCESS, allowing a user to specify a Taxonomy (e.g. “Subject Matter”) and a value for that taxonomy (e.g. “Advanced WordPress”) and then state what roles are needed to read content with that taxonomy value…

    OR (and this is closer to how WC Membership works, and in my view much better)

    You start with a role, and then define one or more “access rules” for it to define what that role can read. For now, an access rule would be a taxonomy/value pair, although in future other types of rule could be included (such as tags or URL patterns and perhaps time restrictions).

    I’d love to be able to switch over to Toolset entirely, because I do have one problem with WC Memberships: it uses two CPTS (Membership Plans and Memberships), but they are defined as Private and I can’t access them in Views. That means I can’t create the sorts of member displays that I want (List of Courses a member has access to / list of courses they could purchase). I guess with Toolset I’d be creating the equivalents of those CPTs, and so could do anything I wanted!

    I hope these two features can be added soon.

    Alex

    • Hi Alex,
      you say

      Hi Alex,
      thank you very much for your thoughts and examples.

      I can’t use Post Groups to set access restrictions, because an item of content can only belong to ONE Post Group, whereas I need an item of content to be part of multiple courses, and hence part of multiple “access restriction” sets.

      Thanks for pointing out that limitation and sharing an example when it matters. Yes, restricting access on a category/taxonomy terms level would be great. Now, we are collecting feedback from users and, as mentioned in the blog post, we will implement the features that matter most. Now we need to know how many users vote for a specific feature to prioritize things.

      Alex, you say:

      I’d love to be able to switch over to Toolset entirely, because I do have one problem with WC Memberships: it uses two CPTS (Membership Plans and Memberships), but they are defined as Private and I can’t access them in Views.

      Did you try the post status filter (when you create a View)? You can select the private posts.

      • Thanks for the suggestion, Agnes, but it’s the definition of the CPTs themselves that are private, rather than the posts within the CPTs.

        Alex

  7. Hi Agnes,

    Thank you for the tutorial and this post. It helps me with creating a membership site. I am still in the conceptual phase.

    I am happy that we users of Toolset get the chance to vote. But if I read well then points 1 to 4 will be solved if the user roles can be changed automatically. I did not buy Woocommerce Subscription (yet). But I would be very happy if I would have enough with the Toolset tools. There is always the discussion wich plugin is to blame if something doesn’t work they way you would expect. So I vote for Feature #1. And I am looking forward to see the training membership site. When will it be expected?

  8. Feature Priorities
    Having now absorbed most of this new material, I can firmly say that #1, being able to change roles through CRED user forms, is definitely a priority.

    Given that I’ve had to purchase WooCommerce Subscriptions, for now #2 is a “nice to have”, but not a priority.

    I see #3 as being more just annoying, rather than a major limitation.

    I don’t have a current application for expiring posts created through a CRED form (#4).

    Re #5 – I definitely see this as an issue for some applications. However, the main use-case that I’ve come across tends to be tied to other functionality. See the next point below.

    Other lacking membership-related features
    The one big membership feature that I’ve found lacking is being able to (easily) implement a search that is based on posts that the logged-in user has flagged as a favourite. I realise that this means implementing a system of allowing a (member) user to add and remove posts from their own favourites list. However, it’s a feature that, in one form or another, is invariably required in membership sites.

    Yes, this could be as simple as the functionality that exists in the Support section of this site, with an AJAX link.

    However, I concede that this is most likely to fall farther down the request list for now and into the category below …

    Code Snippets
    I have to agree with jeff1 regarding the benefits of having some support snippets to fill in gaps and facilitate access to some of the advanced functions that are necessary to perform some tasks.

    One of the biggest challenges that I found when I started working with Toolset, was being able to readily confirm just what (incredible, versatile, fantastic) functionality, was possible through Toolset, and just when I had to choose between digging into code snippets, or go looking for third-party plugins.

    In this regard, I keep reading numerous support threads, identifying code snippets and seeking to understand why they are required (use case), what they are achieving, and how they are constructed. Beyond the support threads, I just watch and try to learn anywhere and from anyone.

    Ultimately though, I still find the support search function cumbersome for identifying relevant results for any search. However, I’ll save that gripe for elsewhere.

    Keep up the great work!

    🙂

    • Hi Stephen,
      great feedback, great summary. Thank you for explaining everything in such a clear way.

      I have a question about the “Favourite feature”. You say “implement a search”. Do you mean a search 1) available for the currently logged-in user to search his own favourites or 2) available for all other users/visitors?

      You say “implementing a system of allowing a (member) user to add and remove posts from their own favourites”. Have you considered using the parent-child relationship to implement that Favourite feature? I mean, the technique covered here. So, if you want a (custom) post to be flagged as a user’s favorite, a child post is added to that post with the user set as the post author. Then, you can list the user’s favorite posts by creating a View that lists all posts a currently logged-in user has flagged as favorites. For this, use the Post author is the same as the logged in user View filter in your View.

      I keep reading numerous support threads, identifying code snippets and seeking to understand why they are required (use case), what they are achieving, and how they are constructed.

      Great summary. We will keep that in mind when creating new tutorials (and adding thread summaries, where possible). Thanks a lot for you great feedback.

      • Hi Agnes,

        The “Favourite feature” is something that I see only being required for the logged-in user, to display their own favourites – much as is implemented in the support section of the Toolset site.

        However, I have recently extended this concept to displaying favourites for a (the) “group” that the logged-in user is a member. I implemented this (probably not very well), using a CPT.

        Yes, I saw the “Webinar” example, but only viewed in the context of adding a user to a child post, not the reverse (removing). It doesn’t strike me as being quite the same application. I may be wrong. :0)

        • You can remove posts via the front-end as well. Please see this tutorial. Please open the first picture and locate the Delete button and you will know what I mean. Think about ads from that screenshot as the user’s favourite posts. In your View, you would query the child posts instead and in the Loop output section you would display the parent post (just add the id with the $CPT). For each parent post in your output, you would add the CRED delete “form” which is actually a link that lets you delete the post being processed in your View loop directly from the front-end.

          • It looks like our posts crossed.

            Thanks, Agnes. I’ll review that tutorial and hopefully find what I’m looking for.

            :-))

        • Oh, and just to clarify – the “search” of the favourites is actually “using a filter in a View to display favourites that are specific to the logged in user”; not, a function to allow the logged in user to search within the Post Fields of the posts that they have “favourite-ed”.

          Again, just a simple AJAX link that a logged-in user (member) can select to add and remove posts from their list of favourites.

  9. 4… There is no easy way to automatically renew an expired post created with a CRED Post Form if you want to charge fees for doing so.

    Really I want to be able to charge for a renewal of an Ad (so am using a CRED Post Form). I would like to be able to renew easily, but it seems it can only be done from the front end and ONLY if you manage to update before the post expires.

    The other major issue is even if you do this then the Expiry date doesn’t recur for the same time period.

    For example, if the user updates the form then it pushes the expiry date on using the settings in the Post Form Expiration date section – i.e. NOT from the publish date per se, but from the amendment date.

    Example – I set the Edit CRED Post Form to be five days (for testing purposes).
    Original expiry date = 26th Oct

    Two days later I update the form on the front end (today’s date 23rd Oct).
    New expiry date = 28th Oct

    Three days later I updated the form on the front end (today’s date 26th Oct).
    New expiry date = 31st Oct

    As this is supposed to be a subscription, I would want to push the expiry date on, but for the same time period to start from the END of the current time period. Usually of course this would be an annual recurrence.

    • Hi there, thanks for sharing your case.

      You say “Two days later I update the form on the front end”. You mean you updated 1) the post content only because you needed to change some of its field values or 2) you updated it in order to renew it? If you update the post content (1), updating it on the front-end doesn’t change the initial expiry date (you need use a form with the “Set expiration date for post created or edited by this form” field unchecked). If you meant (2), you are right.

      Renewing a post after it expires (turns its status to “draft”) is also possible but we have the same issue here.

      With Views is it possible to display draft posts so if your Post expires, you could use a Post Form that changes an expired post to “Published” again and connect it with a WooCommerce product to charge the user.

      The problem is that setting the new expire date and checking if the related order has completed is not an “atomic” transaction. The expiry date is updated independently.

      So if a user for some reason doesn’t complete her/his order, her/his post will get a new expiry date anyway (even if the post is not published) but it shouldn’t. Is this the issue you had in mind?

    • Yes, I’m trying to do 2… Haven’t gone down the route of linking with WooCommerce – is this what I should be doing? Really just wanted a recurring date, that even if the post is updated before expiry that the date is renewed FROM the original expiry date for the same period set out in the form’s ‘Set expiration date for post created or edited by this form’.

      What’s happening in my case is that I allow users to update their ad’s, but this is adjusting the expiry dates (as outlined in my opening post’s example). The backend manager will not have a ‘stable’ date to work upon. It would be nice if expiry dates could just be managed from the backend, not adjusting every time a post is updated.

      I’m envisioning, client signs up for year contract. They are able to make updates to their ad throughout the year. If the client renews then their ad continues to display for another year – with the same recurring dates (just a year on – or whatever time period selected).

      I’m not sure how best to create a stable recurring time period? That I can charge for.

      • Do you have the “Set expiration date for post created or edited by this form” checked in your form for updating posts? If so, please uncheck it. This way, the edits done by your customers won’t affect the expiry date.

        If you want your customers to renew the post, create another form for it (you can copy the one you have if it makes sense and customize it). Check the “Set expiration date for post created or edited by this form” for this one.

        If a user wants to renew his/her post after it has already expired, they can still do so, just make sure that they can edit their own posts to access posts in the draft status.

        • Thanks for your help Agnes.

          Yes I do have the “Set expiration date for post created or edited by this form” on the Edit Cred Post Form.

          I understand to uncheck this – but what difference will a new form make. i.e. if the users update this new form from the front end it will adjust the expiry date in exactly the same way? Sorry if I’m missing the point.

          Maybe it’s worth looking at sending an email with a link to the Renew CRED Post Form based on the expiry date set on the initial *CREATE* Cred Post, that would work if sent on the day due for renewal… then I guess your final paragraph i.e. ‘If a user wants to renew his/her post after it has already expired, they can still do so, just make sure that they can edit their own posts to access posts in the draft status’ would apply. Does it have to be Draft – i.e. Pending Review wouldn’t work?

          I’ve noticed that if I ONLY update from the backend (which would be ideal) emails aren’t sent.

          Could you confirm I’m on the right track above. Many thanks.

          • Checking/unchecking the “Set expiration date for post created or edited by this form” on the Edit Post Form makes the difference. When this field is checked and the user updates the post through a form that has this field checked – the expiry date will be updated relative to the current date (today’s date). When this field is unchecked, nothing happens with the expiry date if the user updates the post on the front-end (through the form with this field unchecked).

            So if you want your users to edit any fields of that post but leave the expiry date unchanged, you need to uncheck the “Set expiration…” field. But then, you need another form for renewing the post. This other form doesn’t need to have your post fields for editing but needs to have the “Set expiration…” checked.

            I haven’t checked these forms in combination with the email notifications. But I will (to see if there are some issues).
            You don’t need to use the draft status, Pending Review should work the same way.

            • Hi Agnes, thanks for your continued help. Just trying to understand the process at the moment.

              Totally understand paragraph one.

              Second paragraph that refers to the new form…

              But then, you need another form for renewing the post. This other form doesn’t need to have your post fields for editing but needs to have the “Set expiration…” checked.

              If I set this new EDIT CRED Post Form “Set expiration… ” checked then and don’t have any fields available, except an update button, won’t this still amend the expiration date when used? That’s what I don’t understand…

              How would clients be able to see this update form? I guess I’d add a link to an email using an email on the CREATE form on the day of expiry?

              Thank you.

            • For example, you can include both links in your Content Template – please see an example.

              I will check if you can display the “Renew link” conditionally, meaning if you can use the {{cred-post-expiration}} shortcode in a Views condition. If so, you could display that additional link a few days before the ad expires or after it has already expired.

            • Yes, you can use the cred-post-expiration shortcode (which displays the expiry date) in conditional statements along with Views date functions such as TODAY, FUTURE_DAY etc. So you can show this Renew ad link only a few days before the post expires.

              Just remember to convert the date to Unix format (use U, see my example) since our Views date functions operate on that format.

              Pasting the code won’t work in comments so please see my screenshot instead.

          • Thank you Agnes for your continued support. I have tried setting up conditionals using the FUTURE_DAY(4) and PAST_DAY(4), but it doesn’t work when I only want to display the RENEW button for a short period of time – i.e. if the date of expiry is within 4 days of today’s date. The reason for this is if I leave the window larger then we are back to the issue of the CRED form updating the expiry date and subscriptions becoming out of sync. Is there an easy way to do a calculation on a date or am I looking at custom shortcodes?

            • I may have found a solution.

              In Settings > Front-end Content I set _cred_post_expiration_time to show in the Views GUI.

              Then in the View itself I set a Query Filter, selected ‘Expiration Date’ from Custom fields. I then set the options…
              The field _cred_post_expiration_time is a number that is between the following: PAST_DAY 4 \ FUTURE_DAY 4.

              This appears to work, but will do some more testing.

  10. Hi,

    I tried CRED Commerce 1.1 and WooCommerce Subscriptions in August and they didn’t work together. Reason being, both CRED and WooCommerce Subscriptions try to create the user account. I raised this on the Toolset forum and was told it would be looked into. Has this been resolved, cause I can’t see anything in the changelog?

    Thanks,
    Richard

    • Hi Richard,

      both CRED and WooCommerce Subscriptions try to create the user account

      That’s correct but you need to disable creating users in WooCommerce settings.

      I will update your thread with details.
      The answer is yes, you can use CRED Commerce and WooCommerce Subscriptions together.

      • Thanks for the prompt response.

        From my tests not checking/unchecking WooCommerce > Checkout > Enable guest checkout makes no difference to WooCommerce Subscriptions, so I look forward to seeing how you manged to disable creating users in WooCommerce (Subscriptions).

        rt.

        • Richard, did you have your setting set as on that screenshot?
          https://d7j863fr5jhrr.cloudfront.net/wp-content/uploads/2016/02/cred-commerce-setting-registration-options-in-woocommerce-settings.png

          In your original support thread, you mention that you unchecked the Account Creation options while you should have checked them. Checking these fields will prevent displaying the errors you had but since CRED takes the control and creates the user, the user won’t be added twice.

          • Agnes,

            Apologies for the delay in responding.

            Adopting your settings (in the above screenshot) did get the user creation working – so, thank you.

            However, I have two new issues:
            1. By using your settings, WooCommerce wipes out any username and password information that I capture from the user on the Toolset user form. Do you know any way round this?
            2. Also other values entered on the user form do not seem to be saved. For example, I have a generic field capturing Activities and the values are not being saved. Note it is not a problem with my field, because it works when using the same form but without WooCommerce. Again, do you know any way round this, e.g. is there a coding solution?

            I look forward to hearing from you again soon.

            Thanks,
            Richard

            • Hi Richard,
              1. You mean, you would like the user data entered in the User Form created with the CRED to be moved to your WooCommerce form so the user doesn’t need to enter the same data twice? If so, this is the #3 issue I listed in the post above. We don’t have any workaround for it.
              2. You say “have a generic field capturing Activities”. So this field wasn’t added with our Types plugin but as a generic field, right? If so, generic fields are not saved in the database. Please add User Fields instead (Toolset->User Fields). Or please wait, now I read “Note it is not a problem with my field, because it works when using the same form but without WooCommerce.” you say it works fine when used without WooCommerce. Please register a ticket in our support forum or let me know the how you created this field and I will try to replicate it.

  11. Hi Agnes,

    Thank you for the very prompt response.

    I guess in effect they are the same issue, in that both my points are about saving the data entered on the User Form against the user, when using WooCommerce to take a payment. I guess if you cannot do that – please clarify – then that is why my Activities field doesn’t save either.

    Out of interest, can saving data against a user not be achieved through code – I am a rusty developer – or is the issue that there is no user object to save against?

    rt.

    • Thanks. I will try to replicate it and if the data are not saving indeed only on the case when the user form is used with WooCommerce we have a bug.
      Please confirm the steps:
      1. Add a user field (in Types)
      2. Create a User Form (CRED) that includes that field
      3. Connect this form with WooCommerce payment
      4. Create a page with that form
      5. Submit the form, filling out the user field you created in #1.
      6. Fill out the WooCommerce form.
      7. Mark the WooCommerce order as completed.
      The field created in #1 doesn’t save but should.

      Is this what you mean Richard?

      • Agnes,

        Yes, those are essentially the steps I followed.

        I was using Generic Fields, because Types does not support mulit-select User Fields – see my thread: https://toolset.com/forums/topic/multiselect-user-fields-2/.
        Anyway, so I tried with a Types User field.

        So I now have the following on my form – see https://snag.gy/dH0BqD.jpg:
        Nationality (wpcf-nationality) – a Types User Field of type Radio
        Top Activates (top_activities) – a Types Generic Field of type Multi-select
        Sex (sex) – a Types Generic Field of type Radio

        My ultimate aim is to display the values submitted on the form on a Ultimate Member profile.

        Here is what I discovered. When using my User Form and WooCommerce, Nationality is stored – I can see it using a plugin the displays usermeta. However it, does not display on the Ultimate Member profile. Top Activities and Sex are not stored at all. Now, when I use THE SAME FORM without WooCommerce, I get different results. I still get the same result for Nationality, but this time Top Activities and Sex are both viewable via the usermeta – https://snag.gy/lEkyK7.jpg – AND the Ultimate Member profile – see https://snag.gy/dA5e7B.jpg.

        I am happy to give you admin access to my site or maybe you can try and recreate the issue. I look forward to hearing from you again soon.

        Thanks,
        Richard

        • Hi Agnes,

          Any thoughts?

          Let me know if you want to move this discussion to the support forums.

          Thanks,
          Richard

          • Hi Richard,
            yes, it would be good to move it to our support forum. Please register a ticket and you can just copy paste what you posted here. Thanks Richard.

            • Hi Agnes,

              I have opened a new support ticket – https://toolset.com/forums/topic/field-values-not-being-saved-cred-user-forms-and-cred-commerce/.

              The guys are trying to help me, but I was wondering if you could also contribute or at least confirm whether or not you have managed to get a User Form using Generic Fields + CRED + CRED Commerce + WooCommerce + WooCommerce Subscriptions to work – the key point is Generic Fields (please see the thread for the reason why).

              If I can’t get this to work, I will have to give up on Toolset. If I do have to do so, it would be good to at least understand why Generic Fields are supported on User Forms when used with CRED but not when used with CRED Commerce.

              Thanks,
              Richard

            • Hi Richard, thank you for raising the issue in our support forum.
              If Generic Fields work fine when used on User Forms and stop working when used in CRED Commerce it’s a bug and it needs to be fixed.

              I will make a quick test and will let you know.

            • Hi Richard,
              I made a quick test and use generic fields in a User Form (first, without WooCommerce CRED). The generic fields didn’t save (even if I used the
              “persist”:1). So I contacted our developers and they say we no longer save generic fields. You can only use them in conditions to test/check a value, upon submitting the form (if you use hooks and PHP).

              If you need to store additional values for user profiles, please use User Fields.

            • Where do your generic fields appear? In your user profiles? I mean WordPress profiles? I cannot figure that out by looking at your second screenshot.

            • My generic field values are stored in the database – https://snag.gy/F0hnQa.jpg – and displaying via an Ultimate Member profile – https://snag.gy/dA5e7B.jpg.

              And here is my code:

              [creduserform class='cred-user-form cred-keep-original']

              [cred_field field='form_messages' value='']

              First Name
              [cred_field field='first_name' post='user' value='' urlparam='']

              Last Name
              [cred_field field='last_name' post='user' value='' urlparam='']

              Nationality
              [cred_field field='nationality' post='user' value='' urlparam='']

              Gender
              [cred_generic_field field='sex' type='radio' class='' urlparam='']
              {
              "required":0,
              "validate_format":0,
              "persist":1,
              "default":[],
              "options":[
              {"value":"male","label":"Male"},
              {"value":"female","label":"Female"}
              ]
              }
              [/cred_generic_field]

              Top Activities
              [cred_generic_field field='top_activities' type='multiselect' class='' urlparam='']
              {
              "required":0,
              "validate_format":0,
              "persist":1,
              "default":[],
              "options":[
              {"value":"managing","label":"managing"},
              {"value":"analysing","label":"analysing"},
              {"value":"writing","label":"writing"}
              ]
              }
              [/cred_generic_field]

              Email
              [cred_field field='user_email' post='user' value='' urlparam='']

              Password
              [cred_field field='user_pass' post='user' value='' urlparam='']

              Repeat Password
              [cred_field field='user_pass2' post='user' value='' urlparam='']

              [cred_field field='form_submit' value='Pay' urlparam='']

              [/creduserform]

            • Thanks Richard,
              ok, I discussed the issue with our supporters and here’s the official note about generic fields:
              1. Our CRED GUI no longer supports adding generic fields that are going to be persistent (saved in the database). Doesn’t matter if you use generic fields in User Forms or in Post Forms.
              2. However, to maintain backward compatibility that “persist:1” attribute is still supported when used manually.
              3. When you use generic fields in Post Forms with the persist:1 attribute you will see them in your posts (as custom fields)
              4. When you use generic fields in User Forms with the persist:1 attribute you won’t see them anywhere (anywhere in the user profile where you would see User Fields created with Types) but they are saved in the database and can be accessed by your custom PHP code or in your custom shortcodes.

              Now, if using CRED Commerce or WooCommerce violates this expected behavior in any way, this is a bug that needs to be fixed. I would follow our supporter’s advice (from the ticket you shared with me) and shared the credentials to your site so he can test it.

  13. Agnes,

    I have done as Luo suggested and the issue persists. NB it is not just generic fields. My user field is not saving either.

    rt.

    • I can see Luo will debug your issue. Did you provide him with the credentials so he can proceed with debugging?

          • Agnes,

            Lou came back to me overnight, but it has not solved the issue.

            I’d really appreciate it if you could put some focus on this. I have been trying for months to get Toolset + CRED + CRED Commerce + WooCommerce + WooCommerce Subscriptions to work, and I’d really like to know before the weekend if it is going to happen – else I think I will have to give up.

            Thanks,
            rt.

            • Hi Richard, I read Luo’s comment and I can see he didn’t manage to reproduce the issue but from your additional note I can see that you would like him to test it for a user with a different role. Let’s wait for this final test, ok? I will also ping Luo.

            • If I am correct about how he did his test – as an admin – it not valid.

              At the moment we are averaging one response a day and the weekend is round the corner. Anyway, let’s see.

              Thanks for agreeing to ping him.

            • Agnes,

              Is there anyone other than Luo that could look into the issue? I’m afraid I don’t think he gets it and I am not impressed with his testing. If not, I think it is time for me to give up on Toolset.

              rt.

            • Hi Richard,
              I’ve just talked to Luo. Luo will debug it again keeping the Toolset-WooCommerce Subscription compatibility in mind and if there is an incompatibility issue indeed if there is a quick way to fix it.