SOLVED: ACF true/false value not usable in element conditions

Bricks Version: 1.5.6
Browser: Chrome
OS: macOS

I have a custom post type with an acf field called quote_accepted.
Now I want to show/hide a section in my bricks template based on this field is true or false.

I can find the field in bricks drop down and it converts to {acf_quote_accepted} as excpected but the value seems to always return an empty string.
not 0/1 nor true/false.

My workaround (if anyone trying to do the same thing before this is fixed) was to echo the result of a custom function.

In functions.php

function get_accept_quote() {
        $pID = get_the_ID();                            // ID of the post (ex Quote ID)
        $accept = get_field ('accept_quote', $pID); 
        return $accept ? "1" : "0";

In bricks builder dynamic data field


Now you can use 1 or 0 respectively for true / false condition in the value field.

Would be awesome if bricks detected true/false elements in acf/metabox and then gave true/false as alternatives in different format than free text field. ie drop down select.


Hi Emil,
Thanks so much for your report!

Unfortunately, I cannot reproduce the issue. In which template do you query the ACF field?

Best regards,


It’s the template type “single”.
Also, I have 2 fieldgroups for the custom post type. This is from the 2:nd one (I did not check if true/false from the first one works as excpected before posting).

Here are some useful screenshots for troubleshooting.

Works fine for me.

  • “Quote” CPT
  • Two custom fields (ACF):
    • show_text (True / False)
    • text (Text)
  • Bricks Single template (post_type: Quote)
  • Regular text element showing the custom text field
  • Condition on the text element to only show it when the custom True / False field is set to true

Hi aslotta.

I can also make it work like you did because you did only use one (1) field group.
the acf true/false returns empty string if false and 1 if true in the first fieldgroup.

the acf true/false returns empty string all the time when placed in the second fieldgroup.
At least in my setup.

Can you please try with multiple fieldgroups and see if this is the issue?
My second fieldgroup has this conditions:

post_type = quote AND
current_user_role = administrator

see screenshot

Do both True/False fields in the different field groups share the same key? If so I am pretty sure they override each other. Which is not specific to Bricks.

Can you tell me what the exact use case is? How do you expect the logic show/hide admin/non-admin to work?

OK, lets take this from the beginning in a clean install.
Follow this steps to reproduce the issue in a clean install.

Open a terminal (instructions for mac, but feel free to use another OS, steps is almost the same.

brew install --cask docker
mkdir ~/bricksbug
cd ~/bricksbug
vim docker-compose.yaml

paste this content to docker-compose.yaml.

    # We use a mariadb image which supports both amd64 & arm64 architecture
    image: mariadb:10.6.4-focal
    # If you really want to use MySQL, uncomment the following line
    #image: mysql:8.0.27
    command: '--default-authentication-plugin=mysql_native_password'
      - db_data:/var/lib/mysql
    restart: always
      - MYSQL_ROOT_PASSWORD=somewordpress
      - MYSQL_DATABASE=wordpress
      - MYSQL_USER=wordpress
      - MYSQL_PASSWORD=wordpress
      - 3306
      - 33060
    image: wordpress:latest
      - wp_data:/var/www/html
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro
      - 80:80
    restart: always
      - WORDPRESS_DB_USER=wordpress
      - WORDPRESS_DB_PASSWORD=wordpress
      - WORDPRESS_DB_NAME=wordpress

Create more upload so we can install bricks and plugins

vim uploads.ini

Paste the following content inside uploads.ini

memory_limit = 512M
upload_max_filesize = 10M
post_max_size = 10M

Start the docker container

docker-compose up -d

Go to plugins and erase akismet and hello dolly
Install and activate plugin
ACF PRO - paid version (6.0.3)
CPT UI - free version (1.13.1)

Go to appearance → themes and install bricks 1.5.6
Activate bricks license

Add a Custom Post Type called Quotes
CPTUI → add/edit post type
Slug: quote
Plural: Quotes
Singular: Quote
Has archive: true

Add a bricks template for the post type
Bricks → templates → add new
Title: Quote Single
Type: Single
Click: Publish

Create 2 separate fieldgroups with ACF - one for all users and one for administrators
Custom fields → field groups
Click: add new
Field group title: my_field_group_1

In this fieldgroup add 1 field.
Type: (choice) true/false
Label: my_choice_1
Name: my_choice_1

Conditions: post_type is equal to Quote

Hit: Save

Create one more field group like this
Custom fields → field groups
Click: add new
Field group title: my_field_group_2

In this fieldgroup add 1 field.
Type: (choice) true/false
Label: my_choice_2
Name: my_choice_2

Conditions: post_type is equal to Quote AND current_user_role is equal to administrator

Hit: Save

Both of this fieldgroups will now show up when editiing a post with post_type Quote.
If you are an administrator.

Create a Quote
Quotes → Add new
Title: my first quote
Check both checkboxes (my_choice_1 and my_choice_2)
Click: Publish

Set up the template with bricks
Now go back to bricks and open the template for quotes
Bricks → templates → Quotes Single → edit with bricks

Hit the section element once and the block element twice.
Insert one header in each block just to have som content.
The structure like this

Give the blocks different background so you can see the difference.

Use conditional logic for block 1

Use conditional logic for block 2

Give the template the proper conditions
In the builder hit the gear icon (settings) → Template settings → Condtions

Hit: Save

Now visit the quote on the front end.
In my case: http://localhost/quote/my-first-quote/

Now there is only the first block showing…
Even when viewing the frontend as a logged in administrator.

(My excpectations are to view both blocks for all users since the admin role is only for showing/hiding the interface in the backoffice - the value of the field should be used for all users - well, this seems not to be the issue anyway since for logged in administrators it does not show)

What seems to be the issue here
When removing the second display condition from my_field_group_2 in the ACF interface. Then the true/false-field returns as excpected. The error is in there some where.

1 Like

Ok. At least I understand what you’re doing here now.

And something seems to be wrong here indeed, @timmse. But to me it does not seem to be an element condition but a general dynamic data (tag) problem (see screenshot attached). Hopefully the screenshot makes it clear.

1 Like

I recorded a small screencast demonstrating the problem. Maybe this helps.

1 Like

Im glad you could reproduce the issue now.
Also Im glad it was not just me being stupid =)

And if anyone else stumbles across this issue before it is solved my workaround in the first post will do the job. Happy coding =)

