There are two basic ways to loop something in a page builder environment: a “Loop” element and a toggle-based “loop” feature.
Oxygen Builder, for example, has a Loop element that they call a “Repeater.” Whatever you want to loop goes inside the repeater and you configure your loop settings on the Repeater element itself.
Bricks Builder, on the other hand, allows you to turn certain existing elements (but not any element) into a loop by toggling a switch. When you elect to loop something, you get access to the loop settings for that element.
Which way is better, though?
Let me confuse you really quick and then I’ll snap you back into clarity…
Looping in Bricks is far better and easier than looping in Oxygen, but Oxygen’s premise is superior to Bricks’.
OK, OK, let’s clarify all this.
A dedicated Loop element is superior to a toggle-based looping solution on existing elements, assuming the builder executes the architecture correctly!
Here are the problems with Oxygen’s loop architecture:
- It forces a single child that gets looped. You can put elements inside of this child that’s being looped, but you can’t loop multiple children. This creates structural limitations, especially when using nested loops.
- The child that gets looped is forced and you can’t control the HTML tag of the child. This can produce incorrect code in certain situations. For example, it’s impossible to correctly create semantic lists with loops.
- You can’t safely drag things into and out of the loop without risk of breaking the repeater. In some cases, the errors are unrecoverable.
Here are the problems with Bricks’ loop architecture:
- Since looping is an action you assign to elements, you can’t always include new things in the looping behavior unless they actually, truly belong as a child of that specific element.
- If you loop the wrong thing on accident, you can’t move the loop. You have to undo the loop on the incorrect element and then reconfigure the loop on the new element.
- You can’t loop whatever you want. You’re limited to looping approved elements. For example, you can’t loop images. In order to loop unapproved elements, you have to add a blank wrapper and loop the blank wrapper. This is a hassle and affects the code output on the front-end.
How Etch’s Loop element is better (strictly from an architectural standpoint):
- The Loop element in Etch is a blank canvas. You can put anything inside of it you want, in any structure, without limitation, and loop pretty much anything.
- You can safely drag things into and out of the loop without issue.
- There’s never an issue of “looping the wrong thing.” The loop is a ghost element that contains whatever you want looped and affects nothing else.
- The loop doesn’t output anything on the front-end. It doesn’t affect the DOM in any way, other than duplicating what’s inside of it. There are no extra wrappers required or forced on the user.
- You can freely use conditional logic elements inside of the loop. These are far superior and more flexible to how all other page builders handle conditional logic. And since the Loop element is just a ghost container, you can put the logic around things or inside of them — or both.
- Bonus: Etch gives you access to the full php configuration of the loop. You’re not limited to what’s available via the UI.
- Bonus: Etch gives you access to the HTML of everything in the loop, so there’s never any limitation as to what the loop output is, whether you’re editing tags, attributes, or content itself.
- Bonus: Etch will of course allow looping of posts, users, taxonomies, and even external data where most other loops are confined to posts, or just WordPress database items.
That’s a pretty short and fairly “non-technical” overview of why Etch’s Loop element is superior to how loops are technically architected in other builders.
If you still have questions, they’ll be answered by using Etch’s Loop element a few times. It really doesn’t get any easier or more powerful.