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.
Hi there! Beda was on my last ticket and wanted me to open a new one for this question. So if you want do forward this ticket to Beda, please do so.
My CRED-forms-notifications don't work without given %%POST_ID%% to all of my types-fields. When I do it without, no data-content is sent. For types-field it is clear to me, how to declare the post_id. But my wpv-conditional tags aren't working. I did it this way:
[wpv-conditional if="( $(wpcf-anfr-telefon).id(%%POST_ID%%) ne '']Telefon[/wpv-conditional]
This didn't work out. Beda told me to write it as in one of the two examples below:
[wpv-conditional if="( $(wpcf-customer-says) eq '' "]fdsaf[/wpv-conditional] [wpv-conditional if="( '[wpv-post-title id="%%POST_ID%%"]' eq '' "]fdsafs[/wpv-conditional]
The first option doesn't fit my needs, because there is no given ID and as I said: These fields are empty and don't show up in my notification – so this conditional is always empty and never true.
And in the second one there is a wpv-field, not a wpcf-field. As I understand, for types-fields I have to write the field like it is stored in the database, don't I? So what does it look like for my example from above? Like:
[wpv-conditional if="( '$(wpcf-anfr-telefon) id="%%POST_ID%%"' ne '']Telefon[/wpv-conditional]
I'm afraid, this doesn't work also. So I'm really stucked. Please for help!
Hello, this is Beda again.
1. Test Emails will never contain dynamic data like Post Fields
It cannot contain them as there is no data.
So the email will send only the hardcoded Strings (normal text)
2. The Custom Fields right now work like this:
- native Types Post Fields do not need a %%POST_ID%%
I tested this.
This code sends the below value:
[types field='price' format='FIELD_NAME: FIELD_VALUE'][/types]
This is a Field: Price: 22
It also works with %%POST_ID%% of course:
[types field='price' format='FIELD_NAME: FIELD_VALUE' id='%%POST_ID%%'][/types]
The same Field with Post ID: Price: 22
I tested this here:
Login is sent to your email.
3. Conditionals do work like this, and I tested this on the abovelinked CRED Form as well:
[wpv-conditional if="( $(wpcf-price) ne '' )"]this is a filled field[/wpv-conditional] [wpv-conditional if="( '[types field='price' format='FIELD_VALUE' id='%%POST_ID%%'][/types]' ne '' )"]this is a field with ID[/wpv-conditional]
Both are true, both work, and both send the data:
this is a filled field this is a field with ID
As such I see no problem or Bug, the conditional I submitted you is correct.
You can use Types ShortCodes as you see in my example above.
Please let me know if you need more help with this.
I tested on your site and you are right, every form of your code works there. So perhaps is an issue with custom post types, which were created in the old version of Types? I'm not sure, but the only thing I can say, that my CRED notifications worked fine, before I updated all my Toolset Plugins. And after the updates, they didn't work without the ID on two of my client sites.
I now specified my conditional-ifs with the ID as you did in 3:
[wpv-conditional if="( '[types field='anfr-nachricht' id='%%POST_ID%%'][/types]' ne '' )"]...[/wpv-conditional]
But I'm having problems with one of my Drop-Down-Fields, where you can choose how many children are going on vacation, my types-field "anfr-kinder". You can choose between:
* no children > "0" is stored in the database
* 1 child > "1" is stored in the database
* 2 children > "2" is stored in the database
I had a conditional-if which checked, if there is more than 1 child ('wpcf-anfr-kinder' gte '1'). I tried this with your code:
[wpv-conditional if="( '[types field='anfr-kinder' id='%%POST_ID%%'][/types]' gte '1' )"]...[/wpv-conditional]
But that didn't work. Am I right, that the types-field doesn't combine the given string with the database, but instead with the string in the dropdown-field. So I would have to check it against the text-string of my dropdown:
[wpv-conditional if="( '[types field='anfr-kinder' id='%%POST_ID%%'][/types]' ne '1 child' )"]...[/wpv-conditional]
But this would only check, if the dropdown is not "1 child", not if there are more children because I can't check with "gte" in a text-field. So in this case I would have to combine this conditional-if with two more conditionals. Like: is not "no child" AND is not "1 child" AND is not "" I did so in the meanwhile, but it's really complicated.
So again, isn't there a way to specify the ID when checking the database-fields (and not the types-field itself)? A conditional-if to check for $(wpcf-anfr-kinder) gte '1' with given ID?
1. So perhaps is an issue with custom post types, which were created in the old version of Types?
That should not be an issue, those Fields are populated by CRED, not Types.
Also, an update should not cause this, after all, we updated the Plugins as well on the Discover-WP instances.
2. my CRED notifications worked fine, before I updated all my Toolset Plugins. And after the updates, they didn't work without the ID on two of my client sites.
This seems a corruption of the Database.
I am not sure anymore, have you tried to re-create a Form?
Often those issues are solved by it.
Also, of course debug steps like not using any other Plugin but Toolset and a native Theme will show more, but I believe we did that already, right?
3. Am I right, that the types-field doesn't combine the given string with the database, but instead with the string in the dropdown-field.
I am not sure what you mean here.
4. But this would only check, if the dropdown is not "1 child", not if there are more children because I can't check with "gte" in a text-field.
What are you using, Select or Tex Fields?
These are not the same, they got nothing to do with each other.
A Text Field will hold a String you need to compare to.
Let's say your Field (Text Field) holds the value "my-value", so that is what you compare it to.
If it's a Select Field, the value to compare is what you set it to save in Toolset > Post Fields > your_filed_group > Edit > your_field > Custom field content.
Natively in Select Fields, those are numeric values, one each option, increasing, which results in values like 1,2,3 etc.
When you compare a Select Field in a Conditional you need to tell the code what you want to compare (Display value or Stored value?).
So the condition in the case of a Select Field would look something like this:
[wpv-conditional if="( '[types field='select' output='raw' id='%%POST_ID%%'][/types]' eq '1' )"] conditional shown content here [/wpv-conditional]
(already adapted to your specific situation where you need %%POST_ID%%)
This would compare if the Field's selected option is "1".
If you want to check if it is selected at all (not empty) you need to make sure that in Toolset > Post Fields > your_filed_group > Edit > your_field > Custom field content there is NO default selected, as otherwise, the Post will save something in all cases.
As long there is no default and the user selects NOTHING when saving the post, the condition to check whether it's empty or not would be:
[wpv-conditional if="( '[types field='select' output='raw' id='%%POST_ID%%'][/types]' eq '' )"] conditional shown content here [/wpv-conditional]
As you see I also add the attribute "raw" to make sure we compare only values and no HTML.
Does that solve the problems?
I'm sorry, my English isn't the best. You are right, it's not a text-field, it is a select-field. I meant the text-value of the select-field (on the left hand side of the field-form), which appears in the Dropdown on Frontend. Because when I filled in the conditionals without the "raw"-attribute, it compared these text-values in there. So the "raw"-attribute is exactly what I was looking for! Thanks a lot!
Yes, I did these debug-steps, before I wrote my first thread to the support-forum. I had the same issues with deactivated plugins and with your standard Toolset Theme. I first assumed, that my older php- and mysql-versions on this project are perhaps a part of the problem. But then it appeared on one of my others projects too, where these versions are all up-to-date ...
No, I didn't try to recreate the form already. And that would be a lot of work to do so again. So I'm now happy with the solution to add the IDs to all of my fields. It's worth the work, because I'm on the safe side now for all the upcoming updates. So if you don't want to get to the bottom of this problem for other users, that's okay for me.
But please don't mark this issue as resolved yet. I want to test the outcome with notifications from the next few guests, which are sending the form. I will then get back to you.
Thanks again! Diana
No problem, I will keep the issue open.
About not getting to the bottom, we do analyse this.
I have internal tickets with the Developers to test this feature thoroughly.
Please let me know if any issues surge.
Now all the conditional-fields seem to work properly. Raw-output did the trick for me.
So I'm closing the ticket.