Thread

Hi, after upgrading to EE 1.6.9 build 20100805 I noticed issue concerning behavior of empty custom fields inside conditionals.

Say, we have custom empty field “analysis_source_title13” which is empty. Then this code will work correctly, i.e. conditional will be evaluated as FALSE and nothing will be outputted:

{exp:weblog:entries weblog="my_blog" category="6" sort="asc" limit="1" dynamic="off"}

{if analysis_source_title13 != ""}

{analysis_source_title13}

{/if}

{/exp:weblog:entries}

But in this code for some reason wrongly evaluates as TRUE

{exp:weblog:entries weblog="my_blog" category="6" sort="asc" limit="1" dynamic="off"}

{if analysis_source_title13 != ""}
<tr class="line_off">
<td class="checkboxtd">
<input type="checkbox" />
</td>    
<td>
{analysis_source_title13}
</td>
</tr>
{/if}

{/exp:weblog:entries}

and outputs

<tr class="line_off">
<td class="checkboxtd">
<input type="checkbox" />
</td>    
<td>

</td>
</tr>

The code

{exp:weblog:entries weblog="my_blog" category="6" sort="asc" limit="1" dynamic="off"}

{if "{analysis_source_title13}" != ""}
<tr class="line_off">
<td class="checkboxtd">
<input type="checkbox" />
</td>    
<td>
{analysis_source_title13}
</td>
</tr>
{/if}

{/exp:weblog:entries}

works correctly.

I consider this issue as a quite serious because many conditionals which earlier worked correctly might now be broken.

Conditional behavior should not have changed there. There is no need to brace your variables, likes so

{if "{foo}" == "bar"}

Instead

{if foo == "bar"}

should still work. It does in your first example, correct? I would suggest to start with a minimized template and build that up.

Hi Ingmar,

Here is my minimized template:

{exp:weblog:entries weblog="ebook_common" category="6" sort="asc" limit="1" dynamic="off"}

{if "analysis_source_title13" != ""}

{analysis_source_title13}

{/if}

{/exp:weblog:entries}

In it the conditional wrongly evaluates as TRUE and the output is

The conditional must evaluate as FALSE since the field “analysis_source_title13” is empty.

I am unable to reproduce this behavior. Does the same thing happen with other custom fields, using both simple and advanced conditionals?

Hi Ingmar,

I sent you email describing steps to reproduce the issue on the fresh install of EE 1.6.9.

I have logged in to your site and modified the site/test template. It’s working now as expected, I think, can you confirm?

Hi Ingmar,

In test template I unintentionally added quotes around field name, but the issue has nothing to do with quotes. Please, check again.

Laisvunas,

Ingmar will be on shift in a few hours and will check again for you. Thanks for your patience.

You custom field was, in fact, not empty: it consisted of a single space… very hard to spot, of course. Once I corrected that (the custom field for entry_id 1 is empty now) all conditionals worked as expected. Can you confirm, please?

Hi Ingmar,

Thanks, now it’s clear why conditional was not working as expected.

But it seems that this behavior can be considered to be a bug. The content of custom field is being treated inconsistently: in case content of custom field is being outputted as the value of single variable of exp:comment:entries tag its content is trimmed, but in case content of custom field is being compared to some string inside conditional it is not trimmed. It seems that since content of custom field is outputted trimmed it also should be compared trimmed.

Current behavior is counterintuitive. Consider this scenario. The user posts some entry. Inside that entry there is custom field “my_field” which has as its value some string. Inside template there is code inside exp:weblog:entries tag:

{if my_field != ""}
blah blah
{my_field}
blah blah
{/if}

After some time user edits the entry and deletes the value of “my_field” custom field but accidentally leaves single white-space symbol. In this case above code contrary to expected will have output and the user will sit scratching its head pondering if the output exists because of some mysterious template bug or because of some EE bug or because of what?

Perhaps current behavior exists because of some overwhelming reason, but I don’t imagine how it can be justified.

Hi Laisvunas,

This is how the conditional comparison works. Please do submit a Feature Request if you think that this needs to be changed.

Cheers

Greg

Posted feature request here.

Hi Laisvunas,

Okay, thanks. I’ll go ahead and close this thread now.

Cheers

Greg