RockFrontend 🔥🚀 The Powerful Toolbox for ProcessWire Frontend Development

[Stefanowitsch]

@bernhard does the postCSS feature still work as intended? 

After updating RockFrontend and installing RockDevTools all my rfGrow settings are written directly to the generated styles.css like this:

font-size: rfGrow(18pxrem, 20pxrem);

 

[protro]

How do we fix the breaking changes? The documentation is unclear:

I have installed RockDevTools
added $config->rockdevtools = true; to config.php
switched styles() to stylesTag() in _main.php.

I am getting WireExceptions, and the Rockfrontend documentation is out of date https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/asset-tools/

[bernhard]

  On 2/4/2025 at 9:08 PM, protro said:

How do we fix the breaking changes?

Expand  

At the moment I'd recommend simply not to upgrade and use the new RockFrontend + RockDevTools just for new projects.

[protro]

And if we have already upgraded ?
Is it enough to manually add v 4.10 back into the /modules folder ?

[bernhard]

Yes that should be all you need to do.

[bernhard]

  On 2/3/2025 at 10:48 AM, Stefanowitsch said:

@bernhard does the postCSS feature still work as intended? 

After updating RockFrontend and installing RockDevTools all my rfGrow settings are written directly to the generated styles.css like this:

font-size: rfGrow(18pxrem, 20pxrem);

Expand  

@Stefanowitsch I'm proud to announce that this is now also successfully ported to rockdevtools 😎

Note that the syntax changed to grow() and shrink() as it is not any more a RockFrontend feature and AI told me it's safe to use these wordings as they are not used in css/less/sass

https://www.baumrock.com/en/processwire/modules/rockdevtools/docs/rockcss/

[cbc-design]

Hi @bernhard,

I get this error on old projects in Firefox (see screenshot).

Now it also appears also in a new project with RockDevTools - do you have an idea how to solve it?

Thank you, Christian.

 

[bernhard]

  On 2/25/2025 at 5:14 PM, cbc-design said:

I get this error on old projects in Firefox (see screenshot).

Expand  

Does that mean you do not get this error in other browsers? So it's FireFox only?

[cbc-design]

Sorry, I had forgotten: the error appears in all browsers with which I can test. There is no error on the first call, but the liveload still doesn't work. The error then appears when the page is reloaded (attached is the screenshot from Edge).

[spoetnik]

Thanks for the great ecosystem of tools you have build

Today i tried to setup a new clean site using the ``site-rockfrontend`` profile. Right out of the box less compiling, and live reloading doesn't work.

I have read the documentation, and watched your Youtube video's, but all didn't help. Finally I came here, and read that the livereload has moved to RockDevTools. So the setting in the site config should be ``$config->rockdevtools = true;`` and not ``$config->livereload = 1;``

I think to documentation, and the site-profile are behind at the moment.

[bernhard]

  On 2/27/2025 at 4:59 PM, spoetnik said:

Thanks for the great ecosystem of tools you have build

Expand  

Thx 🙂 Glad if it is helpful!

  On 2/27/2025 at 4:59 PM, spoetnik said:

Today i tried to setup a new clean site using the ``site-rockfrontend`` profile. Right out of the box less compiling, and live reloading doesn't work.

I have read the documentation, and watched your Youtube video's, but all didn't help. Finally I came here, and read that the livereload has moved to RockDevTools. So the setting in the site config should be ``$config->rockdevtools = true;`` and not ``$config->livereload = 1;``

I think to documentation, and the site-profile are behind at the moment.

Expand  

Yeah that's possible. Unfortunately I had to change the way how I manage assets in my frontend. Thx for the report! I'll try to fix those issues asap.

[bernhard]

  On 2/25/2025 at 5:14 PM, cbc-design said:

Now it also appears also in a new project with RockDevTools - do you have an idea how to solve it?

Thank you, Christian.

Expand  

Well... the pragmatic, most efficient and probably best solution would be to use DDEV. Other than that it might be that LiveReload breaks in subfolder installations. I have to check that. But still I can't recommend DDEV enough for PW development.

[bernhard]

Hey @spoetnik I just pushed an update to the rockfrontend site profile. Can you confirm things are now working and showing infos as expected?

[spoetnik]

Is started a new ddev project, copied the site profile from https://github.com/baumrock/site-rockfrontend/tree/main/site/assets/backups/export-profile/site-rockfrontend
but it still doesn't work out of the box.......

[bernhard]

  On 3/1/2025 at 4:41 PM, spoetnik said:

but it still doesn't work out of the box.......

Expand  

It worked for me. It would be nice to provide more information for me. What did you do, what did you expect, what was the actual behaviour? Or if you know what needs to be changed to make it work out of the box please provide that information.

[Stefanowitsch]

@bernhard I have some trouble getting the new RockFrontEnd Toolbar to work properly.

Per default, when outputting the toolbar at the beginning of the body like this:

<body class="<?= $page->template->name; ?>">
	<?= $rockfrontend->toolbar() ?>
    ...
    ...

The toolbar gets rendered but is overlapped by my <header> which has position 'fixed'. This is because the toolbar has no position declarations at all:

So I understand that you need to tweak the toolbar markup to apply style classes to make it work for the specific project.

Like mentioned in the documentation I added this code to my _init.php:

// Customize RockFrontend Toolbar
$toolbar = '';
if ($user->isLoggedin()) {
    $toolbar = rockfrontend()->toolbar();
    $dom = $toolbar->dom();
    $dom->addClass('sticky foo bar');
    $toolbar = $dom->outerHtml();
}

I added the "sticky" class because It looks like the toolbar comes with a few default styles:

Then I render the output of the toolbar in my _main.php:

<?php
// _main.php
echo $toolbar;

What is strange: The "sticky" classname gets removed after rendering:

Another problem: The _main.php is appended. So the toolbar markup will be rendered at the very bottom of the DOM. Even if the "sticky" class will be applied it has no effect as the toolbar element still will reside at the very bottom of the page.

IMHO the toolbar should be positioned 'fixed' at top 0 with the highest z-index and at the top of the DOM per default.

 

[bernhard]

Hey @Stefanowitsch thx for the quick meeting. I updated the docs in the hope that others won't have the same problem of understanding how the toolbar works. Let me know if the docs are still missing anything.