Visual Builder approach

[abmcr]

What you think about visual builder approach? in the wordpress ecosystem the Gutenberg project, the DIVI theme ecc are commons... for the client may be useful a toy as a visual builder... 
Thank you

[louisstephens]

You can achieve something (that I think is better) using a the Repeater Matrix (profield). I was actually playing with this the other day. I created several "blocks" ie image/text, quotes, slideshow etc etc and with very little effort (output styling not included) had a homepage built.

 

I like this approach better than Visual Builder as it allows the developer to have a bit more control of the output (styles/layout). In my experience, vb can lead to bloat, and a very fractured site structure. It also, at times, makes it difficult to find where pieces of the site are located.

[Christophe]

Hi,

I see that you asked a similar question in 2016:

Have you seen this topic (and the pages that it links to), for example?:

 

[abmcr]

41 minutes ago, Christophe said:

Hi,

I see that you asked a similar question in 2016:

 

 

Yes! But my question is not about Processwire and Builder (as Repeater Matrix), but in general talking about the approach of building website with page builder.

In processwire an approach like builder is made with repeaters etc... but i have interest about your opinion in builder approach

 

[qtguru]

1 hour ago, louisstephens said:

You can achieve something (that I think is better) using a the Repeater Matrix (profield). I was actually playing with this the other day. I created several "blocks" ie image/text, quotes, slideshow etc etc and with very little effort (output styling not included) had a homepage built.

 

I like this approach better than Visual Builder as it allows the developer to have a bit more control of the output (styles/layout). In my experience, vb can lead to bloat, and a very fractured site structure. It also, at times, makes it difficult to find where pieces of the site are located.

The correct word is all times, I haven't come across any site builder that allows 100% control over content without creating a mess or even without the need for code, the closest so far I can think of is October CMS which generates a templates from the frontend and allows you to tweak them, but it requires knowledge of Twig or blade (not sure), really this is an important topic you raised, I have a client i tried convincing to try Processwire, but the client wasn't interested in coding and wanted to builder to achieve all their needs. The only thing i can think of is a Builder 100% built around Processwire API(s) meaning, when they create a Page and add content and use modules from builder, at the backend it should replicate the same process like creating a template, downloading the modules but that will be a very difficult task to achieve. However I would be happy to hear what ideas you have and we can research further upon that. so far Processwire is the best CMS platform that's minimal and straight forward but for developers more.

ImpressPages comes close to what you have in mind, I will keep an eye on this thread and contribute should i have more information. If this can be achieved I think we can further push PW to clients and have them replace WordPress, at the same time we should be careful we don't create another WordPress in this ecosystem. what do you think ? 

[pwired]

Quote

for the client may be useful a toy as a visual builder... 

This subject seems to come back every now and then. When it comes to the client the backend of processwire is already easy enough to update for example text and pictures in the website of the client. So what do you mean by giving the client a toy as a visual builder ? Are you thinking of some kind of visual builder plugin or template for processwire ? How would that be possible to achieve without hacking the core of processwire with the use of some sort of shortcodes ? The client would only end up creating frankenstein websites like divi does.

[louisstephens]

9 hours ago, pwired said:

 The client would only end up creating frankenstein websites like divi does.

This has been my experience with a site I inherited (wordpress) that was using the Oxygen plugin. There are template partials stored under the plugin menu that you "call" from the visual builder (ie once you go to edit a page). It really became a nightmare on finding what parts were being used, and where all of this data was being housed in the backend.

Giving the client/user a way to drag/drop content seems nice, especially when you know the project is over. However, when you come back to it for any updates, the project has turned into a tangled mess with no map.

I do apologize if this has became a rant on Wordpress, as I still enjoy wordpress for blogs. It really comes down to having a nicely structured backend where it all "just makes since".

[dragan]

Yeah, similar experiences here. We have used a theme called The-7 (iirc) for 4 WP-sites.  The theme had half a dozen variations of everything: 5 different tab elements, 7 accordion types, x sliders/carousels etc. etc.

To ensure style consistency, we had to write a manual so authors could remember which items to choose and how. 

But tbh, I can fully understand why some ppl like such stuff. To most people, more is more.

[Pixrael]

I really need something like that many times. Perhaps a partial solution is a module based on Textarea that the Inputfield Type is an HTML editor with design blocks. I tried to develop one but since I'm not a "real" programmer, I could not make much progress.

Maybe someone who knows how to develop modules in Processwire can do it, it does not seem very complicated.

