jemcbade

Good research.

I have also made a request in the Bricks forum for users of Bricks on their site.

Meanwhile we have a work around I think.

Thanks for all your work on this.

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.

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;

   }

}

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;
   }
}

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.

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.

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.

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.

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.

Sorted

Never mind. I think this is sorted.

Just for comparison, the Metabox CPT creator defaults to “Hierarchical”.

Yes. A settings page for CPT UI that I could set some defaults like Hierarchical “True”.

Another suggestion from a UI standpoint is the settings page is so long, getting back to the top is a lot of “mousing”. Maybe use some tabbing or other UI design to compact the settings so that the page is shorter and we can get to the Save etc. easier (with less ‘mousing about ?? )

Thanks for listening.

I’m sorry, but when I see this as a warning, I don’t feel this is something to invest in.

“This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.”

3 MAJOR releases. That’s significant. I just don’t have confidence to “play” with it.

If you update the plugin, then I will be more than happy to give it a try.

You say you have a new updated iteration for this, let’s see it please. The ball is in your court at this point.

Regards

Being that it is not supported, I have not tried it.