Hi,
It is hard to know what the issue might be. Usually, three scenarios might be included:
1) Keep the field in the form, hidden, and not required
In the form markup, use the hidden type (do not mark the field as required in the field group)
2) Set the value after the post is created
Use cred_save_data (not cred_before_save_data) so the post ID is valid and you’re past the server-side validation step.
add_action( 'cred_save_data', function( $post_id, $form_data ) {
// Limit to this form
if ( (int) $form_data['id'] !== 12345 ) return; // <-- replace with your form ID
// Read ?pos= from the URL, add 1
$pos = isset($_GET['pos']) ? intval($_GET['pos']) : null;
// Cast-position meta key for a Types field with slug 'cast-position'
$meta_key = 'wpcf-cast-position';
if ( $pos !== null ) {
update_post_meta( $post_id, $meta_key, $pos + 1 );
}
}, 100, 2 );
Note: The meta key for a Types field slug cast-position is wpcf-cast-position. Double-check this in the database or by viewing the input’s name attribute in the form HTML.
3) Quick sanity checks
Temporarily make the field visible and submit with ?pos=3. If the post saves and you see 4 in the saved field, your hook & key are correct—then flip it back to hidden.
If it still won’t save, remove the form-ID condition to see if you picked the wrong ID.
If you truly want to set it on the client, keep the field hidden and drop this in the form’s JS editor:
jQuery(function($){
var params = new URLSearchParams(location.search);
var base = parseInt(params.get('pos') || '', 10);
if (!isNaN(base)) {
$('input[name="wpcf-cast-position"]').val(base + 1);
}
});
But the server-side method above is more reliable (no dependence on front-end JS or timing), and it won’t block the save.
Again the points above are what I could guess but in the end if it gets more complicated you will need to hire a developer to handle such custom code.
Thanks.