It was based on GrapesJS http://grapesjs.com/ an open source Javascript library and it is very easy to include it in a project https://github.com/artf/grapesjs#usage. 

Here you can see a working example http://grapesjs.com/demo.html, the library exports the HTML code that can be stored in the Textarea.

You just have to include the CSS that the frontend uses to make it work.

[Jonathan Lahijani]

Brain dumping here, but on one end of the spectrum, we have good-ole' templates, which is what ProcessWire is all about.

Then on the other end, we have these infinitely configurable, drag-and-drop page builders.  Popular ones include:

• webflow.com (arguably the most elaborate)
• grapesjs (looks like open-source webflow clone that they encourage CMS's to integrate)
• yootheme pro (a wordpress builder; Yootheme is the company that makes UIkit, so their approach particularly appeals to me since I'm all in on UIkit); it's interesting to see how a pure, truly inspired uikit builder would be imagined, and yootheme pro is it
• other wordpress builders: gutenberg, divi, beaver builder, + a million others

Of course, if you have a site that has highly relational data and templates, PW is perfect, but then there's those one-off pages, or sections within templated pages, that need the flexibility of a builder so the non-coder editor who's editing the page can do what he needs to do.

I think these builders need to take the end-user into consideration... with too much flexibility and an editor without a strong understanding of how they work, it's more likely the resulting builder page that has been created is going to be sub-par.  The images might be way too big, the fonts may be off, spacing, etc. etc.  Honestly, even when I as a web developer use those builders, it doesn't feel right, but perhaps that's because I'm totally biased.

I feel having a strong set of components/blocks that each have a bit of flexibility to them via various options is the better way to go if it makes sense for a site.  RepeaterMatrix does this perfectly and because it's through RepeaterMatrix, you can use PW's API to query things if need be.  The trade-off is doing column layouts is a bit trickier (not impossible), it's not 100% visual/drag-and-drop, and you have to create a defined list of blocks/components/matrix-types (which is another way of setting up some expectations of what is and isn't possible).

[grimezy]

I too was wondering how to best approach this, as I needed a base configuration that sped up the design layout for each template a client requested.  I just spent too much time on this than anything else.  Because I am a one man show, and this isn't my primary job, I finally think I found a happy medium, using the following:

A combination of using:

• One main template which is used to build any layout
• Repeater Matrix Fields as html blocks/containers, which build html code based on the UIKit v2 framework (grid classes, subslasses, etc...)
  • I tried to code in a function which uses the recent Item Depth settings for a Repeater Matrix field to know when to open and close div elements with levels of code blocks, but couldn't quite get it right, as my math and coding skills aren't that great yet, but if anyone manages to get something like this working, it would be great!  So instead I just created a bloated if else statement, but I still use the item depth feature to see how the blocks of code would be indented for easy readability within the backend.
• Backend templates for each widget, so I can add configurations and settings to each particular widget, and a way I could call this from a page reference field 
• A 'Page Reference' field to select which widgets I wanted to show in these containers.
• A 'Selector' field to target which pages these particular html blocks/containers should be visible.

I would love have this in some kind of installable module, but I'm just not skilled enough/don't have the time  I hope though that this has given someone an idea of how you can use the above combination to take the hassle out of building page layouts, without touching the front-end code continually 

I have attached a screenshot to make it a bit clearer on what I am doing... (or trying to do!)...

[maxf5]

I made this with Page Tables. It's not 100% perfect yet, but works for my demands

_init.php:

// Main Content
if ($page->views)  {

$content = "<div id='views' data-uk-grid-margin>";
$contentview = "";

foreach ($page->views as $view) {

  $typ = $view->template;
  $id = $view->name;

  $colxl = $view->colxl;
  $gridcountxl = $colxl;

  $colsm = $view->colsm;
  $gridcountsm = $colsm;

  $colxs = $view->colxs;
  $gridcountxs = $colxs;

  $fw = $view->fullwidth;
  $nmnp = $view->removemargin;
  $border = $view->hasborder;

  switch ($typ) {

    case "Text":
        $text = $view->textfield;
        $ct = "<div id='{$id}' class='uk-width-small-". $colxs ."-12 uk-width-medium-". $colsm ."-12 uk-width-large-". $colxl ."-12'>$text";
        $ct .= checkGrid($gridcountxs, $gridcountsm, $gridcountxl);
        $ct .= "</div>";
        $contentview .= fullWidth($fw, $cv=$ct, $nmnp, $border);
        break;

    case "SlideGalerie":
        $bilder = $view->images;
        $sg = "";
        $sg .= "<div id='{$id}' class='product-gallery views owl-carousel owl-theme'>";
        foreach ($bilder as $b) {
          $bbig = $b->width(1920, $options);
          $bsmall = $b->size(485,325, $options);
          $bretina = $b->size(970,650, $options);
          $sg .= "<div class='g-item'>";
          $sg .= "<a href='{$bbig->url}' data-uk-lightbox=\"{group:'{$view->name}'}\">";
          $sg .= "<img data-src='{$bsmall->url}' data-src-retina='{$bretina->url}' class='owl-lazy' alt='$b->description'>";
          $sg .= "</a>";
          $sg .= "</div>";
        }
        $sg .= "</div>";
        $sg .= checkGrid($gridcountxs, $gridcountsm, $gridcountxl);
        $contentview .= fullWidth($fw, $cv=$sg, $nmnp, $border);
        break;
  
  	// Case .. Case .. Case ..


}
$content .= $contentview;
$content .= "</div>";
}

 

_func.php

/**
 * @param string $gridcountxs
 * @param string $gridcountsm
 * @param string $gridcountxl
 * @return string
 */
function checkGrid($gridcountxs = '', $gridcountsm = '', $gridcountxl = '')
{
    $out = '';

    if ($gridcountxs >= 12) {
        $out .= "<div class='uk-clearfix uk-visible-small'></div>";
    }

    if ($gridcountsm >= 12) {
        $out .= "<div class='uk-clearfix uk-visible-medium'></div>";
    }


    if ($gridcountxl >= 12) {
        $out .= "<div class='uk-clearfix uk-visible-large'></div>";
    }
    return $out;
}


/**
 * @param string $fw
 * @param $cv
 * @param string $nmnp
 * @param string $border
 * @return string
 */
function fullWidth($fw = '', $cv, $nmnp = '', $border = '')
{

    if ($nmnp) {
        $nomargin = 'uk-margin-top-remove';
    } else {
        $nomargin = '';
    }

    switch ($border) {

        case '1':
            $b = 'border-top';
            break;

        case '2':
            $b = 'border-right';
            break;

        case '3':
            $b = 'border-bottom';
            break;

        case '4':
            $b = 'border-left';
            break;

        case '5':
            $b = 'border-all';
            break;

        default:
            $b = '';
            break;
    }

    $fout = '';

    if ($fw) {
        $fout = "<div class='full-width " . $nomargin . " " . $b . "'>" . $cv . "</div>";
    } else {
        $fout = "<div class='uk-container uk-container-center uk-margin-large-top " . $nomargin . "'><div class='uk-grid " . $b . "'>" . $cv . "</div></div>";
    }
    return $fout;
}

 

 

[WinnieB]

Interesting topic. From my experience using the Gantry framework with the Grav flat-file CMS, the extra level of "ease"/abstraction visual builder tools offer can be a hassle when things don't work 100% as expected (which is at least 50% of the time).

It gets complicated if the builder magically (meaning in ways not well-documented) overrides standard settings that are documented in the CMS itself but are suddenly not working.

That said, building your own within PW to speed workflow with clients a la @grimezy / @maxF5 makes a lot of sense.

[SubMon]

I agree that page builders are not something you usually want to hand off to a client. However, I have found the new crop of WordPress Page Builders to be useful even as someone who codes. Namely, in circumstances when budgets are limited and quick landing page iteration is necessary. If I want to change a section from 2 to 3 columns or insert a call to action block with a different image size, a decent page builder allows me to do it without diving back into the template. It saves me time as long as I can work within the constraints. In other words, a Clickfunnels-Squarespace interface (these builders are better than both of those) have their place—at least in my world.

That being said, I'd always rather use ProcessWire over WordPress. I wonder if one of the 3rd party page builder developers could be wooed to port to ProcessWire? Check out Elementor: https://elementor.com/  Brizy and Divi look decent as well.

What do you think?

[pwired]

Quote

It saves me time as long as I can work within the constraints.
What do you think?

A page builder injects both JavaScript and CSS files => additional loading time.
A page builder doesn`t take image and header tags into consideration => negative impact on SEO.

A page builder injects its own set of shortcodes
Have you seen the code that divi and other page builders are creating ?

It happens out there that the coder who has set up the website, in time will not be available
for the client anymore. Would somebody else in the future want to maintain such code ?

Reverting might leave you with styling issues as you most likely have to manual delete all shortcodes.
Good luck with that.

 

[dotnetic]

@SubMon @pwired Did you see 

 yet? Take a look at the video. It seems to become a nice page builder for ProcessWire.

[SubMon]

13 hours ago, pwired said:

Good luck with that.

Thanks pwired. Of course, your right that Page Builders have several downsides. I know I'm not exactly an active member of these forums, but I think I have a perspective that could be useful to this discussion. I am not advocating for PW to go this route. Just trying to highlight that there is a valid use case—those in which loading time and future proofing is not your top priority (everything can't be number 1)—and show Builders that are doing it well.

[SubMon]

@jmartsch

Yes, it's intriguing. But if I understood it correctly, it's for the admin, not the front end display. Back end builders can be great and I've always liked the PW appreach. They allow designers to control design and editors to control content. That's not the same though as what has really taken off over the last couple years in WP world. Which is a truly WYSIWYG front end builder which is also not ideal for many situations but is ideal for certain situations. Not saying PW necessarily needs something similar.

[OLSA]

Hello for all,

my opinion about integration of some popular "page builders" into PW is not a good option. All respect for developers, but "page builders" are like a "box" with "toys" inside of it. Problem is that every website is different and very soon you would noticed that you need to prepare some new element because you don't have it in a "box".

Before few days I find some page builder with 170 predefined blocks, but noticed that there were not blocks what I needed for my last project (demo, slow host). Inside "box" with 170 content blocks were not any with "large text in the corner of the frame".

I believe that right solution are tools for building "page builders" right on place, and that is why PW profields (Repeater Matrix Fields) are good option (or my custom what I had made before few years, part of it is here). 

I really like to hear new ideas to make things better but I am sure that integration of popular page builders are not a way to go.
Regards.

[teppo]

On 8/6/2018 at 11:34 PM, SubMon said:

I agree that page builders are not something you usually want to hand off to a client. However, I have found the new crop of WordPress Page Builders to be useful even as someone who codes. Namely, in circumstances when budgets are limited and quick landing page iteration is necessary. If I want to change a section from 2 to 3 columns or insert a call to action block with a different image size, a decent page builder allows me to do it without diving back into the template. It saves me time as long as I can work within the constraints. In other words, a Clickfunnels-Squarespace interface (these builders are better than both of those) have their place—at least in my world.

That being said, I'd always rather use ProcessWire over WordPress. I wonder if one of the 3rd party page builder developers could be wooed to port to ProcessWire? Check out Elementor: https://elementor.com/  Brizy and Divi look decent as well.

What do you think?

I agree that there are valid use cases for page builders. In fact some of the biggest projects I've built on top of ProcessWire have utilized some form of that. Not just for fast mockups, but also because these sites often have hundreds or thousands of pages with varying layouts, meaning that a predefined fields approach would become a hot mess of dozens or even hundreds of separate templates and fields. That's simply not feasible.

Regarding the idea of porting one of those tools to ProcessWire... if you're talking about a direct port, so far I'm not convinced. Elementor advertises itself as the only fully free and open source editor, and if that's true, then it's the only one we could port, and even then we'd have to convert a lot of WP specific code over. Elementor consists roughly of some 20k lines of JS, 20 external JS libraries, and plenty of PHP on top of that.

In short it would be a massive project, and maintaining such a fork would be a full-time job. That being said I haven't had a closer look at the Elementor JS part, so it may be more portable than I currently think – but considering that it probably wasn't designed with portability in mind, that seems unlikely ?

If only there was some sort of a CMS agnostic page builder framework, that'd be awesome ?

[teppo]

By the way, since we're talking about page builders, I assume that everyone here is already familiar with Gutenberg?

If not, in a nutshell it's a flexible and extendable (new custom blocks can be registered by third party plugins) page builder developed by core devs as an official alternative (and perhaps at some point in the future as a full replacement) for the current WP editor interface (which is essentially a customized TinyMCE field).

Gutenberg has caused a bit of turmoil among the WP folks, with some considering it the best thing that has happened to WP and others wishing that it would just go away. Personally I think that it's a brilliant move from the core devs, and fits the WP ecosystem like a glove – not to mention that it has already spawned an entirely new category of third party plugins (Advanced Gutenberg Blocks, Stackable, Atomic Blocks, and so on).

In other words it seems that the WP core devs are taking the page builder approach very seriously, while other approaches – such as custom fields and content types – remain in the realm of third party plugins.

[szabesz]

5 hours ago, teppo said:

I assume that everyone here is already familiar with Gutenberg?

There is one big issue with page builders: working with them can still be time consuming depending on the use case, quote:

Quote

Having to split blocks up and define blocks to be a whole new type is the most painful process.

Realising text as one type of block, or text already inside a block needs to be a different type of block is just crazy.

Oh …. need an image in the middle of a text block … grunt. Create new text block, copy paste the first part of the text into the new text block, insert the image block.

Oh … I needed the image one sentence further down. Old way – cut image paste where I want. Takes about a second. Now … copy paste text from one text box to the adjacent one – select text carefully to get the right bit – this is much more time consuming if you have to do it four or five times in a row. If there is a better way … I don’t see it (unintuitive).

source: https://wordpress.org/support/topic/i-was-really-ready-to-give-this-a-good-shot/
https://wptavern.com/gutenberg-plugin-garners-mixed-reactions-from-new-wave-of-testers

Being a designer I can cope with any page builder for sure, but lots of editing tasks are even more time consuming that way. A page builder and a rich text editor both have their shortcomings and strengths, none of them is superior to the other. For example, my current clients would have a hard time working with page builders, as they only need simple RTE features and do not want to "learn more than that" for sure.

Edited August 15, 2018 by szabesz
typo

[pwired]

LoL why not move over to wysiwyg site builders so clients have all the easy page building they want.

[teppo]

On 8/15/2018 at 2:39 PM, szabesz said:

There is one big issue with page builders: working with them can still be time consuming depending on the use case, quote:

source: https://wordpress.org/support/topic/i-was-really-ready-to-give-this-a-good-shot/
https://wptavern.com/gutenberg-plugin-garners-mixed-reactions-from-new-wave-of-testers

Being a designer I can cope with any page builder for sure, but lots of editing tasks are even more time consuming that way. A page builder and a rich text editor both have their shortcomings and strengths, none of them is superior to the other. For example, my current clients would have a hard time working with page builders, as they only need simple RTE features and do not want to "learn more than that" for sure.

Absolutely. The best approach depends entirely on the needs of a specific project and client ?

For an example, while (re)building a large news site some time ago we first considered going with a page builder, but in the end implemented a single RTE field for the main copy of each article, with some minor layout customisations. The thing is that their old system was based on blocks, and one particular pain point with that was that since the authoring process itself relies on producing the whole text as a single document, it had to be manually split for the site.

It's also true that new tools tend to require some getting used to. That first review is a good example of this: when you've had 15 years to get used to doing things in a specific way, migrating to a new set of tools can feel rather awkward. I'm not saying that Gutenberg is the "perfect" page editor, but it's not necessarily quite as bad as that text makes it seem:

"Oh …. need an image in the middle of a text block … grunt. Create new text block, copy paste the first part of the text into the new text block, insert the image block."

Actually you can just move the cursor to where you want the image, hit enter to create a new empty block, and then insert an image. Or you can insert the image right into the paragraph block if you want it inline with the text.

"Oh … I needed the image one sentence further down. Old way – cut image paste where I want. "

In this case you have a couple of options: click the arrows next to the image block to move it up or down, drag it where you want it, or copy and paste it to the right position. Admittedly the work in progress state of Gutenberg shows here: while "copy" already works, "cut" doesn't, so there's an extra step of deleting the old image. It is still a beta version, so I'd cut them some slack ?

On 8/15/2018 at 2:52 PM, pwired said:

LoL why not move over to wysiwyg site builders so clients have all the easy page building they want.

In my opinion a true professional is able to choose the best tool for the job, thus avoiding a cognitive bias commonly known as "the law of the instrument" (or "the law of the hammer"). If I run into a project where the client clearly needs a page builder, then that's what I'll use.

The great thing about working with a system like ProcessWire is that we have so many options: one can implement a page builder together with a set of template specific predefined custom fields and all the benefits that come from being able to precisely define content hierarchies and URL structures.

In other words it's all about having options – and of course having an open mind when it comes to exploring potential new solutions ?

[dragan]

It all depends. For some sort of projects, where you really need to have structured data (e.g. Skyscraper profile, or real-estate listing / database-like sites), a visual builder would do nothing for you, or your clients.

otoh, for stuff like huge immersive storytelling sites, it's certainly a dream come true. (you know, stuff like this)