RepeaterMatrix Page Builder - 3 Different Approaches to Building a Section (I need your feedback)

[Jonathan Lahijani]

Over the years, I've experimented with using RepeaterMatrix as the basis of a rich page builder.  I've gone through at least a dozen concepts, most of which hit the chopping block due to either being too complex, not well thought out, too clever or too limiting.

To my knowledge, the only other CMS that takes the "Builder" approach that I've demonstrated is DjangoCMS (meaning, it has a matrix-like field with depth support).

While the "Builder" approach works well, it could be too advanced for some people.  Therefore the other approach is the "Classic" approach where you don't deal with containers/rows/columns (which instead is handled by template code), and simply enter the content in the respective field.  This is easy to understand, but has drawbacks in terms of flexibility.  If it were made to be too flexible, it would become a "God" block which is bad.

Then I finally thought of a third approach which is a mix between the Builder and Classic approach.  It uses the basic builder blocks, combined with the layout from the matrix item template file.  By using the basic builder blocks, you get the plethora of options.  It requires an extra page to be created behind the scenes however, but live preview still works.

I made a video comparing all the above (10m duration).  I want to hear your feedback on this as I am ~75% done with my super module (doing a lot of code and concept cleaning at this point) and want to finish off this portion of it.

(note: I'm posting this in the Dev Talk forum since this is a discussion / not support request)

[Davis Harrison Dion]

@Jonathan LahijaniI haven't watched the video yet; will get to that this evening. But I do have a question: Have you had a look at CraftCMS?

[Jonathan Lahijani]

1 minute ago, Davis Harrison Dion said:

@Jonathan LahijaniI haven't watched the video yet; will get to that this evening. But I do have a question: Have you had a look at CraftCMS?

Yes, I built a project with CraftCMS 2 years ago.  It made me love ProcessWire even more. ?

I follow WordPress very closely and CraftCMS somewhat closely.  AFAIK, their Matrix field works similarly to ProcessWire's, but the fields that go inside each matrix-block are 1-off (not re-used).  Pros and Cons to that.  Also, it doesn't support depth, so really it's more of the 'classic' approach (like WP ACF Flexible Content).

[3fingers]

I really like the idea behind the third approach where every block has its sets of options to work with. I don't really like the way to access them, via a modal interface, even tought I think you've used it since it's the current best way pw gives us to stay in the state of the page edit.
One better approach would be to have somewhere a tab (or tabs) for each and every component inside the block (in this case image and text, as for your example) where the options might have their place to live, something similar to what we already have for the rest of the pages.
Or maybe, and even better, use the pw native sliding panels to edit the content of each block.

Great job by the way!

[jacmaes]

I always watch carefully your videos. You've put so much thought into it, it really shows how you've found the advantages and drawbacks of each solution. I also started experimenting with the first option where you basically need to set up the container, rows and columns first before working on your content. Template-wise, I figured that tracking depth could get complicated quickly, and I abandoned the idea, but it sure looks like the most flexible, less "hacky" way compared the new, third option you're proposing. Sure, it requires thinking about design first before inputting your content, and I'm not sure I would offer that option to most of my clients as it requires some learning and a designer/developer frame of mind ("what's the deal about those rows and container anyway?" is what I'd imagine they'd say), but if I'm the sole editor, I'll love to have that option!

The classic option is of course always a good, although obviously more limited option, that is intuitive and supported out of the box without some clever hack and double modals such as the new, hybrid approach. I can't shake the feeling that the third option is going to be brittle and need an ever-growing set of workarounds for all the use cases out there.

Personally, I've gone a different route. That's probably going to sound half-baked to you, but it might be of interest to some. Instead of trying to cram all the blocks on the same page, I'm using subpages as containers for those blocks. In other words, from the parent page, I loop through all the children to build my page out of this series of containers / sections. So each child page is basically a section of the parent page, where I only need to apply columns, then place my blocks inside. If I need to change the order of those sections, it's just a drag and drop away: I simply move the child page up or down below the parent page.

I've not fully explored the possibility, and I'm still experimenting with this on a couple of sites, but I've found it flexible enough for most of my uses, and easy to code. On each child page, first there's a combo (pro) field that holds the basic design settings for the current section, such as margin, padding, background color, width, etc. Then I set up my columns with a simple text field that holds predefined tags for responsive widths and optionally offsets and additional classes, and inside my blocks. Here's a screenshot (in Spanish, sorry) of something very similar to what you've shown in your video: a text on the left, and image on the right.

 

[Ivan Gretsky]

Nice to have this conversation going on) Thanks @Jonathan Lahijani!

