Skip Navigation

[Resolved] Adding Several Custom Fields

This support ticket is created 4 years, 3 months ago. There's a good chance that you are reading advice that it now obsolete.

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.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

Author
Posts
#1433153

Hello,

We have purchased Toolset, setup a custom post type, created custom fields for that post type and setup forms to use those custom fields. We now wish to add several (about 4000) custom field type checkbox options that display based on conditionals set.

Our goal is to have 4 checkboxes fields:
1. Specialty (A user would check their main specialty, then a checkbox list of related subspecialties would appear)
2. Subspecialty (Depending what specialty was checked, a checkbox list of related subspecialties would show)
3. Conditions treated (Depending on what subspecialty was checked, a checkbox list of related conditions would show)
4. Treatments performed (Depending on what subspecialty was checked, a checkbox list of related treatments would show)

Since we have several (about 4000 in total) of specialty, subspecialty, conditions and treatments checkbox options - is there a way to add these fields in bulk via import/export/CSV, rather than manually adding them one-by-one in the dashboard?

Thank you in advance for your help with this matter!

#1434323

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi Nick,

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

When a large number of options are involved, which also need to be connected or dependant on each other, it is better to use custom post types instead of custom fields. That is because, unlike custom fields, custom posts can be connected with each other through post relationships:
https://toolset.com/documentation/post-relationships/

In summary, you can use these post types to store this data:

1. Post Type "User Profile":
The main post type that will link each registered user on the website, with other post types. We'll need this, as a post relationship can only be created between two post types and not directly between a post type and a user.

Here is a useful guide on this topic:
https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/

2. Post Type "Specialty":
As one user can have only one "Specialty", you can create a one-to-many relationship between "Specialty" and "User Profile" post types.

3. Post Type "Subspecialty":
As one specialty can have many subspecialties, you'll create a one-to-many relationship between "Specialty" and "Subspecialty" post types.

4. Post Type "Conditions":
As one subspecialty can have many conditions, you'll create a one-to-many relationship between "Subspecialty" and "Conditions" post types.

5. Post Type "Treatments":
As one subspecialty can have many treatments, you'll create a one-to-many relationship between "Subspecialty" and "Treatments" post types.

Once this data structure has been deployed, the bulk import through CSV file(s) will also become more streamlined, as explained at:
https://toolset.com/documentation/user-guides/export-import/how-to-import-content-into-wordpress-using-csv/

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

regards and a Happy New Year
Waqar

#1436555
Screen-Shot_3.png
Screen-Shot_2.png
Screen-Shot_1.png

Thank you for your reply!

Please allow me to explain what we are building so we know if we are asking the best questions

We are building a membership site for doctors (hidden link). We want the doctors to have the ability to edit their public profile from a private page. A basic version of that is working now. An important part of the doctor's profile is a list of the treatments they perform and the conditions they treat.

Screen-shot_1.png

Doctors all have a specialty and many specialties, but not all of them, have a subspecialty. Each subspecialty has different treatments and conditions. And even multiple doctors who have the same subspecialty will not treat all of the same conditions or offer all of the same treatments.

Screen-shot_2.png

Doctor 1 does not offer ALIF or Discography treatments. Doctor 2 does not offer Discography and does not treat the condition ASD. Doctor 3 is also different.

NOTE: the red lines are just for the mockup and will not be on the site. Instead they will simply not show up at all if they are not selected.

There are hundreds of specialties and subspecialties, and thousands of different medical conditions and treatments. We have them all organized in Excel.

Screen-shot_3.png

What we want to add to our current profile form is the conditional logic so if, for example, a doctor selects "Anesthesiologist" as their specialty then the 5 Anesthesiologist subspecialties become options they can select, and if they select the Pain Medicine subspecialty then the appropriate Pain Medicine Treatments and Pain Medicine Conditions will appear so they can select which ones they want on their profile.

If all of that makes sense then (1) how should we build it and (2) is there a way to import these thousands of treatments and conditions?

#1438131

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Thanks for writing back and for sharing further details.

The new detail, that each doctor should have the choice to selectively pick from the connected subspecialties, treatments, and conditions, complicates this a little.

In summary, this means:
a). The involved data items (specialties, subspecialties, treatments, and conditions) will need to be grouped together, but
b). It is not necessary that all items from a group are selected.

If my understanding is correct, you can structure the data items and relationships like this:

1. Post Types:

