[Resolved] problem with apostrophe in wpv-conditional

[Author]

Posts

[eliseD-2]

I've seen a few threads on this topic, but no solution that has worked for me.

I am testing for an empty field in a CRED form, but the field often contains an apostrophe, and so the wpv-conditional isn't working.

The conditional I am using is checking a field from a parent post:

[wpv-conditional if="'[types field='question1' id='$test'][/types]' ne '' "]

I saw a thread that suggested to replace the wpv-conditional with something like this:

[wpv-if f1="wpcf-someidentifier" evaluate="!empty($f1)"]
blah blah
[/wpv-if]

So I tried this:

[wpv-if f1="wpcf-question1" id="$test" evaluate="!empty($f1)"]

But this didn't work for me.

Can you help?

Elise

[Beda]

Whenever you have a paostrophe in a Field, and use a HTML conditional to evelaute the field's content, this will break.

It's a BUG in Views.
All Conditionals work fine, but when you have a apostrophe like "'" in your Field's value, this will break your conditional.

You could workaround this by NOT using this apostrophe:
'

This below will work:
`

As you see only a "backwards" apostrophe will not break the output.

However, the simple evaluation wether a Field is empty or not, will also work if the Field holds a apostrophe as '.

But only if you compare a field of the Current Post.
As soon you use that to grab values of a PARENT post it will break, if the parent has a apostrophe in that value.

Also here, you can workaround with using the ` apostophe.

I will push the internal Issue Tracker Ticket becuase right now there is not solution for it.

[eliseD-2]

Okay. Not using an apostrophe, or using a backwards apostrophe, is really not an option for me. And for the particular function I am writing, I need to call the info from the parent post.

So - if you "push the internal issue Tracker Ticket" - would that result in a bug fix from Toolset? And if so - would that be soon - or would it be at some unknown time in the future?

If it looks like it's going to be a long wait, I might change the field to a WYSIWYG field - but I don't want to do that if I don't have to since I can't just change the field time - I have to create a new field and delete the original one (and I have 25 fields that will be affected by this!)

Thanks.

Elise

[Beda]

It will not be fixed in this upcoming release.

There is development for this planned for the 2.3 release, but when exactly our developers will release a Update including the required Fix is not up-to us Supporters to determine.
Each issue reported in, whether a bug or a new feature request, is taken seriously into consideration.
It is given a high or low priority based on a number of factors.
Factors which those with the overview of all things related are in the best position to determine.

I apologize any inconvenience this may cause.

Thank you for understanding.

[Juan Supporter Timezone: Europe/Madrid (GMT+02:00)]

Hi Elise

Ths is Juan, lead Views developer.

I see that we do have a problem with conditonals, when trying to get fields values from related posts. You do so by using a Types shortcode and an id="$syncro" attribute, hence getting the data from the parent post on the "test" post type.

We are aware of an issue with conditionals, caused by the order in which shortcodes are getting parsed. In your case, the Types one gets parsed before the conditional itself, so the values to compare can introduce quotes, hence breaking the comparison. On the other hand, the syntax $(field-name) gives us much more control on the value to compare, and we do clean it before comparing it, which means that some characters are removed.

As you can see, each side of the comparison is managed on a differet way, and while one can change its value for security reasons, the other can not and may break things.

We want to bring safety and uniformity for this. But first, let me stress that the $(field-slug) syntax is the preferred method for comparing field values, and that the wpv-if shortcode should not be used in any new comparison:
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/checking-types-fields-and-custom-fields/

The only reason that forces you to use a Types shortcode is because the $(field-slug) syntax does not let you get data from the "test" parent post. We are extending this $(field-slug) syntax so it lets you do this, hence there will be no need to use a Types shortcode directly anymore. But this is a bold change and it will need proper testing, so I thank you for your patience. This change is already in the works and will get included in our next major update. On the meantime, I am sorry as I do not have a better alternative for this.

Hope it helps.

Regards.

[eliseD-2]

Thanks. I'll just keep using the wpv-if until this gets fixed another way.

Thanks.

Elise