Skip Navigation

[Resolved] Delete custom fields using cred_before_save hook?

This support ticket is created 5 years, 8 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
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+00:00)

This topic contains 6 replies, has 2 voices.

Last updated by julieP 5 years, 8 months ago.

Assisted by: Nigel.

Author
Posts
#1211228

I have a cred_save_data hook which is applied to the 'create' version of my form. The hook creates new custom (repeating) fields and populates the values based on fields completed by the user. For the 'edit' version of the form, these fields need to be deleted before the edit form is submitted but I'm struggling to implement this. I've tried using the example given in the documentation https://toolset.com/documentation/programmer-reference/cred-api/#cred_before_save_data, but this returns a 'too few arguments' error.

I've also tried it simply like this but the same error is returned:

add_action('cred_before_save_data', 'before_save_data_form_68',10,2);
function before_save_data_form_68($post_id, $form_data){

	  if ($form_data['id']==68){
	      
	      delete_post_meta($post_id, 'wpcf-my-custom-field');
	  }
}

How do I do this please?

#1211286

Nigel
Supporter

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

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

Hi Julie

You are an experienced user so forgive me for stating the obvious, but an edit form does not have to be the same as the publish form.

If you don't want certain custom fields to be updated by the edit form, then remove the fields from the form itself, so that they are not submitted in the first place.

I'm guessing you have a reason for not doing this, but let's clear that up first.

#1211335

Hi Nigel

I probably should have explained the whole process!

When the user first creates the post, the value of main-custom-field is used in a hook to create a variable number of new fields (my-custom-field) each with a value based on the value of main-custom-field. For the purposes of my question, let's assume that a final post contains main-custom-field with a value of 1 and 2 x my-custom-field with values of A and B. When the user then edits that post, they might change the value of main-custom-field which might mean that now only 1 x my-custom-field should exist with a value of X. Therefore, when the edit form is submitted, the 2 x my-custom-field with values A & B need to be replaced by my-custom-field with value X.

I looked at using the cred_before_save_data hook to delete the existing and then the original cred_save_data hook to create the 1 x my-custom-field. Trying to update an unknown number of repeating fields seemed mega complicated if not impossible. I also didn't want to simply add the new repeating fields because leaving the original my-custom-field would skew the View output.

Is this a bit clearer??

PS: the 'Submit this form without reloading the page (use AJAX)' box is unchecked and I've checked that the before_save_data function is working (I used the test code provided in this post https://toolset.com/forums/topic/cred_before_save_data-not-firing/#post-1136646). I've also tried varying ways of writing the hook (e.g. with $post_id = $form_data['container_id']; to get the post ID and just $post->ID instead of $post_id in the delete_post_meta variables) but nothing is working.

#1211764

Nigel
Supporter

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

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

I guess the problem conceptually with using the cred_before_save_data hook is that the edit form is submitted with whatever fields, you intervene to change some fields as currently stored in the database, and then the form submission continues and potentially overwrites whatever you just did.

(That would depend on exactly what fields are included in the form, and I don't know those details.)

Why don't you stick to the cred_save_data hook instead?

You can expand the same function you already use, i.e. you'll only be hooking in a single time.

Your code first checks if this is the edit form. If it is, it deletes the unwanted custom fields.

It then checks if we are on either the intended publish or edit form, and does whatever you did before.

I think that should work without getting into details.

#1211839

That's interesting! I moved my delete action to a save_data hook and the re-creation of the new my-custom-field values to a submit_complete hook and now I get the results I was looking for!

I'm curious though; why does the delete action not work in a before_save_data hook?

#1211872

Nigel
Supporter

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

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

Hi Julie

I'm not sure what the problem is with your code. I just tested this locally and didn't have any problems.

I have a post with 'start' and 'end' custom fields.

I have a form to edit the post. The post has values for both, but my form doesn't include the end field, so when I submit the form the $_POST object knows nothing of the end field.

I have this little bit of code to delete the end field from the post:

function tssupp_edit_form( $form_data ){

    if ( 15 == $form_data['id'] ){        
        delete_post_meta( $form_data['container_id'], 'wpcf-end');
    }
}
add_action('cred_before_save_data','tssupp_edit_form');

I edit the existing post with the form, submit it, and afterwards confirm that the post no longer has an entry in wp_postmeta for wpcf-end.

#1211929

I can see your code is slightly different to mine but even when I re-write mine to match your format, it doesn't work so it's certainly strange. I'm happy it's working with the save_data hook so I'll run with that for the time-being and come back to testing it with a before_save hook on a sparse, single site install.

Thanks for your help & have a good weekend