a). Doctor Profiles
b). Specialties
c). Subspecialties
d). Conditions
e). Treatments

2. Post relationships:

a) Specialties -> Subspecialties
A one-to-many post relationship

b). Subspecialties <-> Conditions
A many-to-many post relationship

c). Subspecialties <-> Treatments
A many-to-many post relationship

Note: the above relationships are needed for grouping the data items.

d). Specialties -> Doctor Profiles
A one-to-many post relationship

e). Subspecialties -> Doctor Profiles
A one-to-many post relationship

f). Conditions <-> Doctor Profiles
A many-to-many post relationship

g). Treatments <-> Doctor Profiles
A many-to-many post relationship

Note: these post relationship actually represent the actual connection/link between these data items and a doctor.

3. To allow a doctor to select these options on the front-end while editing his/her profile, you'll need some workaround and multiple forms (on the same or different pages), since this is something that is not supported out-of-the-box.

In summary, the first edit form will show the available "Specialties". Once a specialty has been selected and form is submitted, the second form will start to show "Subspecialties" options, only related to the selected "Specialties".

After the second form is submitted, the third and final form will start showing all "Conditions" and "Treatments" which are related to the selected "Subspecialties". Once all these forms have been submitted, the selected items will be connected to that logged-in doctor's profiles.

Please let me know if this structure and approach would work for you and we can then move on to specific details around how to deploy these forms.

regards,
Waqar

#1438461

Brilliant! How do we get started?

Nick

#1442563

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

Hi Nick

Waqar has a day off today. As he is already quite a way down the road of working on this issue with you, I'll leave it for him to update you when he returns tomorrow.

Thanks for your patience.

#1442627

We tried Meta Box before we discovered Toolset and one of the reasons we are happy with the switch is the excellent support. Thank you for taking a moment to update us when your colleague is away

#1443849

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi Nick,

Thank you for waiting and for your kind words.

If you haven't already, I'll recommend starting with deploying the custom post types and the relationships between them, as suggested in my last reply.
( ref: https://toolset.com/forums/topic/adding-several-custom-fields/#post-1438131 )

Once they're ready, you're welcome to share temporary admin login details for your website, so that I can log in and suggest the next steps.

I'm setting your next reply as private and please make a complete backup copy of the website before sharing the access details.

regards,
Waqar

#1446781

Port 22 for SFTP

#1448607

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi Nick,

Thank you for sharing the admin access.

A). Frontend forms:

The first step moving towards the front-end forms would be to create a "new post form" to add a "Doctor Profiles" post for each user/doctor who registers on the website.

As explained earlier, you'll need exactly one "Doctor Profile" post for each doctor/user who registers on the website, because posts can't be connected to the users directly and so a post type will be used to connect with other post types.

The steps for this are explained in detail in this guide:
https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/

In summary, this would be the flow:

1. A user/doctor comes to your website to register through a front-end user form.
2. After logging in, he/she will be presented with a form to add a new doctor profile, if one doesn't exist already.
( ref: https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/#how-do-i-prevent-users-from-creating-more-than-one-contractor-post )
3. Once that user's doctor profile has been created, you can show the subsequent forms to pick items like Specialties, "Subspecialties", "Conditions" and "Treatments".

B). Data Import:

Now that the post types and the relationships for "Specialties", "Subspecialties", "Conditions" and "Treatments" are set up, you can start importing the data in them.

Have you tried the import steps from the guide that I shared with you earlier?
https://toolset.com/documentation/user-guides/export-import/how-to-import-content-into-wordpress-using-csv/

Please let me know if you face any challenge in following those steps and then we'll move forward to the next phase.

regards,
Waqar

#1449397

Hi Waqar,

We have all of the specialty, subspecialty, conditions, and treatments imported into the site underneath their appropriate custom post type. Here are links to their archives:

hidden link
hidden link
hidden link
hidden link

How do we make the custom forms for the provider to select their specialty, etc using checkboxes (and setting up conditionals to display certain things); which will in turn update their profile?

hidden link

Regards,
Nick

#1455349

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi Nick,

Thank you for waiting.

I'm currently working on the steps of how these forms will need to be set up on my test website will share them in detail as soon as they are ready ( ideally by the end of the day today ).

regards,
Waqar

#1456227

Thank you, Waqar!

#1457987

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi Nick,

Thank you for waiting, while I deployed the forms with the discussed requirement on my test website.