The 1st approach

There is probably a room for each of the approaches. For now I am always using the 2nd one. It is the easiest for non-technical people and I have them in the admin. I do not think that I will ever use the 1st approach as it is. It is too complicated and too closely coupled with the markup IMHO. Not unless we make it more visual. To do it, we need at least 1, 2 and 9 from this list.

The 2nd approach

I can see how the 2nd approach could be made more configurable. You said earlier you're using Mystique for the options. I would've build option sets for different option groups:

1. Оne for the section, dealing with section background, margins, width and so on.
2. One for the grid, making columns proportions adjustable (50/50, 30/70, 33/33/33, 25/25/50 and so on). That option set should be limited by the pre-defined number of columns for block, so you wouldn't have 33/33/33 for a block that only should be displayed in 2 columns grid.
3. Option sets for image and text (for the example in the video).

The easiest way to implement those option sets is having them in separate Mystique fields. But they also probably could be merged into one general options field using this (hope I understood it right, didn't try it). Using separate fields would bring the benefit of positioning options next to corresponding items (like putting image options next to  image field). I understand that this could be a lot of work to configure those option sets, but that could pay off in the long run.

The main downside to 2nd approach is that you cannot easily and visually change elements' position/order. Like making image+text field a field+image. Or adding another column making it text+image+text.

The 3rd approach

I like the idea of using the 3rd approach, but I do not like the implementation. It indeed looks kind of hacky. I would stay closer to RM basic functionality, though extend it. I think that there could be a neat way to make it if @ryanwould help us here.

1. We would need to implement no. 1 (and 2)))) from this list (Make possible to define allowed children for the matrix types.) This would make 1s approach more solid, but also help us with the third. So we would only allow image and text block under image+text.
2. We would need to make possible creating groups of blocks from add block button. So when we add image+text block image and text blocks are automatically created under it. Might be already possible with hooks.
3. We need to think what happens when we move one of the child blocks somewhere else, so there would be only text under image+text and no text. Or make it impossible to move them out of that nesting. Or teach our content managers to not do it (worst scenario))

Well, lots of hacks needed too) But at least the text and image blocks are under the parent block and are manageable the same way as others.

---

There are other possible approaches. Probably Johnathan already thought/tried them, but putting them here for more alternatives.

The 1+3 approach

Let's have only general section block with options (no rows and columns) and content blocks. Content blocks can (but not should) go under section. If they are NOT under section, they display as full width. If there are more than 1 content blocks under section, they are displayed in columns. If you add 4 - there are 4 columns. Widths are adjustable on the content block label. If there are more than 100% of total width, they are displayed in 2 rows. Still we need no. 1 and 2 from this list to not allow content blocks be nested under each other.

The Repeater/RM inside RM approach

The name says it. Image and text blocks are inside of a RM nested inside Image+text field. Lots of extra fields, lots of configs, but I do it sometimes.

[Davis Harrison Dion]

On 12/14/2021 at 4:01 PM, Jonathan Lahijani said:

Yes, I built a project with CraftCMS 2 years ago.  It made me love ProcessWire even more. ?

Ha! Yes, me too. And I see what you mean about a 1-off field per block. Good point. Thanks for pushing this subject along!

[bernhard]

This is what I'm doing with RockMatrix:

I guess that's option 3 ? Not perfect, but the best option I have so far...

While I see the benefits of option 1 I can't see any client in the world be able to use it. And even if you where a developer it would need very good understanding of the setup or css framework that you use to understand exactly what you need to do, where you need to click, which block you need to indent and where etc...

[3fingers]

1 hour ago, bernhard said:

This is what I'm doing with RockMatrix.

Now we are talking ?
That's what I meant in my previous post, using pw-panels to have some more options capabilities per single, matrix block, field.
In your example video (where the panel is used), is there any reason beyond your preference to not have a repeater field in your main editing page?
IMHO the real potential benefit would be delegating custom, reusable options (something like a combo field) for each single repeater matrix entry (if needed).
Doing so we could de-clutter the interface and gain more clarity for both us and the user.

[bernhard]

