[Resolved] Best Toolset / WooCommerce Subscription combination

[Author]

Posts

[caroleM-4]

Hello,

The WPML / custom code website I am actually migrating to Toolset / WooCommerce Subscription (and still WPML of course) is meant to allow subscribed users to post ads of a certain kind and registered users with no subscription another kind of ads.

Before the migration the website was using a CPT for user profiles and we would like to continue having these as many users are already registered and our customer is used to find all their data on their profile posts. Many of the fields of these profile posts are identical to WooCommerce address fields but not all of them and we also have a few more that are not related to addressing.

I am actually trying to find the best deal for user registration, login and profile edition knowing that, ideally, I would like to :
- Create the profile post and populate its metadata on registration in order to force user complete their profile from the start no matter if they will be free users or subscribers
- Also populate WooCommerce billing address fields on registration with the same value as those from the profile identical fields to avoid users being forced to fill them twice.
- Update all data when an administrator edit a user from the backend as well as when the user itself updates his data using a frontend form
- If possible avoid the manual creation of a select country field in Toolset as WooCommerce already has one which is working perfectly and both would not be syncing.
- Use the same login form for WooCommerce account pages and other pages with a restricted access like for example, list of own contents, edit forms, etc.
- Have a common set of pages for managing WooCommerce account functionalities and other registered user only data / functionalities (list of own ad posts, posts / profile edit forms, etc.)

I guess available options to reach these goals are :
- Use cred user forms for registration / login / profile edition and form / field / views API to manage the WooCommerce part of the thing
- Use WooCommerce registration / login / profile edition functionalities and WooCommerce API to manage the CPT part of the thing
- Use a magic combination of all those methods to get the best of both worlds while keeping things stable and safe

I know there still will be limitations I'll have to find workaround for whatever I choose in the end but I am pretty sure there will be less if I can follow the correct path from the start and that would be a very good thing as I already bumped on many walls since I started working on this project.

Unfortunately, it's the first time I use Toolset in such a context and I am missing the needed experience to spot the points on which things may get really complicated so I can't figure out which options would be the best for me.

What would you recommend on your side based on your technical knowing of Toolset and your experience of the common issues / limitations encountered when building similar websites ?

Thanks in advance for your help and have a nice day.

[Waqar]

Hi,

Thank you for contacting us and I'd be happy to assist.

You're thinking on the right lines and maintaining a "User Profile" through a CPT, in parallel with the WordPress user profile is something we also recommend for directory websites where custom search needs to be performed on user profiles or where other CPTs need to be linked to "User Profiles".
( this is because in Toolset relationships can be created only between two post types and not between WordPress users and post types )

We have a detailed guide on the topic at:
https://toolset.com/course-lesson/how-to-create-custom-searches-and-relationships-for-users/

In summary, every user will be maintaining two types of profiles on the website:
a). Account Profile
This will be the actual WordPress user profile, which will include the account-related information like username, password, email and WooCommerce fields, etc.

b). User Profile
This will be your CPT, and you'll need to make sure that every registered user has exactly one post in this CPT, where he/she is the post author.

Any additional fields, which are not available in "Account Profile" ( i.e. WordPress user profile or in WooCommerce ), can be part of this CPT.

Note: I'd avoid storing the same field data in both these profiles, as it will be challenging to keep the data in sync between the two profiles.

I hope this helps and please let me know if you need any further assistance around this.

regards,
Waqar

[caroleM-4]

Well, I could of course migrate addressing data of already registered user profile posts to WooCommerce billing fields and just display the address in a metabox to fulfill our customer's needs when checking profiles, that's not really a big deal and you're right to say that it could ease their management.

As for the main purpose of this ticket which was more to determine if it would be more efficient to use cred forms for registration / profile edition or to let WooCommerce handle that, I realized while thinking about whether I should or not migrate addressing data that the answer was rather simple to find as WooCommerce does not collect billing address on registration which I need to do.

This means I will use cred forms at least for registration this no matter where I decide to store the data as the only advantage I was seeing in letting WooCommerce handle the registration was to rely on built-in functionalities.

Just one more question before closing the ticket, I have seen that it's possible to populate options of cred forms generic select fields via a shortcode, which would be useful for the country field, but did not find anything similar in the options proposed when adding a select field using "Manage non-Toolset User Fields with Toolset Forms". Is there a reason for that ?

