RockPageBuilder is here! 🚀🔥

[Tiberium]

11 minutes ago, bernhard said:

only the UI is not and I'm not sure what the best implementation would look like

How about it is done by the RepeaterMatrix. You can copy/clone a block:

A Dropdown come up (in my case in German)

1. Copy this element in the storage to insert somewhere else
2. Clone element and paste it over this (selected/clicked) element
3. same as 2 but paste it behind
4. is there when an element is in the storage and you want to paste it above
5. same as 4 but paste behind
6. Empty the sorage

And then you get on all Fields (same Page and other Pages with this field), the option to paste it in:

 

I think there is potential to optimize it. But i think it is a good starting point. Especial for people who come from the RepeaterMatrix.

[bernhard]

7 minutes ago, Denis Schultz said:

I think there is potential to optimize it.

Please go ahead ? 

[Tiberium]

I don't say i knew it better ^^ - But as a base point....

In my opinion, the really not so good part is the dropdown. The points 2 and 3 can easily be confused with 4 and 5. Aside from that, I think the approach with the clone in the storage and then add the paste link where you add your blocks is (again, in my opinion) straight forward.

[sebibu]

20 minutes ago, bernhard said:

That has been on my wishlist for a long time ? The API is already there, only the UI is not and I'm not sure what the best implementation would look like. I could think of either a copy&paste feature (similar to what we have in regular repeaters) or a move/copy icon in the top right where you can select another block. I think copy&paste would be easier overall?

Great the API is already there.?

A cut and copy icon in the context menu in top right of every block would be intuitive, I think.
And when having already cutted or copied a block a paste icon in the context menu in top right of every block.

20 minutes ago, bernhard said:

Could you please explain the exact use case? I've never had that need myself.

If you have a RPB field on template1 and template2 and you have to change the template while having content in the RPB field, the content should not get deleted.

Also when having e.g. 1 and 2 column-templates and the editor wants to change the layout on a page from 2 to 1 columns and simply changes the template while having content in RPB fields, the content should not get deleted.
If the RPB field on the old template is also in the new template, the content should be preserved (moved in the background/db),
if the RPB field does not exists on the new template RPB should asking if/where to paste the content to.?

I can now think of two more functions:

1. Drag and drop blocks from on RPB field to another RPB field on the same page.
2. Cut/copy fields in blocks from on page to another.?

[bernhard]

2 minutes ago, sebibu said:

I can now think of two more functions:

1. Drag and drop blocks from on RPB field to another RPB field on the same page.
2. Cut/copy fields in blocks from on page to another.?

I knew these would come up one day ? 

4 minutes ago, sebibu said:

If the RPB field on the old template is also in the new template, the content should be preserved (moved in the background/db),

Actually I didn't know that content is lost. I'm not sure why to be honest. It's a textarea field behind the scenes and I thought field content was preserved when changing a template? I haven't had the need to change templates for a long time though and I'm wondering why you are creating two templates for that. Couldn't you just create a select field on one template that says "2-column layout" and "3-column layout"?

[sebibu]

43 minutes ago, Denis Schultz said:

In my opinion, the really not so good part is the dropdown. The points 2 and 3 can easily be confused with 4 and 5. Aside from that, I think the approach with the clone in the storage and then add the paste link where you add your blocks is (again, in my opinion) straight forward.

I see it the same way.