52 minutes ago, 3fingers said:

In your example video (where the panel is used), is there any reason beyond your preference to not have a repeater field in your main editing page?

That's a really good question! I just remember that RockMatrix does not support nesting RockMatrix fields inside RockMatrix fields. I can't remember why and I can't remember if it works with Repeaters... I should actually try that out... ? 

[elabx]

On 12/17/2021 at 12:20 PM, 3fingers said:

IMHO the real potential benefit would be delegating custom, reusable options (something like a combo field) for each single repeater matrix entry (if needed).

I've thought of this a bunch of times! Common settings for the repeater types. Some I normally use are visibility settings, and sometimes dates for ranges to enable/disable.

[fuzendesign]

On 12/14/2021 at 6:11 PM, jacmaes said:

Personally, I've gone a different route.

I really like this approach. Very much. Thanks for sharing.

[thetuningspoon]

What you've done with the first example looks super powerful. Nice work. The second approach is what we use. It's always a battle between giving the client more control vs. making it easier for them to manage (and making sure they don't mess up the site's aesthetic!). So we tend to give them more clearly defined components and then add options to them as they need them, or build out new components if they want something totally new. With the example of the text w/ image block, you could create a single block but add a radio button for which side the image goes on.

[OllieMackJames]

@Jonathan Lahijani I love what you are doing.

I would like for you to take a look at something from the wordpress world, which is oxygenbuilder which bypasses the whole themeing system of wordpress.

The oxygen builder is a thing to behold, and boy would I love to see that implemented in your processwire pagebuilder.

If you want, I can give you access to the backend on one of my test sites so you can do a deep dive yourself.

Below you see the backend of www.rugpijnweg.nl/wpress where I try to copy www.rugpijnweg.nl (which is a processwire site) to wordpress in oxygenbuilder

I will start another post on why I even considered leaving processwire, but do not want to hijack your post, I just want to give you input on what I think would be brilliant if you could make your page builder like that.

Below you see a screenshot of the backend, with on the right the different sections, as you can see I selected the Hero Video section, on the left you see a couple of tabs, Primary, Advanced and Style Flow. I opened up advanced so you can see all the options there.

This allowed me to replicate my processwire custom made site, and add things easily. Mind you, I am not a coder, nor a developer, but sell my ebooks through my sites and need them to be easily adaptable to improve conversion.

Reason for me to post is that I still can not get myself to fully leave processwire, IMHO it is the very best csm under the hood.

So let me know if you want to see more of this, and I'll give you access.

 

[Jonathan Lahijani]

@OllieMackJames I've experimented with most of the popular page builders in WordPress, including Oxygen.  The direction I'm taking is vastly different from all of them.  Simply put, the page builder being based on RepeaterMatrix is what I'm trying to accomplish and for it to be usable with the developers CSS framework of choice (Uikit, Tailwind, Bootstrap, Codyframe, no framework, etc.).  Anything beyond that is outside my skillset and the scope of what I'm truing to do.  I have no interest in using React, Vue, etc. and going to the extreme like the WP page builders do.  The page builder will simply be "good enough" to make marketing pages based on the capabilities of whatever CSS framework is installed.

[OllieMackJames]

@Jonathan LahijaniThanks for your reply and insight in your reasoning.

[MrSnoozles]

@Jonathan LahijaniI'm just planning a project that would benefit a lot from a page builder. Were you able to work more on yours?

[Jonathan Lahijani]

6 hours ago, MrSnoozles said:

@Jonathan LahijaniI'm just planning a project that would benefit a lot from a page builder. Were you able to work more on yours?

Yes, but the module is still in deep development.  It's kind of never ending, but I have put a lot of consistent time into it over the last month.  I'm at mostly the refactoring stage now as I have gotten in most of the features I want.  I am stripping out experimental ideas that just didn't feel right, such as the 3rd approach in my video (too overcomplicated).  Page builders are... not difficult to develop but easy to overcomplicate.

