WAIT: Custom element ID not working/recognized in 'bricks/posts/query_vars' filter

[Rem]

Bricks Version: 1.6.2

This looks like a bug, not 100% sure:

While using the ‘bricks/posts/query_vars’ filter:

Filter: bricks/posts/query_vars

When you use a check for $element_id in the filter, as in the above doc page examples, like this:

if ( $element_id === 'yjqekk' ) { //do something }

The $element_id checked against here is the ‘internal’ element id consisting of random characters.
It is not checking the elements’ ID as set in its setting in the left top: Screen Shot 2023-02-14 at 15.03.17.png - Droplr

Maybe I’m missing something here, but I’d expect you can set an element to a custom ID, and then check against it in this filter.

I tried this with a ‘Block’ element and a ‘Post’ element. For both only the randomized original ID works in the filter. The templates/blocks are properly saved of course after adding the custom ID. And the custom ID is present on the front-end as id attribute.

[wplit]

@Rem

I’d expect you can set an element to a custom ID, and then check against it in this filter.

No, the ID that is output on the front end is different to the element_id here. They’re separate things, they only look similar to start with because Bricks uses that element ID when it first has to create an ID for the element to add styles to, but when/if that’s changed, it doesn’t effect the actual real element ID.

delete your custom ID, and then Bricks will return the original ID that will look like #brxe-XXXXX where XXXXX is the ID you’re needing in your code for that element.

[Rem]

Thanks for clearing up that those are not the same.
Maybe it’s an idea to mention that on the hook’s page:

Filter: bricks/posts/query_vars

We have users in FacetWP support wondering why that hook does not work. I found this to be the cause after a lot of trial and error.

[jaclas]

I just ran into the same problem and through google came across this thread. I think this Bricks action (using automatic and hidden ID) is incorrect. I have several pages that have almost identical structure and for which I would like to have ONE filter. So I set a static ID in each of these pages (the same for a specific element), but I found that this does not work. And now I have to add in the filter code all the IDs generated by Bricks in each of these pages (and in the future remember that!), so that each of the pages can be processed by the filter, even though their code is structurally almost identical! This is a big hassle.

[mackarias]

I’ve also just wasted a LOT of time dealing with issues arising from the ID set in the builder not being the ID used by the filter.

+1 to this being clarified in the documentation ASAP

[Rem]

Also bumping this once more. In the FacetWP.com docs, we need to have this green banner clarifying how to get the correct ID:

Bricks | FacetWP

[Matej]

This is one way to get Bricks ID, but even the easiest way is to copy it, using the Bricks icon.

[Rem]

@Matej thanks, never noticed that icon before.
But the issue is that it’s unclear that this id is something else than what is shown in the input box, which is apparently called the ‘CSS ID’ (I see from the copy icon of that), which is not clear from the UI.
Adding to the confusion, in the filter and on the filter’s doc page, it is called ‘element_id’. So there is bricks ID, CSS ID and element ID, of which the first and last are the same.
It would be helpful to mention this on the page of the bricks/posts/query_vars filter.

[Matej]

Yap, I agree here, it could create confusion, if you are not used to this. Maybe that’s a thing we need to improve when we will rework the academy.

[digifish]

I came across this thread because I was trying to figure out how to change the bricks internal element ID as well…

I did find a workaround, building on the example from the academy…

if( $settings['_cssId'] !== '{{customID}}') return $query_vars;