Skip Navigation

[Resolved] CRED Form Generic field saving the option value and the option label

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.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 4 replies, has 2 voices.

Last updated by stuart 4 years, 11 months ago.

Assisted by: Christian Cox.

Author
Posts
#1405513

This is related to a previous ticket... for reference:
https://toolset.com/forums/topic/cred-form-generic-field-not-saving-taxonomy-data-cred_save_data/#post-1405451

I've managed to use CRED edit form with cred_save_data action to save the generic field values (multi-select) into a taxonomy.

I am using View to populate the options for this from a separate custom post type (this is so I can keep everything dynamic)

When the data is saved into the taxonomy it is saving the slug and the term name as the value... which is a number... this makes it difficult in the admin side to see what's selected

- see image: hidden link

Function:
[code]
<?php
/**
* New custom code snippet (replace this with snippet description).
*/

toolset_snippet_security_check() or die( 'Direct access is not allowed' );

add_action('cred_save_data', 'my_save_data_action',10,2);
function my_save_data_action($post_id, $form_data)
{
// if a specific form
if ($form_data['id']==386143)
{
if (isset($_POST['test']))
{
wp_set_object_terms( $post_id, $_POST['test'], 'test', False );
}
}
}
[/code]

CRED Form:
[code]
[cred_generic_field type='multiselect' field='test' class='partner-service-industries']
{
"required":0,
"persist":1,
"default":[[wpv-view name="test-tax"]],
"options":[[wpv-view name="partner-industries-select"]]
}
[/cred_generic_field]
[/code]

View output from the shortcode above in options: [wpv-view name="partner-industries-select"]
[code]
{"value":"385119","label":"Aged Care"} ,{"value":"373524","label":"Fishery"} ,{"value":"373525","label":"Tobacco"}
[/code]

I am just not sure how to access and apply the label to the taxonomy using the function above 🙂

help?

thanks

#1407135

Hi, I'm not exactly sure what you're trying to accomplish. What does "385119" represent here in the wp_set_object_terms call - is it the desired term ID of a new term "Aged Care"? Or the desired slug of the new term "Aged Care"? Or the ID of an existing term "Aged Care"?

If it's the desired ID, then you cannot set the ID of a new term in a wp_set_object_terms call. You could provide the numeric ID of an existing term, but you cannot provide the ID of a new term. The ID will be generated programmatically and returned by the wp_set_object_terms function call:
https://developer.wordpress.org/reference/functions/wp_set_object_terms/#return

If 385119 represents the slug of a new or existing term, then that's a potential problem, see here: https://codex.wordpress.org/Function_Reference/get_term_by

Warning: string vs integer confusion! Field values, including term_id are returned in string format. Before further use, typecast numeric values to actual integers, otherwise WordPress will mix up term_ids and slugs which happen to have only numeric characters!

It is generally not a good idea to use a numeric term slug because of potential confusion between term slugs and term IDs. Especially if the slug and the term name are not similar, like "aged-care" and "Aged Care".

If it's the ID of an existing term, then something is wrong because the system generated a new term with the slug '385119' instead of finding an existing term with that ID. Where are you getting this 385119 number from?

#1407831

Hey Christian- thanks for the input, I'll step back a little and let you know what I am doing.

The Generic field pulls from a view (of a separate custom post type)- this is how the option values and names are generated
:part of the view I am generating and hwy you are seing that numbe, its the wpv-post-id of another post.
( {"value":"[wpv-post-id]","label":"[wpv-post-title output="sanitize"]" )

I am doing this to save me having to input the same values again in a taxonomy and was hoping it would just add them as and when they are selected by the user ( a bit lazy? sounded logical).

the cred_save_data hook then updates the taxonomy on the custom post type and when using the function I have above it sets the slug and the name to be the ID.

I am assuming this is where I am going wrong:

"but you cannot provide the ID of a new term. The ID will be generated programmatically and returned by the wp_set_object_terms function call"

What I was hoping to somehow keep both in sync so that any changes in the original custom post type could just be used in this taxonomy without me manually updating both.

I can, in theory, use the slug of the original CPT, rather than the post id in the initial view, however, I think I will still have the issue of the taxonomy name not being very friendly.

So I guess, I'll just manually create all of the taxonomy terms and keep the slugs the same as my original custom post type - in case I want to match any of them at any point. 🙂

#1410685

That sounds like a reasonable workaround, and I've recommended something similar when Users want to set up a post relationship between posts of the same post type - like a "Related posts" feature. Toolset's post relationships don't currently support relationships between posts of the same type, so a reciprocal taxonomy term association is one functional workaround. Working with legible post slugs is arguably easier than working with IDs.

#1413989

What I was doing was an edge case I would say, so this should satisfy what I was trying to achieve but with a little more manual work 🙂

thanks

Update:

Actually - I just had an idea...

Interestingly you can pre populate the taxonomy data when you are setting this up.

Create a view of the data you want to insert - e.g in this case I have and "Industry" custom post type that I am using as a json data to populate the generic custom field data which I want ot insert in to a taxonomy.

Change up the view so that you are inserting the slug as the value, then all you need to do is go in an rename them slightly...

Then after your are done you can change the generic options to either a view of the new taxonomy or leave it as is, and then if someone updates the original CPT (Industry), youll have to go in and just amend the name.