Page Builder

[kongondo]

Here is the first very early concept of a Page Builder. As per the conversation in the 'ProcessWire beyond 2021' conversation, I set myself a challenge to make a clone of YOOtheme Pro's Page Builder. This was mainly spurred by @Jonathan Lahijani's excellent overview of ideas of a page builder for ProcessWire.

This is still in very early stages and I am not really sure where it is headed. I would like to hear the thoughts of like-minded persons ?. I would especially love to hear from @Jonathan Lahijani, @szabesz, @AndZyk and @flydev ?? please.

Concept

The page builder in its current state is a Fieldtype + Inputfield supported by other behind-the-scenes Fieldtypes without Inputfields. 

• There are no hidden or extra pages in contrast to Repeater Matrix.
• All values are stored in the Page Builder fields for the page being edited.
• The fields do not store values as JSON.
• Definitions for elements, rows, grids, etc as stored as JSON.
• Currently, for storage purposes, 4 datatypes are supported - Text (HTML), images, plain text and headlines. From a storage perspective, the latter two are one and the same. Just texts with different 'schemas/definitions'. More on this below.
• The fields are multitype fields. This means one page can hold multiple texts, allowing for repeatability.
• Similar datatypes are stored together in one field/table. For instance, there is no reason why a (future) URL element (datatype) should not be stored in the same table as plain text. At the database level, they are both just texts with similar requirements. At the processing level, URLs vs other plain texts (headlines, etc) are handled differently (validation, sanitisation, etc). 
• Each 'element' represents a row in a table for most types (e.g. slideshows are slightly different).
• Querying and access of field values is via the main Fieldtype - FieldtypePageBuilder. However, the supporting Fieldtypes can be also be accessed and queried individually, if one wishes, using normal ProcessWire selectors.
• The supporting Fieldtypes, if such need arises could easily become custom tables instead (but best to keep them as Fieldtypes - easier querying with selectors, etc).
• It is totally CSS-agnostic in relation to frontend output. You bring your own CSS. In the preview, you can also use your own CSS.
• In the frontend, you can choose to output raw values as you wish or use inbuilt render methods to render the whole layout for you or to render the value of an element as per its tag definition (e.g. headlines as h2, h4, etc) where applicable. 
• Fully multilingual (although the editing UI not yet implemented).

Issues

The main issue is the real estate needed for InputfieldPageBuilder. Any such page builder would require the whole width of the window. As you can see from the screenshot below, this obviously throws things out of kilter with respect to the ProcessWire page edit UI, in any theme (I believe). I am not a designer so would love to hear from you about possible solutions. My current thoughts are:

Modal

Open the page builder in a modal for editing.

Pros

• Would allow for use of whole real estate.
• Title and other fields would not be in the way.

Cons

• Editing in modals can be tricky?
• Other..?

Process Module

Pros

• Solves the real estate issue.

Cons

• Disconnect between the page being edited/created and the page tree.

Screenshot

No attempt has been made to theme it as per any current ProcessWire theme (that I know of). This was a quick and dirty-ish clone of YTPB. As stated, however, the current ui is not acceptable as an Inputfield for, mainly, real estate reasons.

 

Video Demo

This is a demo for the Page Builder app outside ProcessWire.

Thoughts? Thanks.

PS: I currently have no time to continue working on this (Padloper, etc..)

 

[gornycreative]

I saw this video pop up in my feed, and I was really happy to see it as there are folks who are comfortable with this way of managing content.

Very exciting project!

[Jonathan Lahijani]

WOW!  This is incredible!  I think this idea really has legs and you've proven it can be done in a ProcessWire way.

I would like to contribute in any way I can... ideas, styling, testing, financial.  I would 100% use this on multiple projects if it could be developed further.

I hope you are able to see this project through as well as Padloper.  Please let me know how I can help.

 

[kongondo]

2 hours ago, Jonathan Lahijani said:

I would like to contribute in any way I can

Thanks Jonathan. I'll be in touch soon.

[teppo]

Hey @kongondo! I know this project is at a very early stage, but it does seem promising. I also like your ideas about the data structure, though I'm not entirely sure I fully get it yet (might require a more hands-on example of the data vs. schema vs. database structure part).

