I would like to see better integration with Pods (especially in terms of repeater fields), like what is available with the ACF integration which is much more “seamless”.
It’s also necessary to write custom query code to get data from simple Pods relationships. Again, this could be made easier in the builder.
Hi Jamie,
Thank you for submitting your ideas to the idea board. The ideas will be reviewed at irregular intervals. However, the focus is currently on Bricks 2.0, which will already contain many new, extensive features. After that, we will certainly get back to work on new ideas to make Bricks better bit by bit
Hear hear – I much prefer working with Pods over ACF (ACF is so intrusive on a site unless you upgrade to the paid version… and just feels bloated, to me anyway).
Thanks so much for your consideration I look forward to seeing what you might come up with on this front!
@John.R Last time I checked, ACF free had fewer field types than Pods. No idea about SCF, except it left a bitter taste for everyone who followed how it came to be. It’s also a fork of ACF free, not pro.
It’s a common misconception that SCF is a fork of ACF Free. SCF is actually a fork of ACF Pro, with all Pro features available freely and without restrictions.
As for the “bitter taste,” people naturally took sides during that episode—but that’s noise.
The substance is that SCF, a full-featured, no-upsell fork of ACF Pro, is now maintained by WordPress.org.
That’s why I found it curious that some would still choose Pods over SCF today.
@John.R I didn’t keep up with the noise, but initially SCF was a straight copy/takeover of ACF free. Maybe they also ripped off the pro features by now too. Assuming they have, I don’t know how stable or compatible those features are.
Either way, it’s off topic. Bricks bills itself as having seamless integration with Pods when it doesn’t, and that’s what I and many others would like to see.
Just to clarify—SCF was never a “ripoff” of ACF Free. It was a direct fork of ACF Pro, reconstructed from the publicly available GPL-licensed source. One could call it a fork, a clone, a ripoff, or a lift—but under the GPL, it’s all perfectly legal and entirely legitimate.
Forking is a long-established and accepted part of software development—from the early days of Linux to countless modern examples. It’s how open ecosystems evolve.
Whatever view one takes on how SCF came to be, the end result—as of March 2025, when SCF came out of beta—is both legally sound and technically solid.
In any case, I understand now that for some, the preference for Pods goes beyond features—it’s philosophical. And that clears up my earlier curiosity.
Worth clarifying: under the GPL, removing branding or copyright attribution in the code is permitted—as long as the license terms are preserved. It’s not a gray area; it’s explicitly allowed. That’s what makes forks like SCF possible in the first place. That said, the March 2025 release that came out of beta restored attribution in the code—likely to appease the fence-sitters.
As for the timeline—there’s no point in re-litigating the project’s early direction. It evolved.
What matters now is that the current SCF is a fully featured, free fork of ACF Pro maintained by DotOrg.
That’s the version in active use, and the basis of the discussion and my curiosity today.
@John.R This is a rather long way of agreeing with what I said a few posts ago - the initial SCF was a direct copy of ACF free (sans attribution). At that time, Pods free still offered more field types than ACF/SCF.
I didn’t know that the “new” SCF later became an ACF pro ripoff because I had no interest in followings SCF development.
I still would rather use Pods - the same as others prefer JetEngine, Meta Box, Carbon Fields, Toolset.
Fair enough—we’re aligned on the early history. Yes, the initial SCF closely mirrored ACF Free, and Pods had a broader set of field types at that point.
I highlighted that the current SCF (post-March 2025) isn’t just a continuation of that—it’s a full-featured fork of ACF Pro, available for free and maintained under WordPress.org. That shift materially changed its position in the landscape.
As for tool preferences—completely valid. JetEngine, Meta Box, Carbon Fields, Toolset… each has its own design philosophy and user base, and many are priced below ACF Pro to appeal to budget-conscious users.
My curiosity was specifically about why some still prefer Pods over SCF, now that SCF offers ACF Pro-level capabilities without the paywall. I now understand—and as I acknowledged earlier—it’s philosophical.
@John.R Partly philosophical, partly that Pods is already in use on some projects (and there’s a familiarity with it - also not sure what the migration process looks like), partly I didn’t know that they added features from ACF Pro (curiously, the posts I read suggested that this was largely unpolished at first which is odd if they cloned it). Also, what does the feature support look like between Bricks and what is now SCF in terms of the newly added “pro” features.
Of course—for legacy projects already using Pods or similar CPT plugins, migration can be tricky. But for new projects, SCF is quite appealing.
It’s a clone of ACF Pro, so for users familiar with ACF, the transition is seamless. That said, for some, the reluctance is still philosophical.
Can’t speak for Bricks, but it’s worth testing directly.
To me, it’s a case of: while the two tigers fight, the fox runs off with the kill. SCF is the kill. And if someone trusts WordPress from DotOrg but questions SCF—well, that’s one strange fox.
