Anybody using any kind of page builder with sage am not asking about the main stream page builders i.e. elementor, visual composer, divi etc etc
I want my clients to be able to create pages for themselves as well calling pre-built blocks and components. at the same time i dont want the pages to be spammed with junk codes.
Anybody doing this already ? Does anyone know of any page builder boilerplate ?
Depending on the project I use Beaver Builder. It’s not the most semantic, and it writes a LOT of HTML, but it doesn’t use shortcodes and it’s very easy for non-developers to get the hang of. I’ve even trained clients on it.
No off-the-shelf page builder but I do build my own into most projects using ACF flexible content fields.
I build each of these out as reusable components and on templates where I allow the page builder, a client can go ahead and build their own mix-and-match set of components out for themselves.
@MWDelaney and @nathobson what do you guys think about the TypeRocket repo on github ?
sounds nice thats what i was looking for how do you go about it ?
That junk code is what i dont like 
and shortcodes arent that bad most builders use it but compared divi and visual composer elementor and bb is much better
I keep telling myself I’ll write up something about it but hard to find the time.
Esentially, create all the components as individual rows in the flexible content field. I then have a page-builder controller trait that can be included with any template’s controller. I then have a page-builder partial which is essentially just a foreach through each row of my page builder controller. I then load in another partial for each component based on the foreach matches. I also have a seperate SCSS file for each component.
I don’t think that makes much sense written down 
Let me try and write that up a little better.
Page builder controller trait
<?php
namespace App;
trait PageBuilder
{
public function page_builder()
{
// Get all page builder fields
$page_builder = get_field('page_builder');
// Set up array
$data = [];
// Loop through each block
foreach ($page_builder as $block) {
if ($block['acf_fc_layout'] == 'component_one') {
// Do any logic for this component here
$this_block = (object) [
'block_type' => $block['acf_fc_layout'],
'field_one' => $block['field_one'],
'field_two' => $block['field_two'],
];
array_push($data, $this_block);
} elseif ($block['acf_fc_layout'] == 'component_two') {
// Do any logic for this component here
$this_block = (object) [
'block_type' => $block['acf_fc_layout'],
'field_one' => $block['field_one'],
'field_two' => $block['field_two'],
];
array_push($data, $this_block);
}
}
$data = (object) $data;
return $data;
}
}
}
Page builder view partial
@foreach ($page_builder as $block)
@if ($block->block_type == 'compontent_one')
@include('partials.page-builder.component-one')
@elseif ($block->block_type == 'compontent_two')
@include('partials.page-builder.compontent-two')
@endif
@endforeach
Component view partial i.e. component-one.blade.php
<section class="component-one">
{{ $block->field_one }}
{{ $block->field_two }}
</section>
And finally I would have a corresponding component-one.scss file.
The above is cut down to a minimum without any checking etc. to just show the basic structure. I call them blocks in the above code for no good reason (slightly shorter I guess) but block == component 
Edit:
My next project is to break up the page builder trait as it can get kind of messy when there’s a lot of components with a lot of logic. The current method does lead to great tiny view partials and styles though and all the front-end code is the 100% your own 
This is some next level stuff am not really that competent 
Something like this heavily depends on the size of the project, and how well scoped the design is. I find often with smaller projects the design requirements are looser, making this method a bad fit for a few reasons.
But that’s just my experience with projects. This is a great method!
We keep our design process as:
Design -> Designs passed to dev team -> back to designers with dev feedback -> Implementation of dev feedback -> Repeat until signed off for build.
The dev team feedback is mainly to streamline how the website will be built and point out those small differences that will exponentially increase to project scope. By the time we come to build, we should have really already scoped out all components, post types, templates etc. We’ve also found that we can usually get away with far fewer templates i.e. a default template with a “page builder” that handles 95% of pages, then a few unqiue templates for the rest.
I’m jealous of your timeframes
You could just jump on the Gutenberg train a little early: https://wordpress.org/gutenberg/ Haven’t messed around with it myself, but ostensibly there’s a way to build/define your own blocks.
even i haven’t tried it yet let me check it out
Thanks for sharing. I am using a very similar method so it’s good to know that I am on the right path
I would just suggest to output template partials like this:
@foreach ($page_builder as $block)
@include('partials/page-builder/'.$block->block_type)
@endforeach
So you could avoid a ton of if statements. Of course, in this case your acf layout and template names should match. But you can use dashes for acf layout names as well so it’s not an issue.
Nice! I like that in principal, although I definitely would prefer my ACF layouts to be underscored for consistency elsewhere but that’s probably me just being pedantic
I’m curious about this as well. When using something like beaver builder, when does it start and end for something like sage? Are you only using it for page content?
Wherever you want. I’ve built sites where even the title section was a BB “saved row”, and I’ve also built sites where the BB part was confined to a container. and the header and footer were done with ACF or normal WordPress functionality.
It depends on the project needs, the client’s needs, and the designer’s ability to be specific.
Hey
Not sure if I understand this correctly, but does that mean that BB can be used in specific blocks, not just the main wordpress post editor? Let’s say I have rows of flexible content fields and I want one of them to be able to use beaver builder, is that something possible?
Thanks in advance
So you’ll actually use Beaver Themer?
How am I still leveraging Sage’s approach when I do this? Are there benefits to using Sage with Beaver Themer?