With the dropdown, two dimensions of the function (action and position) are accommodated together (it's easy to get lost), which can be separated and visually simplified.
Action via cut/copy and paste icon.
The paste position could be determined by selecting the paste icon before and after each block.
This is intuitive for me and is also used by other pagebuilders.

But that would mean that it must also be possible to insert new blocks above and below.
Which I would very much welcome.?

[sebibu]

26 minutes ago, bernhard said:

I knew these would come up one day ? 

? So let's go!?

27 minutes ago, bernhard said:

Couldn't you just create a select field on one template that says "2-column layout" and "3-column layout"?

For editors who prefer to change content in the backend, editing content/blocks already in 2 or 3 columns is way more natural.
Moreover, when selecting "2-column layout" then there are still 3 RPB-fields of which you are not allowed to use the last one, if I understand you right.?

[bernhard]

I'll have to check out this weird change template issue! Thx.

[sebibu]

Okay, changing a template with same RPB-fields preserves content.

But changing the template of a page to a template without the former RPB-field deletes the content.
Even if you change the template back.

Hope that helps for this topic, which is obviously and unfortunately not of interest for you.

Edited March 19 by sebibu
Clarification

[bernhard]

1 minute ago, sebibu said:

Hope that helps for this  topic, which is not so much fun.

What do you mean?

1 minute ago, sebibu said:

Okay, changing a template with same RPB-fields preserves content.

But changing the template of a page to a template without the former RPB-field deletes the content.
Even if you change the template back.

Thx for the clarification. Well... I don't know how that should be possible then? It sounds like a very specific use case and you could always hook into Pages::saveReady and Pages::saved to achieve what you need. I don't think that I can come up with a common solution for that specific use case that would be helpful for many.

[bernhard]

On 3/19/2024 at 10:46 AM, sebibu said:

Great the API is already there.?

New docs about the RockPageBuilder API that makes it easy to import content from old websites and convert it to RockPageBuilder blocks ?

https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/api/

[Klenkes]

@bernhard, sorry but after the update to RPB 5.4.0 the site is broken... I had to revert back. A missing dependancy?

Quote

Method Config::versionUrl does not exist or is not callable in this context (in D:\Projekte\xxxxxxx\wire\core\Wire.php line 563)

PW 3.0.226 | RMig 3.35.5 | RockFrontend 3.11 | PHP 8.2

[bernhard]

Your version of PW seems to not have versionUrl on the $config variable. Can you update PW to a recent version?

[FireWire]

Hey @bernhard!

Is there something I can add to an element to prevent the editor from rendering? If I can add an attribute or class to something that would disable editing on a per-element basis? I could skip elements where it isn't desired. This is a FormBuilder form embedded as an iframe:

Would be a good idea to eliminate them in iframes altogether? Not sure if there would be instances where that would cause issues though.

 

[bernhard]

Hey @FireWire thx for your message!

53 minutes ago, FireWire said:

Is there something I can add to an element to prevent the editor from rendering? If I can add an attribute or class to something that would disable editing on a per-element basis? I could skip elements where it isn't desired. This is a FormBuilder form embedded as an iframe:

What you are seeing here is the RockFrontend topbar. That is coming from RockFrontend, not RockPageBuilder. Where do you render that formbuilder form? What kind of iframe is that? It looks like a modal. Do you show a form in a modal popup?

The topbar is added here: https://github.com/baumrock/RockFrontend/blob/67fcccee9295c81716c133f9ac28ce3ff3b5dcba/RockFrontend.module.php#L278

You know more about FormBuilder than I do, so if you tell me how we can identify that we are in a FormBuilder iframe than we can catch that situation and prevent rendering the topbar. Maybe we can even find a more general idenifier that also works for other situations like iframes in general, as you mentioned. Input/Ideas welcome ? 

 

[FireWire]

@bernhard I'll look into this and reach out when I have more information. The form is being rendered using one of FormBuilder's built in methods to embed as an iframe. The iframe is being rendered in a UIkit modal, but that isn't causing any conflicts which is OK.

This is only the 2nd time I've used FormBuilder so I'm no expert ha!

[FireWire]

@bernhard So a quick fix for the FormBuilder isssue with the topbar is to exclude the page it renders inside the iframe by template name.

<?php

  public function addTopBar(&$html)
  {
    if (!$this->isEnabled('topbar')) return;
    $page = $this->wire->page;

    if (!$page->editable()) return;
    if ($page->template == 'admin' || $page->template == 'form-builder') return; // Adding the extra check for FB here solves it
    if ($this->wire->input->get('rfpreview')) return;
    if ($this->wire->config->hideTopBar) return;
	// etc.

It's the only instance of an iframe issue I can think of and that's because the contents are rendering from a page within ProcessWire where it isn't possible for it to be front-end editable.

[Klenkes]

15 hours ago, bernhard said:

Your version of PW seems to not have versionUrl on the $config variable. Can you update PW to a recent version?

@bernhard RPB seems to need at least PW 3.0.232 when the Version Module was introduced.

I updated to RPB 5.4.0 and it now runs without errors.

[bernhard]

14 minutes ago, Klenkes said:

RPB seems to need at least PW 3.0.232 when the Version Module was introduced.

Thx, I've added this to the module's info.php as requirement

4 hours ago, FireWire said:

$page->template == 'form-builder'

Thx, I've pushed that "fix" to the module ? 

[bernhard]

From the Rock Monthly newsletter:

RockPageBuilder v5.4.2

• We have now an API to save settings:
  $block->saveSetting('image-size', 'S');
• Docs about Frontend Editing have been improved.
• Fixed "$root not defined" bug

[FireWire]

Paging Dr. @bernhard!

I'm kicking off a website project (likely the largest I've ever taken on before) soon and, of course, RockPageBuilder will be used ? It's for a large public event that will have hundreds of pages for event activities, information about entertainment and things to do around town, lodging, sponsors, promote tickets sales, etc. as well as a branded "magazine" style blog. It's going to require a lot of diversity in content and design.

My question: is it possible to have multiple RPB fields with the ability to implement blocks as such:

• Have blocks that are available to all RPB fields (as it does now)
• Assign blocks to multiple RPB fields, but not all
• Assign blocks to just one RPB field exclusively

In my case this is very useful as the "magazine", events, and main pages each have unique design elements and I would like to let users use blocks without using them where they shouldn't be and "breaking" the design of the website, so to speak.

If this is possible I may have to file for divorce and marry RockPageBuilder.

[bernhard]

Hi @FireWire thx for your kind words and congrats for the project!

I think what you are trying to do is already possible, it has just not been documented yet ? So I've added it to the docs for you: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/blocks/#conditional-blocks

Does that do what you need? As mentioned in the notes you could also hook into "getAllowedBlocks". Or you can also create different fields and share blocks across those fields. The easiest solution is the "show" property in the info method if you can trust your users to some extent.

Your project sounds great, would be awesome if you shared the result with us once it is online ? All the best!

[FireWire]

? This is outstanding and I love the implementation. Being able to choose where blocks are available/rendered using a function is really powerful, even better than I hoped for. As usual, RPB continues to deliver so many great features that I wouldn't be surprised at all if this module even made coffee.

Quote

If this is possible I may have to file for divorce and marry RockPageBuilder.

My wife is really not going to like this.

[bernhard]

The latest release fixes a bug that was caused by a recent chrome update where moving blocks led to selecting the underlying text:

And after the fix:

Happy dragging&dropping ? 

[bernhard]

All RPB users please make sure that you remove this line from your Accordion.php block (if you are using it). It will be removed in the installation files on the next version, but if you copied that file you need to remove it manually: