For these cases nested query loops with custom PHP is needed, while pagination e.g. show 12 posts per page won’t work with multiple loops. A simple query loop sorted by date and conditinally enabling the heading would (almost) satisfy the same requests in an easy to understand and efficient way.
Proposal
Provide a loopable wrapper element with no code output. It solely wraps elements any element given, also multiple ones, which can be conditionally shown/hidden.
Example uage
For the month divider a heading is conditionally enabled whenever the current post date starts a new month.
Following the development of other builders, there might soon be one of the first with rather unrestricted query loop possibilities. A loop element which acts as an invisible (no code output) container seems the best solution to provide query loop functionality.
The current approach of Bricks, with a single root element and query loop enabled elements is restricted and leads to tedious workarounds like replacing whole loops with PHP or fiddling around with several layers of nested queries and still end up with a non-perfect solution.
It would be a huge deal for pro users, when the restrictions from the essential loops would be removed. With new builders on the horizon, this would be another point to ensure customers can be kept. I am sure many are not even aware of the impact of this feature request.
A loop element could even be the one and only element dealing with queries. Then no element needs this special loop parameter.
thank you for the idea. I agree that this would be very nice (but not so easy to implement, if even possible the same was as the current query loop). I’ll present it internally, and we will discuss what we can do.
Yes, it’s a very interesting idea not to apply a loop to an element, but rather an element to a loop. If I understood the author’s idea correctly
Crockoblock has similar functionality. You can set up any loops separately, and then apply them in the right places. I used it for Elementor once, but that was a long time ago…
Exactly, and then you can even copy and paste the loops (element) without Bricks introducing another special UI or a fifth copy option. The loop element can automatically hold all existing queries and they could be reusable/selectable that way too.
That’s the only crucial improvement that I’m expecting from a Bricks 2.0, not a rating element. This will be necessary, when Bricks should stay relevant for Pro users.
I have long suggested a good idea in my opinion, but it was not implemented. This would be a good alternative. We prepare an array (or json) and this array will already work as a source for the cycle. For example, like this. It is possible to implement this as a separate element, but I think the meaning is clear.
Data extraction approach similar to loop source from “ACF group repeater”
Yeah, that would be an extension of the available loop inputs, which should no be tied to posts/categories etc. in the future. But this doesn’t solve the issues that Bricks has, due to the coupling of query ↔ element.
A loopable element can hold data and provide access to the properties via dynamic data, no matter if it’s from a query, JSON or a static array.
The current query loop limitation (single root element) makes common tasks unnecessarily complex. Simple things like inserting ads every N posts require custom PHP code and developer skills.
A dedicated Loop Element would solve this elegantly - you could add any elements within the loop iteration without DOM restrictions or complex workarounds.
This would make Bricks much more flexible for everyday content organization tasks that currently need custom development.
