[Resolved] Failure to save form data derived from generic form fields

[Author]

Posts

[Paul Bowman]

I’m working on the same project for which I sought help in two previous tickets a few weeks ago, <a href="https://toolset.com/forums/topic/using-cred_save_data-with-generic-multiselect-field-array-output/">‘Using cred_save_data with generic multiselect field array output’</a> and <a href="https://toolset.com/forums/topic/generic-select-form-field-from-repeatable-field-group-one-to-many-relationship/">‘Generic select form field from repeatable field group, one-to-many relationship’</a>.

The difficulty I’ve run into now is related, but the case seems simpler, if anything. I’m building out the user-facing elements for a post-type connected to those I was working on earlier, and I’m using generic select form fields drawing on repeatable-field-group data from a parent in a manner essentially the same as done with success elsewhere in the project. My generic select fields in the current instance display query data correctly, and cred_save_data hook usage is effectively copy of other working functions serving the same purpose elsewhere. In the current instance, however, the generic field form data isn’t getting saved.

Below, the relevant parts of the two form with respective corresponding functions, mostly identical, as I have them at the moment.

I’ve experimented with producing the selection list in different ways, but this seems to have no bearing on the problem. I’ve included "persist":1 and removed it without effect. I’ve also tried variations of the save functions using add_post_meta() and update_post_meta(), again apparently without effect.

<div class="form-group">
	<label for="%%FORM_ID%%_task-assignable-worker-a">[cred_i18n name='task-assignable-worker-a-label']Assignable Worker A[/cred_i18n]</label>
	[cred_generic_field type='select' field='task-assignable-worker-a' class="form-control"]
	{
	"required":0,
	"default":[ [types field="task-assignable-worker-a" output="raw"][/types] ],
	"options":[ [wpv-post-body view_template='filtered-worker-selection'] ],
	"persist":1
	}
	[/cred_generic_field]
</div>

function jobtask_update_worker_select_a( $post_id ) {
	if ( isset( $_POST[ 'wpcf-task-assignable-worker-a' ] ) ) {
		$new_val = $_POST[ 'wpcf-task-assignable-worker-a' ];
		update_post_meta( $post_id, 'wpcf-task-assignable-worker-a', $new_val );
	}
}
add_action( 'cred_save_data_1531', 'jobtask_update_worker_select_a', 10, 2 );

and

<div class="form-group">
	<label for="%%FORM_ID%%_task-street-address">[cred_i18n name='task-street-address-label']Job Task Street Address[/cred_i18n]</label>
	[cred_generic_field type='select' field='task-street-address' class='form-control']
	{
	"required":0,
	"options":[ [wpv-view name="task-addresses-selection-container"] ]
	}
	[/cred_generic_field]
</div>

function jobtask_update_address_select( $post_id ) {
	if ( isset( $_POST[ 'wpcf-task-street-address' ] ) ) {
		$address = $_POST[ 'wpcf-task-street-address' ];
		update_post_meta( $post_id, 'wpcf-task-street-address', $address );
	}
}
add_action( 'cred_save_data_1587', 'jobtask_update_address_select', 10, 2 );

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

Hi there

I'm not familiar with the work you have done so far, but looking at the code samples you share I can spot an obvious problem. Hopefully fixing that will be all you need.

Types custom fields are stored in wp_postmeta with a 'wpcf-' prefix.

A generic field added to a Toolset Form is not a Types custom field, and hence does not use the 'wpcf-' prefix.

In the examples above you are checking the $_POST object for the field value but you are using the 'wpcf-' prefix.

If, for debugging purposes, you send the $_POST object to the debug.log you should see that the form will contain a value where the key is the field slug without the 'wpcf-' prefix. (However, if you are then trying to update the post meta for a Types custom field with the same slug, then the 'wpcf-' is required.)

Here's how you would send a readable version of an array or object to the debug log:

error_log('$_POSTobject: ' . print_r($_POST, true));

(If you haven't already, turn on the debug log by editing your wp-config.php file and change the line with WP_DEBUG like so:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DISABLE_FATAL_ERROR_HANDLER',true);

That will create a debug.log file in your /wp-content/ directory which you can examine in any text editor.)

[Paul Bowman]

That was it. I’ve been giving my generic form fields the same slug as the Types custom fields the values get saved to, and didn’t notice that I was muddling the two things in the save function. Corrected, the function in my second example is:

function jobtask_update_address_select( $post_id ) {
    if ( isset( $_POST[ 'task-street-address' ] ) ) {
        $address = $_POST[ 'task-street-address' ];
        update_post_meta( $post_id, 'wpcf-task-street-address', $address );
    }
}
add_action( 'cred_save_data_1587', 'jobtask_update_address_select', 10, 2 );

I’ll need to go back and look at hooks I set up previously, apparently working fine, which were copied here. It may be that they’re not working as nicely as I think they are, but that something about my process has obscured the fact.

And I need to attend to the debug log. Your prod to this end is entirely apt.

Thank you, Nigel!