RockPageBuilder is here! 🚀🔥

[sebibu]

@bernhard I love your Modules for the well structured and OOP-way with lots of possibilities for advanced users to hook in and extend functionalities.
In RockPageBuilder I'm still missing a way to visual integrate two and more-columns layout simple and intuitive in blocks (not templates!) like this in MODX.
Can I achive this in any way? Thx and greetings to Vienna?

[bernhard]

Hi @sebibu thx for the great feedback ? 

Technically you can achieve that by creating a new block called "layout". Then you create two new RPB fields, eg column_left and column_right. Then you can add blocks to those fields, for example add "headline", "text" and "image" blocks to the column_left field. Then you can go to column_right and click add new block and click reuse existing block for all of your blocks.

For the frontend you have to create the markup of your layout in the "layout" block's template file (eg layout.latte or layout.view.php).

The problem with such setups is that it get's more complicated and you are moving the sweet spot between easy of use and features more towards features at the cost of more complicated content editing. On the backend RPB will show a button for nested RPB fields to edit those fields in a modal (or panel I think). So editors have to save the base page first, then can edit nested content. On the frontend this should be less of an issue.

You can try and report back what you find. Also @Stefanowitsch might have useful tips as he built a quite complex page using RockPageBuilder recently and I think he is going to share something soon?! ? 

[sebibu]

Thx for your quick answer, @bernhard!
This is exactly what I tried ( My blocks name is only TwoColumns instead of layout.?), but unfortunately it's from the backend-side not that intuitive then in the CMS/screenshot above.

However.. how can I get the content of the blocks inside a block with LATTE?
I tried this but curly brackets in curly brackets are not allowed.?

{$pages->get({$block->rpb_left})->text()}

Thanks in advance!

[bernhard]

23 minutes ago, sebibu said:

{$pages->get({$block->rpb_left})->text()}

Once you are in a tag you don't need any brackets any more. Basically inside the bracket its regular php: {$pages->get($block->rpb_left)->text()}

[sebibu]

While testing I tried your version, too @bernhard but getting this..

Unknown Selector operator: '[empty]' -- was your selector value properly escaped? field='1672', value='', selector: '1672' in block #1671 (rockpagebuilderblock-twocolumns)

This syntax works: ☺️

{$pages->get("$block->rpb_left")->text()}

Looking forward to the insights @Stefanowitsch might have.?

Any idea on how to output all possible blocktypes (like text, image,..) clever for both columns?

[sebibu]

Okay, I had a board in front of my head.?

<div class="uk-child-width-1-2@s" uk-grid>
  <div>{$block->rpb_left->render()}</div>
  <div>{$block->rpb_right->render()}</div>
</div>

 

[bernhard]

1 hour ago, sebibu said:

While testing I tried your version, too @bernhard but getting this..

Unknown Selector operator: '[empty]' -- was your selector value properly escaped? field='1672', value='', selector: '1672' in block #1671 (rockpagebuilderblock-twocolumns)

This syntax works: ☺️

{$pages->get("$block->rpb_left")->text()}

I just had a look at your example and answered the question about the latte syntax. I didn't think about what you are actually doing.

The error message means that you provided an invalid selector, which is obvious in your case as you are - as I said - in PHP land inside the brackets. That means inside the brackets the $block->rpb_left will likely be a RockPageBuilder\FieldData object (similar to a PageArray). You can't to a $pages->get( FieldData ) and that's what it complains about I guess.

What you are doing with " ... " is to typecast it to a string value and that makes it return the page ID if you have a single block in that field. If you had multiple blocks added to that field it would do something like $pages->get("1010|1011|1012") which would also cause an error! It's really nothing related to RockPageBuilder or Latte, it's just basic PW API usage.

6 minutes ago, sebibu said:

Okay, I had a board in front of my head.?

<div class="uk-child-width-1-2" uk-grid>
  <div>{$block->rpb_left->render()}</div>
  <div>{$block->rpb_right->render()}</div>
</div>

