Bricks: Display icon from ACF Repeater Select Field

I am not a bricks user so I don’t have first hand experience with this. But googling your issue I did find this forum:

https://forum.bricksbuilder.io/t/problem-with-acf-fontawesome-value-in-a-repeat/10802/3

The issue seems to be related to how this plugin initializes itself, and there is some workaround code from another user there. Changing the way this plugin initializes is something I’ve looked into as a future enhancement but hopefully their workaround will get you where you need to be now.

I ended up spending some time on this tonight along with a few other updates I’ve been sitting on. It’s currently in version 4.0.7 of this plugin. I haven’t fully launched that version yet but it can be downloaded here:

https://www.ads-software.com/plugins/advanced-custom-fields-font-awesome/advanced/

Go to “ADVANCED OPTIONS” and download the “Development Version” if you are able to test it out.

Can you download and test this new version to see if it resolves the problems you are having in bricks?

The field for a description is showing from a pick list of ACF fields but not the icon field.

These are inside a repeater and the loop option for the ACF repeater is showing to be associated with the repeating loop.

I am trying to use the code shown on the Bricks forum

If you want to play with your product using Bricks the trial is available

I’m happy to test also.

Can you test with the ‘development version’ I mentioned in my earlier post, and without the code from the bricks forum? Or is that what you already tested?

Also can you let me know if you are using FontAwesome 5 or 6 fields?

I’m using version 5.x of fontAwesome

I have tested the development version with and without using the PHP Snippit.

I was trying to use it inside a repeater but now I am testing as a stand alone field using your field type.

The field does not appear inside the Bricks ACF variable list.
If I use the PHP snippit, the function does not return the icon. I know the function call works because I can return other things from the same function such as a text string.

Thank you for your time on this. I hope we can get it sorted and hopefully using the field inside a repeater ultimately.

May or may not be helpful, but using the release version or the development one, I see the icons inside the Bricks editor but not on the front end.

The page is an archive page showing all the members of a custom post type.

Well, I asked bricks for a license of their software for testing and they kindly provided one.

I was able to get an ACF FontAwesome field to output to the page front and backend, but the way I did it has nothing to do with how this plugin loads itself and works both on the currently distributed version of this plugin, as well as my new development version.

I put the following code in functions.php:

function fetch_fontawesome_icon_from_loop() {
	$acf_row = \Bricks\Query::get_loop_object();

	if ( isset( $acf_row['icon'] ) ) {
		return $acf_row['icon'];
	}
}

I then called that function from within a bricks content area like so:

{echo:fetch_fontawesome_icon_from_loop()}

I’ve written back to bricks to ask them if this ‘workaround’ is the best way for users of my plugin to integrate their FontAwesome icon fields into bricks. I think ideally there would be a ‘dynamic data’ integration into the core ‘icon’ field that ships with bricks, but I suspect this would take some integration work in their part to make work.

Thanks Matt

I’ll try to check this out sometime today.

I hope you and the Bricks team can find a way to make the field show up in the dynamic fields list. I don’t think they will use the “Icon Element”. I think it will have to be detected and displayed in the Dynamic Data list.

Sounds good, let me know how it goes. Do keep in mind you will need to update the ‘icon’ part of my code example to match whatever you named your FontAwesome field when you created it.

I’ve messaged back and forth with Bricks about trying to find a smoother integration for this. It looks to me like it will take some integration work on their end and I’m not sure if they are interested in doing that kind of work for 3rd party ACF fields. But we’ll see what they say.

I recommend you contact: Sridhar Katakam who is the brains behind BricksLabs

He is a pillar in the BricksBuilder community. He and an associate run Bricks Extras.

These guys know Bricks under the hood about a well as anyone and they are community focused.

I have always found them to be very supportive.

It seems to me that since these fields should be listed like all other ACF fields in Bricks, that possibly there is some kind of registration of the field missing. Could that be it?

I tried a test with some “unlisted” field types from another ACF Plugin “ACF Extended” and some of their additional fields do not show in the list either.

This code below does return the contents of the field.

// return code snippit

function return_code_snippit()
{
$post_id = \Bricks\Query::get_loop_object_id();
$snippitFetch = "post_" . $post_id;

$snippitFetchCode = get_field("code_snippit", $snippitFetch);

if ($snippitFetchCode) {
    echo $snippitFetchCode;
} else {
     echo $post_id;
   }
}

A little progress… I am able to return an icon field icon using:

I needed to re-save the posts to get them to appear.

No progress getting icon fields from a repeater yet.

function fetch_post_property_icon()

{

$post_id = \Bricks\Query::get_loop_object_id();

$iconFetch = "post_" . $post_id;

$post_icon = get_field("property_icon", $iconFetch);

if ($post_icon) {

echo $post_icon;

} else {

     echo $post_id;

   }

}

function get_all_repeater_rows($post_id, $field_name)

