Skip Navigation

[Resolved] CRED Generic Field won't be saved in DB

This support ticket is created 5 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)

Tagged: 

This topic contains 1 reply, has 2 voices.

Last updated by Christian Cox 5 years, 11 months ago.

Assisted by: Christian Cox.

Author
Posts
#1189640
Captura de pantalla 2019-01-23 a las 12.23.28.png

Hello,

I have this form created:

[credform]
<div class="form-group" style='display:none;'>
[cred_generic_field type='email' field='toemail' class=""]
 {
  "required":0,
  "validate_format":0,
  "default":"[types field='email' output='raw'][/types]",
  "persist" : 1
 }
[/cred_generic_field]
[cred_generic_field type='textfield' field='telefonodestinatario' class=""]
 {
  "required":0,
  "validate_format":0,
  "default":"[types field='nombre' output='raw'][/types]",
  "persist" : 1
 }
[/cred_generic_field]
[cred_field field='nombredestinatario' force_type='field' class='form-control' output='bootstrap' urlparam='nomdestinatario']
</div>
	<div class="form-group">
		<label>Votre e-mail</label>
		[cred_field field="courriel" force_type="field" class="form-control"  placeholder="Votre e-mail" output="bootstrap"]
	</div>
	<div class="form-group">
		<label>Vos nom et prénom</label>
		[cred_field field="nom" force_type="field" class="form-control"  placeholder="Vos nom et prénom" output="bootstrap"]
	</div>
	<div class="form-group">
		<label>Votre message</label>
		[cred_field field="demande" force_type="field" class="form-control" placeholder="Votre message" output="bootstrap"]
	</div>
	[cred_field field="recaptcha" class="form-control" output="bootstrap"]
	[cred_field field="form_submit" output="bootstrap" value="Envoyer" class="btn btn-primary btn-lg"]
[/credform]

This post form populates the custom post type "MENSAJES", creating a new post and sending a notification. This custom post type has a custom field named "toemail" that is where the notification is sent. This "toemail" field is populated via a generic_field from the custom field of another custom post type, as Shane suggested in this solution (https://toolset.com/forums/topic/cred-form-wont-fetch-the-email-from-the-displayed-result-to-send-notification/)

As you can see above, this is the code used:

[cred_generic_field type='email' field='toemail' class=""]
 {
  "required":0,
  "validate_format":0,
  "default":"[types field='email' output='raw'][/types]",
  "persist" : 1
 }
[/cred_generic_field]

This field "toemail" fetches the email raw value from the custom type field email of that post.

Well, the problem of this thread is that this field should be recorded in any submission into the post that the form creates, however, although "persist" : 1 is active, it won't be saved in the DB.

Can you understand why is this happening?

Thank you very much

Mario

PS: As you can see in the image, the toemail field will not save any information after using the CRED FORM

#1189830

This "toemail" field is populated via a generic_field from the custom field of another custom post type
When you see the Form in the browser, can you confirm the toemail field value is correct? You should be able to see this by inspecting the hidden field in the browser inspector, or you can add the Types field shortcode somewhere outside the generic field as a test:

Email address test: [types field='email' output='raw'][/types]<br />

If the correct email address is not displayed, we know the problem is that the Types field shortcode needs a post ID to determine which post has the email field. If the correct email address is displayed, we need to look elsewhere for the problem.