[Resolved] Cred generic field does not work with "persist"

[Author]

Posts

[Pat]

Hello,

I'm creating a Cred form using generic fields in order to retrieve some specific info.
Here is one of my codes :

  	<div class="form-group">
		<label>Année inscription</label>
      [cred_generic_field field='annee-inscription' post='inscription' type='textfield' urlparam='' class='form-control' output='bootstrap']
{
"required":0,
"validate_format":0,
"default":"[types field='annee' post='variable' format='FIELD_VALUE' id="175"][/types]",
"persist":1
}

[/cred_generic_field]
	</div>

The right info is displayed in the Cred frontend, but after submission, even with the "persist" parameter, nothing is stored in the database.

Any idea?
Regards
Pat

[Beda]

This Argument has been deprecated around 2 years go I believe.
It should still work in a backwards compatibility, but not as a new Argument which you can set with the GUI or is documented and officially supported.

That said, I analysed this, and it works on my local test:

[cred_generic_field field='sinlge_persist' type='textfield' class='' urlparam='']
  {
    "required":0,
    "validate_format":0,
    "default":"",
    "persist": 1
  }
[/cred_generic_field]

This field will NOT appear in the WordPress Admin thou, since this is not a Types Custom Field but just a native WordPress Field, hence there is no GUI for it in the Edit Post screen.
But it's saved to the database in my case.

The problem eventually is your placeholder, in the default value.
You use shortcode attributes in shortcode attributes in shortcode attributes, which is basically not allowed by WordPress.

But that would not matter if you actually fill a new value in the CRED Field, that is saved.
I tested this with the exact copy of your code, which logically did not serve me the contents of "[types field='annee' post='variable' format='FIELD_VALUE' id="175"][/types]", but I still can see the new value I add during the submit process to this field, in the Database.

Hence, most likely the issue you face is that you do not fill a new value on submit, and the value given by "[types field='annee' post='variable' format='FIELD_VALUE' id="175"][/types]" is wrong, misformatted or empty.

This may as said be due to the fact that WordPress at some point stops executing ShortCodes and/or stops due to breaking apostrophes like "" in "" or similar.

I sugget to doublecheck what "[types field='annee' post='variable' format='FIELD_VALUE' id="175"][/types]" outputs, and then as well adjust it's apostrophes to single ones only, and if that still does not work, try with a hardcoded value to test the mechanism.

If that works, it's due to the ShortCode and we may need to find another way to populate that field dynamically.
For example, with a custom shortcode with less attributes.

[Pat]

Hi Beda,

Thanks for your answer.
I recognize that this example is not the best concerning the field used, but I have several other generic fields in this Cred and none of them are recorded in the database.

This Cred is linked to a product and serve to define some additional info that will be linked to this product.
I can give you access if needed
Regards
Pat

[Beda]

This is strange since locally this works just fine.

Access will not help a lot.
I need to see this locally, track the code when it is fired, get its debug and see what is going wrong and where.

It is very strange that this does not work on your install, since there is not much that can stop this:
- it's a simple WordPress API at work here.

Are you sure that this issue persists throughout your site, post types, and other forms, even if there are no custom codes in place or other plugins that may interfere?

If so, I am happy to analyse a copy of the site, and then update you with the possible solutions.
https://toolset.com/faq/provide-supporters-copy-site/

[Beda]

OK, but this is not the issue we discuss here.

The issue is that persisting generic fields seem not to persist on your site.

To analyse this, I need a copy of the site.
Is this possible? If not, eventually just a copy of the Database and the zipped up Content of your Install (FTP)?.

I can then deploy this locally and see why those generic Fields are not saved properly on the install.

For other questions, related to how to or bug reports, please open a ticket for each issue.
This will allow us to help you more precisely and as well faster.

[Beda]

Thanks.

The private reply still holds no values.

Please let me know if you submitted them, in the case so I will immediately ask the developers for assistance since then the forum would be broken somehow:
I see no log in details or duplicator links (see screenshot)

[Beda]

Perfect.

1. The forum seems broken somehow
2. I received the link, I am downloading it.

[Pat]

Good,

Let me know if you need additional info.
Regards
Pat

[Beda]

On the Duplicate I have the form wp-admin/post.php?post=171&action=edit.
There I see a generic Field:

[cred_generic_field field='post_title' post='inscription' type='textfield' class='form-control' output='bootstrap' urlparam='']
{
"required":0,
"validate_format":0,
"default":"2018 - [wpv-post-title] [types field='jour-cours'][/types] [types field='heure-debut-cours'][/types][types field='minute-debut-cours'][/types]",
"persist":1
}
[/cred_generic_field]

This is all a little strange, since that CRED form, for example, uses a generic field to actually create the post title, for which we already have the proper CRED ShortCodes.
Moreover, the other generic fields seem duplicates of Types fields, which actually appear in the "Inscriptions" post that we create here.

When you already use Types fields there is no need for generic fields, and that is also the reason we deprecated their "persist".
It's not required in 99% of the cases to persist them.

When I submit this form (on a simple page), a post type of type "Inscriptions" is created, in state "bruillon".
The following fields get saved:
annee-inscription
tarif-inscription
animateur

Those are all generic fields, since they do not have the wpcf-prefix.
Hence they will not display in the WP Admin.
But they are saved to the Database.