Didn't understand you where having problems with this, sorry. But glad you got it sorted.

[sebibu]

Thanks for the valuable clarification, @bernhard! I'm still a newbie to PW and the API.

One last question for today?:
What could be the reason the RPB-content is outputted like this??

<section id="b1672" class="rpb-text" data-rpbblock=1672 alfred='{"icons":[{"icon":"edit","tooltip":"Edit Block #1672","href":"\/rs\/page\/edit\/?id=1672&language=1062","class":"pw-modal alfred-edit","suffix":"data-buttons=\"button.ui-button[type=submit]\" data-autoclose data-reload"},{"icon":"up","label":"","tooltip":"vSpace top default","type":"vspacetop","widget":1672},{"icon":"down","label":"","tooltip":"vSpace bottom default","type":"vspacebottom","widget":1672},{"icon":"clone","label":"","tooltip":"Clone Block #1672","href":"\/rs\/rockpagebuilder\/clone …

 

[bernhard]

Ok glad it was helpful. I never know the level of the users so it's sometimes hard do find the right amount of information ?

4 minutes ago, sebibu said:

What could be the reason the RPB-content is outputted like this??

<section id="b1672" class="rpb-text" data-rpbblock=1672 alfred='{"icons":[{"icon":"edit","tooltip":"Edit Block #1672","href":"\/rs\/page\/edit\/?id=1672&language=1062","class":"pw-modal alfred-edit","suffix":"data-buttons=\"button.ui-button[type=submit]\" data-autoclose data-reload"},{"icon":"up","label":"","tooltip":"vSpace top default","type":"vspacetop","widget":1672},{"icon":"down","label":"","tooltip":"vSpace bottom default","type":"vspacebottom","widget":1672},{"icon":"clone","label":"","tooltip":"Clone Block #1672","href":"\/rs\/rockpagebuilder\/clone …

 

Looks like you are just missing the |noescape filter. Use it with caution, see https://latte.nette.org/en/tags#toc-escaping-output

The reason why you don't need it always is that many times RockFrontend/RockPageBuilder will return HTML objects so that Latte knows not to escape the output. If you return some html code as regular string then latte doesn't know anything and will encode entities for preventing some vulnerabilities.

[Stefanowitsch]

17 hours ago, sebibu said:

Okay, I had a board in front of my head.?

<div class="uk-child-width-1-2@s" uk-grid>
  <div>{$block->rpb_left->render()}</div>
  <div>{$block->rpb_right->render()}</div>
</div>

 

That looks good!

I have just finished a project with some complex layouts that required some nested RockPageBuilder blocks. And I did it the same way as you.

I have multiple layouts block that just render the markup:

A layout block looks like this:

<?php namespace ProcessWire;
use RockPageBuilderBlock\LayoutA;
/** @var Page $page */
/** @var LayoutA $block */
?>
<section class="rpb-layouta" <?= alfred($block,["trash" => false, "clone" => false, "widgetable" => false])?>>
    <div id="div1" class="col-2x1"><?= $block->rpb_cell_2_1_a->render(true); ?></div>
    <div id="div2" class="col-1x1"><?= $block->rpb_cell_1_1_a->render(true); ?></div>
    <div id="div3" class="col-1x1"><?= $block->rpb_cell_1_1_b->render(true); ?></div>
    <div id="div4" class="col-2x2"><?= $block->rpb_cell_2_2_a->render(true); ?></div>
</section>

Inside there are some nested - custom - RockPageBuilder fields. Inside these fields you can insert various other RockPageBuilder content blocks. Like Text, Images, whatever.

This is especially neat when editing the site in the frontend. The "naked" layout block looks like this:

Then you can insert content to each of those cells via the nested RPB fields;

However I have to say that the backend editing of these blocks is a bit "convoluted".

When the project reaches a "final state" I will explain the details in a showcase here in the forum in more detail.

[sebibu]

On 7/17/2024 at 6:58 PM, bernhard said:

Looks like you are just missing the |noescape filter.