To be clear, my module is not going to be just a page builder (although that is a large part of it).  It's essentially my vision of a highly opinionated, modularized starting point that works well with a CSS framework of your choosing (UIkit3, Bootstrap5, Tailwind, CodyFrame or no CSS framework).  Whichever CSS framework one uses, a page builder (ie, the 'Blocks' field), would be provided that's built around the chosen CSS framework.  UIkit3 would be the most flexible in page building capability (since UIkit is designed for page building scenarios and it's easy to replicate the logic and thought process of how YOOtheme did their builder), but the page builders for others would work well too as they would be inspired by YOOtheme's approach but just adapted for the respective CSS framework.

I'm taking great care to make it as easy to use as possible.  A goal of this is to make ProcessWire easy to use for those who are just starting to use it and not sure how to structure things.  This is where the heavily opinionated decisions I made come in.

[MarkE]

On 7/14/2022 at 6:07 PM, Jonathan Lahijani said:

It's kind of never ending

That's a shame. Maybe an initial release would help ? At least some feedback might be useful.

[pwired]

It is no secret that Wordpress attracs a lot of no-coders and low-coders because of it's available template market. The no-coder buys a template on envato, themeforest, templatemonster, etc. and sells it as a website to the client. Most of the clients don't even know they bought an envato template website because they have no time and no website experience. By the time the client needs to have something changed, the wordpress template limitations won't allow for it and the no-coder is long gone selling a template somewhere else. Sooner a later the client is forced to call for a real coder for the needed level of support. Pagebuilders will attract even more no-coders and low coders. Having followed the Pagebuilder scene in Wordpress with Beaver, Bakery, Brizy, VisualComposer, Elementor, Genesis, Gutenberg, Themify, Divi, Oxygen, GeneratePress .... the list goes on and on. There is almost every month a new Wordpress Pagebuilder on the block. Why spend time in learning the Pagebuilder of the day if you could spend that same time in learning html, js, css and php and never need a Pagebuilder in the first place and give the Client a website that he really deserves: without Template limitations, unused theme functions and without all the Pagebuilder bloated code. Coming to my point: I hope that what is happening in the Wordpress Pagebuilder scene will never happen with future Processwire Pagebuilders.

[MarkE]

1 hour ago, pwired said:

Coming to my point: I hope that what is happening in the Wordpress Pagebuilder scene will never happen with future Processwire Pagebuilders.

I quite agree. BUT I think ProcessWire would benefit from a larger user group. Many (professional) developers are influenced by the critical mass of an open source solution - below a certain level and they are wary of being tied into a framework that may be going nowhere. For that reason, ProcessWire is often not chosen and an inferior, but more widely used, system is selected instead.

The advantages that a page builder potentially brings are, to my mind:

• More users are attracted to PW. Some of these might be 'non-coders'. Equally, they may be people who can code (to some extent) but who just want to implement a simple site quickly (which might be enhanced later).
• A developer can off-load some of the work to a 'non-coder' who can focus on design aspects (this may be the client)

However, the crucial point that @pwiredmakes is that the use of a page builder should not restrict the site further. The structure of ProcessWire is such that this ought to be achievable, but only if a page builder makes use of PW components in a transparent and modifiable way.

There seems to be quite a bit of activity in this area, notably @Jonathan Lahijani's above and @bernhard's RockMatrix (still under wraps, I think), and it would be good to have a bit more visibility of the approaches used and how they meet these objectives.

I have done a bit of thinking myself about how a page builder should look, but it's early days yet (and I don't want to re-invent the wheel). Ideally it would make use of standard PW components, but it would be opinionated to some extent (CSS grid and Tailwind seem obvious choices). Trouble is, most of the paths I have explored so far end up using RepeaterMatrix. Don't get me wrong, RM is a great field, but I don't think it's a great idea to have a page builder, which is designed to atrract new users, being dependent on a commercial module.

P.S. Also, I think a page builder should allow for multiple themes, so that developers can easily add a new theme.

[szabesz]

12 hours ago, MarkE said:

BUT I think ProcessWire would benefit from a larger user group.

Ryan has already stated lots of times that he is not interested in growing the user group just for the sake of growing it. In other words, it is very low priority for him, as far as I understand it.

He is also not interested in page builders as such, but happy to add features to Repeater Matrix that support such use cases whenever he has the time to work on it. I guess that will be the closest to "page building" from Ryan.

12 hours ago, MarkE said:

P.S. Also, I think a page builder should allow for multiple themes, so that developers can easily add a new theme.

"Theming" will certainly never be possible with ProcessWire as a core feature as that would be agains its philosophy, wouldn't it? A solo or a team of developers can surely come up with their own theming schema and implement it for themselves but that is a different story, I think.