At this time I really only have one question: do you currently see this as a potential commercial module, or something that you would consider open sourcing? I get that it's very early, and I want to stress that there's absolutely nothing wrong if you think it'd be better suited for commercial release. That being said, I see this kind of tool as a pretty massive undertaking, and thus something that could benefit from larger community involvement. I for one would definitely be interested in contributing in some way, assuming that would be an option.

Anyway: a very interesting project — keep up the great work! ?

Quote

The main issue is the real estate needed for InputfieldPageBuilder. Any such page builder would require the whole width of the window. As you can see from the screenshot below, this obviously throws things out of kilter with respect to the ProcessWire page edit UI, in any theme (I believe). I am not a designer so would love to hear from you about possible solutions. My current thoughts are:

Just wanted to point out that I don't really see this as an issue.

If we take WordPress as an example, they've always had UI's that (for similar reasons) step out of the regular Admin: Customizer from the core, for an example, as well as various plugins (Ninja Forms has a very distinctive full page form editing GUI), and in my opinion that works just fine.

[bernhard]

This does really look great in many ways! I guess you are using https://grapesjs.com/demo.html for all that client side magic?

When playing around with the demo my first thought was: Wow, that's brilliant and opens up so many possibilities and can solve so many client needs. Then I copied one person of the team:

Also great. But the problem here is that we totally lose the content management part of ProcessWire - or am I wrong in this assumption? Jessica White is just some kind of text. Dead data. Like a Word document. What if Jessica White married - we would have to change her name on all of our pages where we have placed such a block, right? Using ProcessWire fields on the other hand we might have used ASMSelect to choose from a list of persons in the system and so we could do changes in one central place.

I've never worked with grapejs, so my question is: Can we combine both worlds? Have a flexible layout builder on the one hand and have it use smart CONTENT of our page on the other hand?

Thx for your effort on this! ? 

[kongondo]

10 hours ago, teppo said:

At this time I really only have one question: do you currently see this as a potential commercial module, or something that you would consider open sourcing? I get that it's very early, and I want to stress that there's absolutely nothing wrong if you think it'd be better suited for commercial release. That being said, I see this kind of tool as a pretty massive undertaking, and thus something that could benefit from larger community involvement.

Hi @teppo. This is a holding response since I am short of time at the moment. You've raised an important issue surrounding funding of modules/remunerating developers, etc that I have been meaning to discuss in the beer garden with the whole community. As it is a broad issue, I would like to answer this question within that broader context. As for this module in particular, I haven't decided yet but leaning toward commercial. That's not cast in stone though given the broader issues I'd like to discuss.

10 hours ago, teppo said:

though I'm not entirely sure I fully get it yet (might require a more hands-on example of the data vs. schema vs. database structure part).

I had a feeling this would cause some confusion. I will come back with a detailed answer. For now, just note that schema is used in the sense of defining something, in this case, a column in a DB table containing JSON with the schema/description of that element with respect to layout, tags, etc. Hope I haven't confused you further.

10 hours ago, teppo said:

I for one would definitely be interested in contributing in some way, assuming that would be an option.

Excellent! Thanks.

[kongondo]

7 hours ago, bernhard said:

I guess you are using https://grapesjs.com/demo.html for all that client side magic?

Nope ?. This is all handcrafted using Vue JS + TailwindCSS + custom JS + some drag and drop library. I sometimes use vanilla JS for drag and drop but didn't this time. I have never used grapejs.

7 hours ago, bernhard said:

But the problem here is that we totally lose the content management part of ProcessWire - or am I wrong in this assumption?

You are wrong in your assumption ?..., at least in the context of what I am developing here. We are managing content; we are just not using "traditional ProcessWire inputfield interfaces". The app runs in __render() method of the inputfield. Saving is via ajax but that can be changed to form submissions with page reload if one wanted to (not that I would want to do that myself).

All my responses below are with respect to this Page Builder.

7 hours ago, bernhard said:

Jessica White is just some kind of text. Dead data. Like a Word document.

Wrong again. Jessica White's data actually lives in the database.