Did a test, the problem exist like @aslotta and @etragardh explained.

Dear @timmse , maybe this would help to identify the problem for coding team.
The get_fields_locations() for Provider_ACF might wrongly states where should a field value to grab from. Currently, as long as a field condition included “User role” / “Current user” / “Current user role” / “User Form”, bricks will marked the field should grab it’s value from user meta. (Dev team save in array key of _bricks_location)

Hence, the dynamic tag always return empty value (it was wrongly getting from user meta which doesn’t exists) even we set it correctly in our post.

Hope this help and forgive me if I am wrong.

1 Like

Hey guys,
Thanks so much for heavily investigating this one!
Much appreciated! :raised_hands:

I’ve added it to the bug tracker :v:

Best regards,


Hey guys,
Bricks 1.6 (Beta 2) contains a fix for this problem.

You can download it manually in your account:

Best regards,

I think this is still an issue for Options pages.

Niether true/false or 1/0 produce any results.

For anyone interested, here is a return function that will work with ID by default or options:

function custom_get_acf_boolean($field, $location = "ID") {
    $location = $location === "options" ? "options" : get_the_id();
    $field = get_field($field, $location);
    return $field ? "1" : "0";

Then use == or != with 1 or 0


1 Like

I have the same problem and it is really annoying. ACF boolean fields do not work with conditions

PS: Still in bricks 1.6.1 – not solved at all

1 Like

You can use the :value modifier and compare against 0 or 1. Works as expected.

CleanShot 2023-01-03 at 20.16.53@2x


This works for me and is super simple.

My ACF field “acf_abendchef_name” is either empty or has a name (a text) in it. In Bricks, I simply check the condition of the field, i.e. if the field is not empty (!=), then it will print the content.




It’s end of may and it seems Conditions don’t work with Options Pages, at least for true/false fields.

A solution offered by @Patric with != doesn’t seem to be working too.

ohh this solution worked for me! But super annoying you have to look for workarounds for such simple things

1 Like

Also condition == 1 wont work if its inside group.

edit: just use :value as @aslotta SOLVED: ACF true/false value not usable in element conditions - #16 by aslotta mentioned.

1 Like