{

// Check if ACF is active

if (function_exists("get_field")) {

// Get all rows from the repeater field

$rows = get_field($field_name, $post_id);

// Check if rows exist

if ($rows) {

return $rows;

} else {

// No rows found

return false;

}

} else {

// ACF is not active

return false;

}

}

function getTheRows()

{

$field_name = "property_amenities"; // Replace with the actual name of your repeater field

$post_id = \Bricks\Query::get_loop_object_id();

$rows = get_all_repeater_rows($post_id, $field_name);

if ($rows) {

foreach ($rows as $row) {

// Access individual repeater fields within each row

$sub_field_value = $row["amenities_icon"];

echo $sub_field_value;

}

} else {

// No rows found

echo "No repeater rows found.";

}

}

 

Success but it’s all with a couple PHP functions. It’s messy code that should be re-written BUT it works to get icon fields inside a repeater.

I peaked into the codebase for bricks. This is the function that ‘whitelists’ which ACF fields are supported:

/wp-content/themes/bricks/includes/integrations/dynamic-data/providers/provider-acf.php:833

/**
 * Get all fields supported and their contexts
 *
 * @return array
 */
private static function get_fields_by_context() {
	$fields = [
		// Basic
		'text'             => [ self::CONTEXT_TEXT ],
		'textarea'         => [ self::CONTEXT_TEXT ],
		'number'           => [ self::CONTEXT_TEXT ],
		'range'            => [ self::CONTEXT_TEXT ],
		'email'            => [ self::CONTEXT_TEXT, self::CONTEXT_LINK ],
		'url'              => [ self::CONTEXT_TEXT, self::CONTEXT_LINK ],
		'password'         => [ self::CONTEXT_TEXT ],

		// Content
		'image'            => [ self::CONTEXT_TEXT, self::CONTEXT_IMAGE ],
		'gallery'          => [ self::CONTEXT_TEXT, self::CONTEXT_IMAGE ],
		'file'             => [ self::CONTEXT_TEXT, self::CONTEXT_LINK, self::CONTEXT_VIDEO, self::CONTEXT_MEDIA ],
		'wysiwyg'          => [ self::CONTEXT_TEXT ],
		'oembed'           => [ self::CONTEXT_TEXT, self::CONTEXT_LINK, self::CONTEXT_VIDEO, self::CONTEXT_MEDIA ],

		// Choice
		'select'           => [ self::CONTEXT_TEXT ],
		'checkbox'         => [ self::CONTEXT_TEXT ],
		'radio'            => [ self::CONTEXT_TEXT ],
		'button_group'     => [ self::CONTEXT_TEXT ],
		'true_false'       => [ self::CONTEXT_TEXT ],

		// Relational
		'link'             => [ self::CONTEXT_TEXT, self::CONTEXT_LINK ],
		'post_object'      => [ self::CONTEXT_TEXT, self::CONTEXT_LINK, self::CONTEXT_LOOP ], // Support Query Loop @since 1.8.6
		'page_link'        => [ self::CONTEXT_TEXT, self::CONTEXT_LINK ],
		'relationship'     => [ self::CONTEXT_TEXT, self::CONTEXT_LINK, self::CONTEXT_LOOP ],
		'taxonomy'         => [ self::CONTEXT_TEXT, self::CONTEXT_LINK ],
		'user'             => [ self::CONTEXT_TEXT ],

		// jQuery
		'google_map'       => [ self::CONTEXT_TEXT ],
		'date_picker'      => [ self::CONTEXT_TEXT ],
		'date_time_picker' => [ self::CONTEXT_TEXT ],
		'time_picker'      => [ self::CONTEXT_TEXT ],
		'color_picker'     => [ self::CONTEXT_TEXT ],

		'group'            => [ self::CONTEXT_TEXT ],
		'repeater'         => [ self::CONTEXT_LOOP ],
		'flexible_content' => [ self::CONTEXT_LOOP ],
	];

	return $fields;
}

When Bricks loops through ACF fields on the page, it checks their type against this list, and if it’s not in the list it isn’t available from the Dynamic Data dropdown.

If I manually edit their files, and add a line for this field:

'font-awesome'	   => [ self::CONTEXT_TEXT ],

The font awesome field shows up in the dynamic data dropdown just like the other ACF fields. Selecting it in a field like ‘basic text’ successfully injects the icon element into the page and renders it frontend and backend.

Unfortunately I see no action hooks/filters available for 3rd party developers to register their own field type(s). So to do this properly would take cooperation of their development team to integrate.

I’ve sent my conclusions/recommendations to the bricks support team on how they could add a filter for 3rd party field types like mine to make them available within the dynamic data selection.

I’m not sure if this is something they are interested in supporting or not so I am unsure if they will take any action on those recommendations.

For now there is a workaround (the fetch_fontawesome_icon_from_loop() function I talked about earlier), and a hack (editing their core file to add support to my field).

There isn’t anything more I can do here.