Thanks for the in-depth knowledge to this, @bernhard!
I used this before but tried to avoid it for security reasons.

The background is.. At one time the block-actions were not visible, so I suspected it could be the noescape-filter.
Yesterday I realized by chance, that block-actions are not visible when using the „hide topbar“-button in the RockFrontend Topbar.
I don't find that logical. Can you please separate this two functions in two topbar-buttons?

[sebibu]

23 hours ago, Stefanowitsch said:

However I have to say that the backend editing of these blocks is a bit "convoluted".

I agree with that.

Thanks @Stefanowitschfor the first impressions. Looks great. I am looking forward to your whole showcase!

23 hours ago, Stefanowitsch said:

<?= alfred($block,["trash" => false, "clone" => false, "widgetable" => false])?>

Thanks also for showing the block-actions-setting-syntax! That would have been the next thing i would have asked, I didn't find that in the docs.
Did I missed it or otherwise could you please add it, @bernhard? A search function on your site for the docs would be convenient and probably saves you a few questions.

[sebibu]

Any idea why editing blocks does not open up in a modal anymore for editors and superusers on both websites I'm using RPB?
Seems like for the first milliseconds it opens a modal but then follows a normal pagerequest to the RockPageBuilderBlocks-site.
I browsed my configuration, the docs the last days and editors do have the permission `page-edit-front`. I'm without further ideas..?

[Stefanowitsch]

3 hours ago, sebibu said:

Thanks also for showing the block-actions-setting-syntax! That would have been the next thing i would have asked, I didn't find that in the docs.
Did I missed it or otherwise could you please add it, @bernhard? A search function on your site for the docs would be convenient and probably saves you a few questions.

Not it seems that those settings are not part of the Docs (at the moment).

Have a look in inside RockPageBuiler.module.php on Line 257. There you will finde all attributes that you can change in the markup:

 // setting specific to rockpagebuilder blocks
'noBlock' => false, // prevent block icons if true
'addTop' => null, // set to false to prevent icon
'addBottom' => null, // set to false to prevent icon
'addHorizontal' => null, // shortcut for addLeft + addRight
'move' => true,
'isWidget' => $isWidget, // is block saved in rockpagebuilder_widgets?
'widgetStyle' => $isWidget, // make it orange
'trash' => true, // will set the trash icon for rockpagebuilder blocks
'clone' => true, // can item be cloned?
'widgetable' => $widgetable, // can be converted into widget?

 

[sebibu]

On 7/19/2024 at 11:50 AM, sebibu said:

Any idea why editing blocks does not open up in a modal anymore for editors and superusers on both websites I'm using RPB?
Seems like for the first milliseconds it opens a modal but then follows a normal pagerequest to the RockPageBuilderBlocks-site.
I browsed my configuration, the docs the last days and editors do have the permission `page-edit-front`. I'm without further ideas..?

@bernhard Do you have any ideas on this? Thx & greetings!?

[bernhard]

On 8/15/2024 at 3:18 PM, sebibu said:

@bernhard Do you have any ideas on this? Thx & greetings!?

PM

Update: He was loading jQuery on the frontend which interfered with PW's modal implementation of frontend editing. Removing jquery resolved the issue.

[sebibu]

Thanks @bernhard for helping me out yesterday! Will try to include jQuery only on the necessary pages with a different implementation in the new week.

[bernhard]

RockPageBuilder v5.6.0

• We now have customizable block stubs! 😍🔥
  @FireWire requested that feature in the forum and I thought it was a great idea, so I added support for it. You can now define your very own boilerplate code with custom classes that you need for your specific project. See the docs here.
• Added the "rocksortable-added" event so that you can attach custom callbacks to the sortable instance. I'm using this to apply some project-specific classes after block order has been changed (to update the text color based on the current background color of multi-colored pages): See the docs here.
  I shared a little screencast here and think that is a really cool way of adding color sections to any site.
• Added the field() method to $block objects. Make sure to also update RockFrontend to the latest version!
• Fixed wrong sorting of blocks with Umlauts.