7 hours ago, bernhard said:

What if Jessica White married - we would have to change her name on all of our pages where we have placed such a block, right?

Still wrong. Jessica's marital (or any other of her attributes) status lives in the database. It is retrievable via the API and editable in the app GUI...all the CRUD goodies. You update it once and it is reflected everywhere that data is used, both live as you are editing and once you save your edits.

7 hours ago, bernhard said:

Using ProcessWire fields on the other hand we might have used ASMSelect to choose from a list of persons in the system and so we could do changes in one central place.

That's what is happening in this builder as well. You can choose anything. Literally, anything from the system. It's just a matter of requesting it via the API and getting back a response from the server ?. It's not shown in my demo but you can even do Page Reference fields. All data requests by the App request are vetted on the ProcessWire side (permissions, validation, sanitising, etc).

7 hours ago, bernhard said:

I've never worked with grapejs, so my question is:

Neither have I but it looks like your brief experience with it wasn't great? Maybe it was a misconception? A quick Google search tells me grapejs can work with a database backend. 

7 hours ago, bernhard said:

Have a flexible layout builder on the one hand and have it use smart CONTENT of our page on the other hand?

We can and we do....? Examples include Padloper 2, this Page Builder and other Vue JS apps I have built (unreleased). By smart content I assume you mean data stored in the database, be it in ProcessWire fields or custom tables. All the data you see in the demo of this Page Builder are stored in ProcessWire tables (Fieldtypes). You can access this data using the API and carry out any CRUD task using the usual ProcessWire API.

 

Edited January 22, 2021 by kongondo

[bernhard]

Crazy ? Thx for the clarification!

[Jonathan Lahijani]

I like the idea of editing in a modal (full screen to where it almost feels like its own page), or perhaps a dedicated edit page outside of PW's page editor.  I think having it inline as shown in the screenshot looks bad, not to mention the lack of page width.  If going the modal route, the "esc" key should not close the modal, but maybe a close button that the user has to click.

Also, I would imagine the icons are copyright YOOtheme, but this library is available for commercial use for free and a quick look seems to show they have similar icons:
https://github.com/vaadin/vaadin-icons

Edited January 22, 2021 by Jonathan Lahijani
added icon library

[kongondo]

18 minutes ago, Jonathan Lahijani said:

Also, I would imagine the icons are copyright YOOtheme, but this library is available for commercial use

Definitely ?. This was for demo purposes only. My plan is to develop my own using Affinity Designer...at least the easier ones. However, I don't know how much different I could make them look compared to YOOTheme's. 

18 minutes ago, Jonathan Lahijani said:

https://github.com/vaadin/vaadin-icons

Thanks. Will have a look.

 

By the way, I have been keeping an eye on this one:

https://heroicons.com/  ...by the folks at TailwindCSS

Edited January 22, 2021 by kongondo

[OllieMackJames]

@kongondo, Great proof of concept!

I would like to make a case for going the open source route with this and making this a group effort.

Reason being that this is a massive undertaking.

I recently decided to get a one year subscription to https://thrivethemes.com/ and to be honest I hate working with it, it is buggy, sometimes things save, other times they do not.

But I do like the conversion focused page builder aspects of it.

AND, what I also like is how this one guy who started it, now has a base of tens of thousands of customers.

And the company now has close or more than 70 people working there.

Why do I say all of this?

Because years ago already I bought padloper, never used it because it is nowhere close to what I needed or need.

Then on september 3rd 2018 I saw kongondo taking over, kudos to you I thought and still think.

But over time I became worried more and more, because dates kept on moving away further, then on november 29 2020, I saw the post stating that padloper 2 alpha might be released Q1 to a closed base of alpha testers.

Q1 2021 is now more than 2 years later than 2018 for a functionality that is key to broader adoption of something as great as PW.

IMHO PW needs a good shopping solution yesteryear already.

Just like I believe a good PW page builder is needed yesteryear also.

There is a huge market out there, now going for products that have IMHO a far inferior engine underneath and are buggy to work with.

Then if I see the smarts of the people now sharing stuff on this forum I have hopes that this can be turned into something made by people combining forces and getting a MVP out there asap, and then build on that to get fast iterations of minimum viable productversions.

