SOLVED: Dynamic function for Element Conditions

How To
1

Hello,

Before Bricks 1.5.4, I used the “Conditional Display Add-On For Bricks Theme” plugin from itchicode.com to hide some icons when is the Homepage.

image
image590×1030 47.5 KB

And now I want to implement the same behavior with the new Element Conditions feature, but I don’t know how to achieve that. That is my config:

image
image592×616 13.8 KB

The element is always visible. What is wrong?

Thanks a lot!

1 Like
2

Hey Antonio,

I never used the itchycode conditions, but it seems like the bricks conditions just don’t honour true/false as boolean values. I think you need to use actual booleans instead like 1/0.

1 Like
3

Thanks cmstew,

It works with 1, instead of bool. It’s confusing for me since the is_front_page function returns a bool.

4

I think what’s happening though is this. Imagine that true is a bool so it equals 1, but if true is a string it equals the literally word ‘true’. So I think what bricks is doing is it’s comparing true (bool) to true (string), which is not equal.

This is what I would consider a potential bug. It might be worth creating a bug report about it.

2 Likes
5

In PHP, everything different from 0 (zero) or alike (empty stuff, “0”, etc.) is true, so you can use 1 and 0 for replacement of true and false respectively.

And I agree with @cmstew that the string true must be interpreted by Bricks as the actual string “true”, and that’s normal, since this string has to be potentially usable in conditions value.

1 Like
6

Oh, ya, the current Element Condition didn’t use boolean to compare.

And also that’s why I add a compare data type as dropdown in my temp plugin to do conversion when compare in php.

image
image846×529 12.2 KB

@cmstew and @yankiara were right.

Maybe bricks team got another plan to compare different type of data?

1 Like
7

@cmstew @yankiara @antoniogiroz
After my test, this is what I know.

  • The result of dynamic tag echo function {echo:is_front_page} will return string. If the result of your function is true, will be string 1. If the result of your function is false, will be empty string
  • The compare value we input always interpreted as string

Scenario 1:
image
If this is in front page.

  • Will compare string 1 with string true.
  • The element will be hidden, because result is false.

If this is not in front page.

  • Will compare empty string with string true
  • The element will be hidden, because result is false

Scenario 2:
image
If this is in front page.

  • Will compare string 1 with string 1
  • The element will be shown, because result is true

If this is not in front page.

  • Will compare empty string with string 1
  • The element will be hidden, because result is false

Scenario 3
image
If this is in front page.

  • Will compare string 1 with string 0
  • The element will be hidden, because result is false

If this is not in front page.

  • Will compare empty string with string 0
  • The element will be hidden, because result is false

Conclusion, boolean type compare is not what we think in php boolean compare in current Element Condition.

If using echo dynamic tag

  • use == and empty compare value for a false expected return boolean function
  • use != and 1 value for a false expected return boolean function (easier as explained by yankiara)
  • use == and 1 value for a true expected return boolean function
  • do not use 0 because false expected boolean return function will only return empty string

PS: Please correct me if I am wrong. I just tested for a few scenarios. Hope Bricks team can help on this.

1 Like
8

@itchycode It seems you inverted shown and hidden, since if comparison result is true, element is shown.

But otherwise I agree, and I was clearly wrong writing 0 could be used as false.
String zero (“0”) evaluates as FALSE in PHP, but in this case it cannot be used because return value is empty string, whis is different from “0”, as a string.
(In other words, my comprehension is that both empty string and zero string evaluate to false as boolean, but they are not identical if compared together as strings!)

So, my conclusion is that I will use “== 1” for true and “!= 1” for false, which seems more consistent and easier to remember :rofl:

By the way now I remember it is exactly what I used to do with Oxygen (same string-based values to compare) :wink:

3 Likes
9

Hahaha… you are right. I inverted the scenario result.

Will amend it

1 Like
10

Thank you for your clarifications, it would be great if Bricks adds a compare type selector.

11

It’s just first iteration of conditions. More improvements to come. Once the Conditions API is out adding our own compare types and conditions won’t be difficult. Next few updates should refine it a lot.

2 Likes
12

That’s some very cool!

13

Hi guys,
We’ve fixed this issue in Bricks 1.7 beta, now available as a manual download in your Bricks account: Account – Bricks

Please let us know if you are still experiencing issues.

Best regards,
timmse

1 Like