[Waqar]

Thanks for writing back.

The management of non-Toolset fields and the generic fields in the form are not related.

The option to manage non-Toolset fields allows the custom fields which are not added through Toolset Types to be available in Toolset's Forms interface. The values of these custom fields are stored in the database.

The generic fields in forms, are virtual fields, meaning their values are not actually saved in the database. They are useful when you need to collect some input/response from the user, but don't have to store that input/response, as it is. That input/response from the user can be used in the custom function attached to the form submission, to do some other processing.

For example, in this reply, I've shared the steps on how a generic field can be used to populate select field options from a post type, and then the selected post can be programmatically linked in a relationship:
https://toolset.com/forums/topic/split-publishing-related-many-to-many-posts/page/2/#post-1217880

[caroleM-4]

Thanks for the feedback Waqar.

I understand the difference between both things, what I do not understand is the difference between the available options to populate select fields.

My first idea was to use The "Manage non-Toolset User Fields with Toolset Forms" to include WooCommerce country field and let the form save the value for me but, doing it this way, I can't populate the options another way than manually which is not really the best choice in that case.

I guess I'll end up using a generic field to be able to populate options via a shortcode and then save it manually which is not really a problem but is a little frustrating in such a context. So I wondered if there was a technical reason for the "Populate option via a shortcode" to be available only for generic field or if it may be a reasonable feature request to have it added to non-toolset fields managed with Toolset Forms.

[caroleM-4]

Well, I am actually testing the generic field "Get options from a shortcode" functionality but can't get it working correctly so maybe you can forget my last question until this is resolved 😉

The goal in my case is to populate it with WooCommerce countries so I tried using the following shortcode :

function populate_country_field(){
  global $woocommerce;
  $countries_obj   = new WC_Countries();
  $countries   = $countries_obj->__get('countries');
  
  foreach ($countries as $value => $label ) {
    $options[] = array('value' => $value, 'label' => $label );    
  }
  return(json_encode($options));
}
add_shortcode( 'woocommerce-countries', 'populate_country_field' );

The output seems correct but the field has no option but the placeholder one so I tried with a simpler example to see if the result was better :

function populate_countries(){
  $options[] = array('value' => 'CH', 'label' => 'Switzerland' ); 
  $options[] = array('value' => 'FR', 'label' => 'France' );
  $options[] = array('value' => 'DE', 'label' => 'Germany' );
  return(json_encode($options));
}
add_shortcode( 'custom-countries', 'populate_countries' );

As it was still not working and I could not understand why, I tried doing the same on a testing website on which only Toolset and WPML are installed but the result is the same as you can see on hidden link, this even though the output seems correct if I simply add the shorcode to a page which I did on hidden link.

Could you please help me understand what's going wrong ?

[Waqar]

Thanks for the update.

During troubleshooting, I noticed that if the form is being edited in the visual mode ( example screenshot: hidden link ), the extra opening and closing square brackets around the shortcode output, make the format unrecognizable and the field's options are not populated.

In that case, you can strip those opening and closing brackets from the shortcode's output, by updating the return line to:

return substr(json_encode($options), 1, -1);

That code worked in the other ticket because there the generic field was being added using the text/expert mode.

Note: Toolset has limited control over the non-Toolset fields, but for fields added through Toolset Types, you can use the "wpt_field_options" filter, to programmatically, generate the field options:
https://toolset.com/documentation/programmer-reference/types-api-filters/#wpt_field_options

[caroleM-4]

Thanks a lot, removing the square bracket did solve the problem.

As for using the "wpt_field_options" filter, would it be possible then to combine it with "cred_filter_field_before_add_to_form" to directly use the WooCommerce country field managed by Types and have it automatically saved while still displaying it in the form as a select field and populate its options automatically ?

[Waqar]

Thanks for the update and glad that it worked.

The "wpt_field_options" filter can be used to populate the options for the select and radio fields added through Toolset Types. It can't be used for the WooCommerce fields.

You're welcome to mark this ticket as resolved and start a new ticket for each new question or concern.

[caroleM-4]

Thanks for the feedback Waqar, I'll stay with the generic field / shortcode solution which fits my needs.

Have a nice day.