On one of my sites: https://www.backpaingoodbye.com/ @netcarver built all different blocks with repeater matrix, and it is a joy to work with already, and IMO the page builder could go the route of pre-made blocks that serve a specific conversion focused purpose on pages.

If thrivethemes can build a base of customers around a page builder for wp, don't you guys think we could do better with a superior engine underneath?

And don't you think it is too much for one person to take on?

I am not a coder, but I could think of a business model where together we build the best page builder for websites for people that want their sites to generate results.

The examples are out there, often buggy, yet making their makers lots of money, mind you I am NOT focused on the money side, but PW is such a dream to work with compared to the other stuff, so why not turn that dream into reality together, AND support our businesses as well.

Proof of concept of business model?

- subscription based conversion optimised page builder driven by the best engine under the hood

- timebased and royaltybased payments to building participants, both coders, marketeers and ???

- a transparent website with access to all participants to see income streams and honest value add based division thereof

- allow participants to create derivatives for their own projects

@kongondo, I hope you do NOT see or take this as criticism...

....firstly it is not meant like that, on the contrary, you deserve a righteous applause for your taking on padloper on your own. I look forward to it going live.

...secondly, this processwire tribe is not a tribe where we criticize each other, but help each other reach unseen heights, at least that is how it feels to me.

So once again, if any of my wording sounds like it is criticism, please excuse me for being Dutch

Thanks and kudos to all you processwire lovers and ninjas from a Dutchman who loves this thing called Processwire!

[alejandro]

This seems great.

About a year ago I left PW to retake the WordPress route. I really love PW but I am a designer and I found myself spending more and more time around code, not just HTML or CSS, but PHP and JS, which is interesting to just a certain amount for me. I even developed some kind of blocks using repeater fields but I am no developer, at all, and it was messy. In WP you can find, as you all know, all sorts of builders and plugins and services, so you can be a web designer and create almost anything barely touching any code. But then you find something that should be easy, for example a grid of custom post with custom fields, and it becomes rather comples and/or expensive. Then I miss PW so much, all things pages, so easy.

Please dont consider this comment another rant PW vs WP, just a bit my background, I hope useful in this thread.

I think a module like this could greatly expand PW user base (don´t know if this is needed) beyond what I think is mostly developer users.

 

[Nicolas]

On 1/22/2021 at 8:43 PM, kongondo said:

Definitely ?. This was for demo purposes only. My plan is to develop my own using Affinity Designer...at least the easier ones. However, I don't know how much different I could make them look compared to YOOTheme's. 

Thanks. Will have a look.

 

By the way, I have been keeping an eye on this one:

https://heroicons.com/  ...by the folks at TailwindCSS

This iconset might be of interest for you as well : https://tablericons.com/

[horst]

9 hours ago, Nicolas said:

This iconset might be of interest for you as well

Another candidate can be https://feathericons.com/

But when inspecting the svg code of the arrow-up in a circle from all three icon sets it comes out that they use very different number of chars:

// Heroicons: 239 chars
<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke="currentColor">
  <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 11l3-3m0 0l3 3m-3-3v8m0-13a9 9 0 110 18 9 9 0 010-18z" />
</svg>

// Feather icons: 365 chars
<svg xmlns="http://www.w3.org/2000/svg" class="feather feather-arrow-up-circle" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
  <circle cx="12" cy="12" r="10"></circle>
  <polyline points="16 12 12 8 8 12"></polyline>
  <line x1="12" y1="16" x2="12" y2="8"></line>
</svg>

// Tabler icons: 453 chars
<svg xmlns="http://www.w3.org/2000/svg" class="icon icon-tabler icon-tabler-arrow-up-circle" width="44" height="44" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" fill="none" stroke-linecap="round" stroke-linejoin="round">
  <path stroke="none" d="M0 0h24v24H0z" fill="none"/>
  <circle cx="12" cy="12" r="9" />
  <line x1="12" y1="8" x2="8" y2="12" />
  <line x1="12" y1="8" x2="12" y2="16" />
  <line x1="16" y1="12" x2="12" y2="8" />