Now, saving the post title like this (with generic fields) is not how you should use CRED.
Post Titles have their own proper ShortCodes, as well as Types Fields.

As far I see on your duplicator the generic persist works but it's not how you should use this CRED form.
You should add native field shortcodes and native post meta shortcodes, and use generic fields only for fields that relate to one specific form, and usually, are not used later.

[Pat]

Hi Beda,

First point concerning the Inscription title : how can I define it thanks to other custom fields of the parent (product)? The products can change (for example, the price can evolve during the year or the day can change also ..), so I need to record the data that was defined when the inscription has been done. That's why I'm using a generic field instead of a parent.

Second, I just tried again to create an Inscription (using the page AAA in order to click on the INSCRIPTION BUTTON of the desired product and this is still not working. I have also tried to add wpcf- to the field name in the generic field and this is not working.

Any idea?
Regards
Pat

[Beda]

1. The forum was not broken, it seems that it is required to add a ZIP url to that specific field.
But always the "post body" itself can be used as you did in your last reply.
(See ScreenShots attached)

It is possible that you did not see those warnings (our Developer is looking into this).
Just for expediting this, I enabled another private reply.
Can you take a screenshot of what you see, and send back to me?

Thanks 🙂

2. In reply to your last comment:

First point concerning the Inscription title : how can I define it thanks to other custom fields of the parent (product)? The products can change (for example, the price can evolve during the year or the day can change also ..), so I need to record the data that was defined when the inscription has been done. That's why I'm using a generic field instead of a parent.

OK, but that Generic Field has the exact same issue as the native CRED Post Title SHortCode:
You need to populate it with the data you want, right?
In your case, the "value from other custom fields of the parent (product)".
The same way you populate the Generic Field you can populate the native CRED Fields, they also feature the value attribute.

The correct way thou is to apply custom code to achieve your custom logic.
You would create a PHP Code that gets the values from the parent that you need, and then you return them to the form when it's saving the post, for example.
Not always this is necessary, in your case I think you can just proceed as you do now but use native CRED Fields (autogenerated fields, and then adjust the values).

Second, I just tried again to create an Inscription (using the page AAA in order to click on the INSCRIPTION BUTTON of the desired product and this is still not working. I have also tried to add wpcf- to the field name in the generic field and this is not working.

OK, but this is not what I mentioned and observe.
I mentioned that I submit this form on a simple page and that I see the fields (the generic Fields) in the database.
They are saved.

What obviously will not be saved is the generic post title field since it conflicts with the native post - I assume this will be having no value or not even be saved - here I suggest to use the Title Field as CRED generates it.

For all fields that are created in Types, please use the autogenerated SHortCodes from CRED, not generic field fields.

For all generic Fields, you do not need to add any prefix, as doing so will not automatically make them saving or showing in the WP Admin.
But, if persist is set to true, the generic fields are saved against the post ID created, in the database.

Can you confirm this on the site, when you submit the form on a single page?
This works fine on the very duplicator, locally.

The main question remains, that these generic fields do not seem required to create the post with the information you need.
You can autogenerate the form and populate the value as you wish of those new shortcodes.

This will then make sure the data is saved where it should.

[Pat]

Hi Beda,

Thanks for all this info.

I will try your proposal and let you know.

Just one question : as you can see, I have products and inscription postypes.
I have a WC Cred that is placed in the product page (or in a Views that lists products). Placing it in a standard page does not help as I need to retrieve product info.
When the user click on Cred submit, I want to retrieve info from the current product and place them in some field of "inscription".

Then, I tried to place it in a single page and submit it, but no info is recorded !!!

Is there any info I can sent you from my site to help in the debug?

Regards
Pat

[Beda]

CRED will always try to get data from the post created or edited.

So if you have a CRED Form, you cannot call data from a completely different post.
This, as elaborated, usually requires Custom Code.

The problem is that the form wants the data as from it's post type where it applies to.

But you should be able, as I elaborated, to populate those fields with ShortCodes in the value attribute.
Those shortcodes have to return the exact data you want (in this case, the data of the product in the loop).

There is no need to use Generic Fields for this.

Since the issue here is that "generic FIelds" are not saved to the database, which I cannot replicate, also not on the site provided, I must ask to discuss the other issues in other tickets.

The CRED Generic Fields do save their data to the database if they have a value submitted when the form is saved.
I tried this several times, on fresh installs but also on your install.

I see the fields saved.

Can you show me how this is not saved to the database?
When you submit this form passing the data manually on a single page?

When this does not work in a View - it is related to how we populate the data.

To debug this, these are the exact steps as previously shown:

- use a form with a persisting generic field
- insert it into a page
- submit with values
- see that it works (check database)
- repeat with a View
- see that it works (check database)

I did all these tests already locally and confirm the persisting generic fields are saved.
Even in the View of page AAA.
But those values will not, as elaborated, show anywhere on your post or WP Admin because those are WordPress native Custom Fields, they are not Types Fields.

To have this working, you need to observe the below paragraph:
- the entire issue is not that they do not save, the issue is that it's wrong to use them, in this case, as far I understand the project.
- the correct approach is to use the autogenerated form fields and populate them as you need.

If you stumble over issues doing so, this requires another topic.

[Pat]

Hi Beda,

I think I have understood what you said in your answer. I have tested it and this is working. That really a good point for me as I was thinking until now this kind of affectation can only be done thanks to a generic field !

Many thanks for your support
Regards
Pat