This support ticket is created 4 years, 11 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.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
I want to create a new post type which is using some custom select fields (among other field types as well).
The option list of the SELECT fields should be dynamically generated with the data from other custom post types:
So post type
- SELECT field "A" with options from post type A
- SELECT field "B" with options from post type B
- SELECT field "C" with options from post type C
Unfortunately, the custom SELECT field only accepts static data, no dynamic data.
Hello. Thank you for contacting the Toolset support.
As I understand, for instance, if you have a post type X with 15 posts, you want to display those 15 post titles as options that should be dynamically generated for the seslect field. If this is correct then You can use the hook "wpt_field_options" to fill the options dynamically for your select dropdown.
For the example, the new "combination" post type (with the SELECT fields) represents a meal. Every meal has a choice of meat (steak, saucage, chicken), potatoes (cooked, mashed, fried) and vegetables (...). The meat, potatoes and vegetables each have their own custom post type.
To add meals, we need a new form with 3 SELECT fields (meat, potatoes and vegetables).
Thanks to the PHP code as suggested earlier, the options are already showing correctly in the SELECT fields.
However, the custom "meal" post type does not need to have SELECT fields to store the selected meat, potatoes and vegetables.
3 NUMERIC field is all we need to store the 3 selected values (=Post ID's).
So my question: what is the smart "form submit" code to store the values of the SELECT fields into the NUMERIC data fields?
However, the custom "meal" post type does not need to have SELECT fields to store the selected meat, potatoes and vegetables.
3 NUMERIC field is all we need to store the 3 selected values (=Post ID's).
So my question: what is the smart "form submit" code to store the values of the SELECT fields into the NUMERIC data fields?
===>
Do you mean you just wanted to store the ID of the selected option when you submit the form? Did you created the custom fields in backend that will be used to store those selected option values?
I have tried both versions:
1/ use 3 custom NUMERIC field type for "meal" post type, created in the TOOLSET backend
-> custom form with 3 "generic" SELECT fields which are populated by the PHP code
-> with the generic SELECT fields, the PHP code to create the option list from another post type works perfect
2/ use 3 custom SELECT field type for "meal" post type, created in the TOOLSET backend
-> custom form with 3 "automatic" SELECT fields (generated by the custom post) which SHOULD BE populated by the PHP code
-> with the "automatic" SELECT fields (generated by the custom post), the PHP code to create the option list from another post type is not working. It seems like the hook "wpt_field_options" is not found
I don't know which option is best, because I don't know how the data is stored in case of the TOOLSET custom "SELECT" field type. But because there is custom PHP code anyway, I was thinking that using a NUMERIC field for the data would be the clean solution.
Ok - both way its doable but as you say #1 is already integrated and works for you. Did you create the three custom fields that will hold the numeric value?
If yes - Can you please share the problem URL where you added the form and access details.
If no - please create three numeric custom fields that will hold the value and I will check further.
*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.
I have set the next reply to private which means only you and I have access to it.
the custom NUMERIC field - as defined in TOOLSET - is immediately available to use in the form as well, and it will be submitted without extra coding. So what if we also add the NUMERIC field to the form, but as a hidden field. After each change of the SELECT field, we copy to the hidden NUMERIC field. Then there is even no special code for the submit.
We would only need to create a function that will copy the selected value to the NUMERIC field on each change of the selected option.
Is this your test site?
I do not know why You made things complicated 🙂
I've added another field "add valve spring setup - cam follower 1" for test reason to the following custom field group and also set this custom field group to display with post type "Appears on Post Type(s): valve spring setups"
=> hidden link
Then added the following code to "Custom Code" section offered by Toolset:
=> hidden link
As you can see now the custom field "add valve spring setup - cam follower 1" is auto-filled with the options:
=> hidden link
Then, I added the field "add valve spring setup - cam follower 1" to your form and save the changes:
=> hidden link
And at last, the form is displayed on frontend with the field "add valve spring setup - cam follower 1":
=> hidden link
Now, I do not think that you need to write any custom code or anything as the field is populated and it will automatically save the add valve spring setup - cam follower 1" value (in database it will save the selected option ID) . Can you please check.
yes that seems to work - it's actually what I tried at the very beginning but it did not work.
However, I added the code at the bottom of the "funtions.php" file, not in the TOOLSET php code section like you did.
That seemed to work for the generic SELECT field, but not for the build-in SELECT field of your solution.
Anyway, your solutions looks perfect so I continue like that!