</svg>

So in regard of file size and data compression the winner is Heroicons. 

The number of icons in Tabler is nearly 1000, Feather has 280 and Heroicons 220.

And when it comes to design, ... well, thats purely personal opinion. ?

 

[AndZyk]

Sorry for my late response, I am more interested in other things right now. There are some great discussions about layout builders at the moment, that I have to catch up and I find it great, because all those new API methods and modules are great, but for me more important is how content can be more flexibel for clients. ?

Since you want to here my opinion on this topic:

This demo is looking great for a proof of concept and funny thing is, that I had to work with the YOOtheme builder on a WordPress website a month before and thought myself: This is a nice layout builder. Especially how you can make new sections with grids, duplicate them and so on. And all with a live preview. ?

One downside was, that you have some many options in the YOOtheme builder to build your own layouts, that it can be confusing some times and you have to search for a few minutes.

As for your proof of concept: It is really nice, but if the data would be stored only in the module, I would not use it. Because if something changes in ProcessWire (maybe in version 4) or you would not update the module anymore, I would have to migrate tons of data in the core fields again. I try to build websites with core fields only, that are still working in years and I had to work with projects before, where everything was build around a module that didn't got support be the third-party developer anymore.

If it would be possible to combine the power of ProcessWire and its custom fields inside a layout builder field, where the data still would be there without the layout builder field, that would be awesome. So the layout builder would just be an enhancement of the existing structure, instead of the whole structure.

I think I will wait for Ryans take on this and you are probably still busy with Padloper 2, but thank you for this proof of concept. It is nice to have people like you, that are driving ProcessWire forward. ?

Regards, Andreas

[Schwab]

Hey guys

I wanted to ask what the state of the Page Builder is. I had the same thought a Builder would be great for the accessability of ProcessWire to more casual or professional users.

I doesn't make sense though to invest a lot of time programming such a thing, when someone else is doing it already.

Regards, Simon

[kongondo]

On 10/2/2021 at 8:54 AM, Schwab said:

I wanted to ask what the state of the Page Builder is.

Hi Simon,

Apologies for the late response. I haven't touched this since I built the prototype. I think the Page Builder conversation isn't finished yet. Some of the pending discussion IMO are:

1. What type of Page Builder do people want? E.g. drag and drop with visuals, repeater-like-builder, etc.
2. Technical aspects of the builder: e.g. coupling with existing ProcessWire fields or not, or both, etc.
3. Community (seems more people prefer this(?)) -led versus commercial (other?) project/module.
4. If community-led, who are the leads?
5. Page Builder built on top of repeaters (seems many people would prefer this (?)) or separate module?
6. Strictly Page Builder or a site builder as well? (maybe not as important a conversation to have).

Are you building something yourself? Thoughts?

Thanks.

[Schwab]

On 10/16/2021 at 2:15 PM, kongondo said:

Hi Simon,

Apologies for the late response. I haven't touched this since I built the prototype. I think the Page Builder conversation isn't finished yet. Some of the pending discussion IMO are:

1. What type of Page Builder do people want? E.g. drag and drop with visuals, repeater-like-builder, etc.
2. Technical aspects of the builder: e.g. coupling with existing ProcessWire fields or not, or both, etc.
3. Community (seems more people prefer this(?)) -led versus commercial (other?) project/module.
4. If community-led, who are the leads?
5. Page Builder built on top of repeaters (seems many people would prefer this (?)) or separate module?
6. Strictly Page Builder or a site builder as well? (maybe not as important a conversation to have).

Are you building something yourself? Thoughts?

Thanks.

Dear kongondo

No problem at all. I'm not building anything yet, I don't know if I even could. I just had the same idea and found this post, so I wanted to ask what's going on.

I took a look at other builders like Elementor, js_composer, YooTheme and others. But to get something to work really well, it has to be a destinct solution for ProcessWire in the end. That takes a lot of time and skill, but it would bring ProcessWire to a lower threshold for users.

I think a builder would only make sense, if you finally could dynamically load fields and use selectors to get data for your builder elements like YooTheme is doing. I personally would do it for a commercial use, but I don't think it's viable.

Thanks