I'm going to break down the steps in multiple logical parts so that they can be easier to follow:

1. First, we'll need a main container or a wrapper for these forms, which can hold them in the scope of a current "Provider"
( which is linked to the currently logged-in user )

You can create a post view and name it something like "View to show current provider's form".

In this view's settings, you'll select "Providers" in the content selection and include a post author "Query Filter" to show only those posts where the author is the same as the currently logged-in user.
( and this should always return only 1 "Providers" post )

Screenshot: hidden link

In that view's "Loop Wizard" you can select the "Unformatted" display layout and in the content template for this view's loop item, you can include heading for the first form "Select Speciality:".

2. Since the first step is to select a "Specialty", you can create a post form named "Form to edit a provider - select specialty".

In the form's settings, you can set it to edit existing "Providers" posts, and keep the original status of the form, while keep showing the form after the submission.

Screenshot: hidden link

In the fields section, you'll only need to include the "Specialties Providers" field, and you can set its label to something like "Select Specialty".

Screenshot: hidden link

3. Once this form is ready, you can place its shortcode in the view created in step 1, below the heading "Select Speciality:".


[cred_form form='form-to-edit-a-provider-select-specialty' post='[wpv-post-id]']

Note: how the current provider post's ID is passed in the post "attribute" to tell the form, which post to use for editing.
( ref: https://toolset.com/documentation/user-guides/front-end-forms/cred-shortcodes/#cred_form )

Screenshot: hidden link

As a result, the first form to select a specialty is ready.

When you'll insert this view from step 1 on a test page, you'll see a form with a list of specialties to choose from and a submit button.

Screenshot: hidden link

Once a provider will select a specialty from the list and submit the form, it will be connected with his/her provider post.

4. The next step would be to create a form to select a "subspecialty" but with only the options linked to the selected "specialty".

You'll create a new post form and can name it something like "Form to edit a provider - select subspecialty".

In this form's settings too, you'll set it to edit a "Providers" post, while keep showing the form and keep the same status for the post.

Screenshot: hidden link

Since only one "subspecialty" can be selected for a provider, you can include "Radio" type generic field in this form and make it a required field.

For the slug of this field, you can add "select-subspecialty" and for a source of options, you can set it to get options from a custom shortcode "[show_output_subspecialties_options]".
( explained in the next step )

Screenshot: hidden link

5. One great benefit of generic fields ( ref: https://toolset.com/documentation/user-guides/front-end-forms/inserting-generic-fields-into-forms/ ) is that we can dynamically populate their options, using views. The expected format for this is a valid JSON object, which can be easily achieved using views.

Example:


{"value": "value1", "label": "Label 1"}, {"value": "value2", "label": "Label 2"}....

You can create a new post view and name it something like "View to show Subspecialties options related to a Specialties".

In the content selection settings, you'll select "Subspecialties" post type and in the "Query Filter" section, you'll include a post-relationship filter to only get those posts which are related to a post whose ID is passed through a shortcode attribute "wpvrelatedto", in "Specialties Subspecialties" relationship.

Screenshot: hidden link

In the "Loop Wizard", you'll need to select "List with separators" option and you can structure the final content in the "Loop Editor" section like this:


[wpv-layout-start]
	[wpv-items-found]
	<!-- wpv-loop-start -->
		<wpv-loop>
			[wpv-item index=other]
				{"value": "[wpv-post-id]", "label": "[wpv-post-title]"},
			[wpv-item index=last]
				{"value": "[wpv-post-id]", "label": "[wpv-post-title]"}
		</wpv-loop>
	<!-- wpv-loop-end -->
	[/wpv-items-found]
	[wpv-no-items-found]{"value": "", "label": "No items found"}[/wpv-no-items-found]
[wpv-layout-end]

Please note how post IDs are used as the values for the options and post titles are used as the labels.

6. The next step would be to register a new custom shortcode "[show_output_subspecialties_options]" which was used in step 4.
( ref: https://toolset.com/documentation/adding-custom-code/how-to-create-a-custom-shortcode/ )


// shortcode to create a list of subspecialties options
add_shortcode( 'show_output_subspecialties_options', 'show_output_subspecialties_options_func');
function show_output_subspecialties_options_func() {
	// get the ID of the parent specialty
	$parent_id = do_shortcode("[wpv-post-id item='@specialty-provider.parent']");
	// output of the view to show subspecialties related to a specialty
	$view_output = do_shortcode('[wpv-view name="view-to-show-subspecialties-options-related-to-a-specialties" wpvrelatedto="'.$parent_id.'"]');
	// return the output
	return $view_output;
}

The above code snippet can be included through either Toolset's custom code feature ( ref: https://toolset.com/documentation/adding-custom-code/using-toolset-to-add-custom-code/ ) or through active theme's "functions.php" file.

It basically gets the ID of connected specialty with the current provider and passes it as a shortcode attribute "wpvrelatedto" in the shortcode of the view from step 5 and then returns the output.
( ref: https://toolset.com/documentation/user-guides/views/passing-arguments-to-views/ )

7. Now that this second form is visually ready, it can be inserted below the first one in the view from step 1.

However, if you'd like it to show only once, a specialty has been selected through the first form, it will need to be wrapped within a conditional block.
( ref: https://toolset.com/documentation/user-guides/conditional-html-output-in-views/ )

It possible to get the ID of a specialty connected to the current provider in the view, using the "item" attribute:
( ref: https://toolset.com/documentation/user-guides/views/views-shortcodes/item-attribute/ )


[wpv-post-id item='@specialty-provider.parent']

This shortcode can be used in a conditional block so that the inner content (in this case the second edit form) is only shown if a post ID of a connected specialty exists.


[wpv-conditional if="( '[wpv-post-id item='@specialty-provider.parent']' ne '' )"] 
<strong>Form to Select Subspecialty:</strong>
[cred_form form='form-to-edit-a-provider-select-subspecialty' post='[wpv-post-id]']
[/wpv-conditional]

Screenshot: hidden link

As a result, the second form will start showing below the first one, once a specialty has been selected.

Screenshot: hidden link

8. At this point, the options for the subspecialties will be available, but they'll not be linked to the current provider when this second form will be submitted.

To make this connection on form's submission, we'll need a custom function attached to "cred_save_data" hook:
https://toolset.com/documentation/programmer-reference/cred-api/#cred_save_data


// function to process subspecialty relationships with providers
add_action('cred_save_data', 'subspecialty_processing_action',10,2);
function subspecialty_processing_action($post_id, $form_data)
{
	// if a specific form
	if ($form_data['id']==1234)
	{
		// delete the existing connection between provider and subspecialty
			// get existing connection
			$existing_connections = toolset_get_related_posts($post_id,'subspecialty-provider','child');
			if(!empty($existing_connections)) {
				// delete the found connection
				toolset_disconnect_posts( 'subspecialty-provider', $existing_connections[0], $post_id );       
			}

		// if any option for a subspecialty is selected connect it to the provider
			// if any option for a subspecialty is selected
			if(!empty($_POST['select-subspecialty'])) {
				// connect the selected subspecialty with the provider
				toolset_connect_posts( 'subspecialty-provider', $_POST['select-subspecialty'], $post_id );
			}	
	}
}

The above code snippet can be included through either Toolset's custom code feature ( ref: https://toolset.com/documentation/adding-custom-code/using-toolset-to-add-custom-code/ ) or through active theme's "functions.php" file.

Please replace "1234" with the actual ID of the second form and "subspecialty-provider" and "select-subspecialty" with the actual slugs of your post relationship and the generic field used in the second form, respectively.

When the form will submit, this function will remove any existing relationship between the current provider and any subspecialty and will connect the newly selected subspecialty instead.

You can learn more about the "Post Relationships API" functions used in this snippet from this reference guide:
https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/

9. One last step needed to complete the functionality of this second form would be to make sure that it shows the radio option for any existing connection between the current provider and a subspecialty checked, by default.

For this, you'll need some custom script, which can select the radio option, for the subspeciality which is already connected to the current provider.


<script type="text/javascript">
jQuery(document).ready(function () {
    jQuery('input[type="radio"][name="select-subspecialty"][value="[wpv-post-id item="@subspecialty-provider.parent"]"]').attr('checked', 'checked');
});
</script>

This script can be included right below the shortcode of the second form.

Screenshot: hidden link

Using the same logic and techniques, you can build a third editing form that will include two "checkboxes" type generic fields, one for the "Conditions" and the other for the "Treatments".

I hope this helps and please let me know if any step is not clear.

If you need more personalized assistance around custom code, you can also consider hiring a professional from our list of recommended contractors:
https://toolset.com/contractors/

regards,
Waqar

#1457991

This looks fantastic. Thank you so much, Waqar!

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.