RockFrontend 🔥🚀 The Powerful Toolbox for ProcessWire Frontend Development

[bernhard]

13 minutes ago, Andi said:

RF is really fantastic already, and loving the new features.

Great to hear that ? 

13 minutes ago, Andi said:

If I create an empty folder "site/templates/layouts", there's only two errors coming up..

Interesting. I don't have any issues with that and I also don't have a "partials" folder for example. So I can't really do anything about the issue as I'm not seeing it. Would be great if you could track that down further. I'm quite sure it is in getPath of RockFrontend.module.php so maybe you could just add an early return there at the very top and then move that return down line by line and see when the error starts showing up?

[Andi]

Somehow i feel like getPath is doing it's thing correctly..., It's supposed to return false if the path is not valid, or am I getting confused here? ?

6 hours ago, Andi said:

before
'/site/templates/layouts'
after
false

before
'/site/templates/sections'
after
'/home/sites/XXXXXXX/public/site/templates/sections/'

before
'/site/templates/partials'
after
'/home/sites/XXXXXXX/public/site/templates/partials/'

before
'/site/assets/RockMatrix'
after
false

before
'/site/assets/RockPageBuilder'
after
false

But in AssetsArray.php -> addAll(), there seems to be a check missing for $path.

If I change that to

public function addAll($path, $suffix = '', $levels = 2, $ext = ['js'])
  {
    /** @var RockFrontend $rf */
    $rf = $this->wire('modules')->get('RockFrontend');
    bd($path, 'before');
    $path = $rf->getPath($path);
    bd($path, 'after');
    if (!$path) return;  // ******* <-- add this line *********
    $files = $this->wire->files->find($path, [
      'recursive' => $levels,
      'extensions' => $ext,
    ]);
    foreach ($files as $f) $this->add($f, $suffix);
    return $this;
  }

The errors are gone... Although I'm not quite sure about what to return there ?

[gornycreative]

@bernhard Hi on the site directory templates topic, I think it is just a matter of detecting the template root across the board in terms of /site/templates or /site-subsite/templates...

If I download uikit from the RFE module settings, for example, it does get saved in the site-subsite/templates/ directory. If I download a webfont, the same - a fonts directory is creates in site-subsite/templates/ and font files are brought over.

However, the sample CSS provided on the backend assumes /site/templates/fonts/ as the root for font files.

Likewise, the injected CSS assumes /site/templates/ instead of grabbing the site root directory.

  <!-- rockfrontend-styles-head -->
  <link href='/site/templates/bundle/head.css?m=1666711953' rel='stylesheet'>
  <link href='/site/templates/fonts/webfonts.css' rel='stylesheet'>

The actual site root for this site is site-mgtc - so /site-mgtc/templates should be detected.

I hope that makes sense.

The uikit styling issues were an unrelated VPN issue caused locally - ignore that piece.

Lots of convenient stuff here - really liking the operation so far.

This is with v 2.1.11 BTW - I upgraded and cache cleared to be safe.

[bernhard]

Thx @gornycreative I understand now! So it's only about the generated CSS of the webfont downloader? Or any other spots where you see wrong paths/urls?

[bernhard]

1 hour ago, Andi said:

But in AssetsArray.php -> addAll(), there seems to be a check missing for $path.

If I change that to

public function addAll($path, $suffix = '', $levels = 2, $ext = ['js'])
  {
    /** @var RockFrontend $rf */
    $rf = $this->wire('modules')->get('RockFrontend');
    bd($path, 'before');
    $path = $rf->getPath($path);
    bd($path, 'after');
    if (!$path) return;  // ******* <-- add this line *********
    $files = $this->wire->files->find($path, [
      'recursive' => $levels,
      'extensions' => $ext,
    ]);
    foreach ($files as $f) $this->add($f, $suffix);
    return $this;
  }

The errors are gone... Although I'm not quite sure about what to return there ?

Sounds reasonable!!

Please check v2.1.12 @Andi Thx for your help!

[Andi]

16 minutes ago, bernhard said:

Please check v2.1.12 @Andi Thx for your help!

All good, that seems to have done it ?

Glad I could help & thanks for the support!

[gornycreative]

49 minutes ago, bernhard said:

Thx @gornycreative I understand now! So it's only about the generated CSS of the webfont downloader? Or any other spots where you see wrong paths/urls?

I think the main change that would help is the autoload function - this hardcode in module.php:

  /**
   * Autoload scripts and styles
   */
  public function autoload($page)
  {
    $styles = $this->styles();
    $scripts = $this->scripts();

    if ($page->template != 'admin') {
      // frontend
      if ($styles->opt('autoload')) {
        $styles->addAll('/site/templates/layouts');
        $styles->addAll('/site/templates/sections');
        $styles->addAll('/site/templates/partials');
        $styles->addAll('/site/assets/RockMatrix');
        $styles->addAll('/site/assets/RockPageBuilder');

        // add the webfonts.css file if it exists
        $styles->add('/site/templates/fonts/webfonts.css');
      }
    }
  }

Maybe concat $this->wire->config->paths->root? Sorry I don't have this pulled down in git.

Looks like a Latte cache check is also hardcoded to /site/ in __render():

    // if render() was called from within a latte file we return a HTML object
    // so that we dont need to use the |noescape filter
    if (
      // this works for $rockfrontend->render()
      strpos(Debug::backtrace()[0]['file'], "/site/assets/cache/Latte/") === 0
      // this works for $rockfrontend->renderIf()
      or strpos(Debug::backtrace()[1]['file'], "/site/assets/cache/Latte/") === 0
    ) {
      return $this->html($html);
    }

In createCssSuggestion():

      // see https://css-tricks.com/snippets/css/using-font-face-in-css/#practical-level-of-browser-support
      foreach ($files->find("format=woff|woff2") as $file) {
        $comment = self::webfont_comments[$file->format];
        // comment needs to be first!
        // last comma will be trimmed and css render() will add ; at the end!
        $src .= "\n    $comment\n    url('/site/templates/fonts/{$file->name}') format('{$file->format}'),";
      }

//... and later

      // see https://css-tricks.com/snippets/css/using-font-face-in-css/#practical-level-of-browser-support
      $eot = $files->get("format=eot");
      if ($eot) {
        $src .= "url('/site/templates/fonts/{$eot->name}'); /* IE9 Compat Modes */\n  ";
        $src .= "src: url('/site/templates/fonts/{$eot->name}?#iefix') format('embedded-opentype'), /* IE6-IE8 */\n  ";
      }
      foreach ($files->find("format!=eot") as $file) {
        $format = $file->format;
        if ($format == 'ttf') $format = 'truetype';
        $comment = self::webfont_comments[$file->format];
        // comment needs to be first!
        // last comma will be trimmed and css render() will add ; at the end!
        $src .= "\n    $comment\n    url('/site/templates/fonts/{$file->name}') format('{$file->format}'),";
      }
      $src = trim($src, ",\n ");

I think the rest is just cosmetic hardcode /site/ in notes provided to the admin UI for the settings page.

I realize for the typical site user these issues should never arise as the module is currently written.

I'm sortof in the middle of cleaning up my dev setup here, but I'll do some pull reqs from now on if I find anything else interesting.

[bernhard]

Hey @gornycreative thx for the reports! I've just pushed an update that removes all hardcoded /site paths. See v2.1.13

14 hours ago, gornycreative said:

Maybe concat $this->wire->config->paths->root? Sorry I don't have this pulled down in git.

No, not in this case. RockFrontend has the "smart paths" feature so you can simply do $rockfrontend->styles->add("/site/foo/bar.css") and it should work no matter if the installation is in a subfolder or not. It will automatically do what you have suggested, then get the modified timestamp of that file and then use $config->paths->url... to output that style in the page <head> and append the modified timestamp for cache busting. So you'd end up with something like this:

<link href='/project-x/site/foo/bar.css?m=1666772973' rel='stylesheet'><!-- _main.php:10 -->

Magic paths do not work in CSS files of course, so I have fixed those hardcoded /site urls there ? Let me know if everything works now as expected!

[bernhard]

Update: I've decided not to add a merge feature to RockFrontend's asset hadling. The reason is that it has more drawbacks and really not any benefit in 2022, see https://gtmetrix.com/blog/should-i-combine-css-js-files-on-my-website/

But we have an automatic minify feature now ??

https://github.com/baumrock/RockFrontend/wiki/Auto-Minify-Feature

If you enable the auto-minify feature RockFrontend can automatically create and load minified versions of your assets. It does not do it 100% automatically to let you have control over what you which assets you want to minify and which not.

To use the minify feature simply add .min to your asset path:

$rockfrontend->styles()->add("/path/to/your/file.min.css");

RockFrontend will then check if file.css exists. If so it will check if file.css is newer than file.min.css and if that is also the case then it will recreate the minified file using matthiasmullie/minify.

The same applies to scripts()->add("/path/to/file.min.js")

---

Why merging is a problem: One huge problem is that $rockfrontend->styles()->add(...) makes RockFrontend create a file /site/templates/bundle/head.css

Now what if we added a merge feature? How would we call that file? Because on every single page the content of that file could be different, as on some pages there might have been styles added (eg map.css and map.js for a web map) and on others we don't have to add those assets. If we merged all into a single file we'd have to find a way to create different merged files and manage them and make sure to import the correct one.

No. That's not good.

Especially as with HTTP2 there is no reason for merging files. Quite the contrary, as browsers seem to perform better in general if assets are split into chunks rather than one huge file.

 

[bernhard]

Be sure to checkout the new grow feature ?

 

[Stefanowitsch]

The grow feature looks promising. I know that in another thread we discussed the responsive font handling and I was hoping that I could use boostraps RFS feature for responsive fonts:

https://getbootstrap.com/docs/5.2/getting-started/rfs/

I used this feature in my latest project. But it turned out in reality that some of my big headlines just did not shrink the way that I needed them to shrink. It resulted in ugly link breaks. So i needed to make custom font size adjustment via media queries (very oldschool nowadays it seems...)

So can you adjust the "grow-shrink-factor" on this one? To control how much the font will shrink down once a breakpoint is reached?

EDIT: Found a scale factor variable in the depths of the bootstrap files. Anyway I find this is an important value that someone might want to tinker with, it should be possible to adjust it via a value.

[bernhard]

Hi @Stefanowitsch at the moment it scales linearly, but you can define the min and max viewport for that.

I've added a page to the wiki: https://github.com/baumrock/RockFrontend/wiki/PXREM---GROW-(fluid-font-sizes)

Does that explain what you were asking? Or do you want to a custom non-linear scale function (like easing)? That would be possible I think but I'm not sure how practical it would be. Input is welcome.

The scale factor in the code is basically there for RockPageBuilder ? 

 

[maetmar]

Hi @bernhard, 

on an existing page I have upgraded to the latest version of RockFrontend. I went to settings and saved (nothing activated or whatever).

Now the output for anything coming from a .latte file is "destroyed".

the sourcecode of my page in the browser looks like this:

	<!DOCTYPE html>
	<html lang="de">
	<head>
	<meta charset="utf-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<link rel="shortcut icon" href="style/images/favicon.png">
	<title>Home - Website Name</title>
	<meta name="description" content="Website Description for SEO">
	<link rel="stylesheet" href="/processwire/site/templates//assets/css/plugins.css">
	<link rel="stylesheet" href="/processwire/site/templates//assets/css/style.css">
	<link rel="stylesheet" href="/processwire/site/templates//assets/css/colors/ennemoser.css">
	<link rel="stylesheet" href="/processwire/site/templates//assets/css/custom.css">
	</head>
	......   so basically all < and > characters have now been escaped to HTML entities. was there some change in between that I missed? I call the .latte files like this: {$rockfrontend->render('includes/_head')} is this call now wrong and I need to change something? thanks

[bernhard]

Hey @maetmar sorry for the trouble!

12 minutes ago, maetmar said:

was there some change in between that I missed?

I don't know what version you upgraded from and to - there have been several updates and you can see the commit log. But I don't remember anyone that should cause such an issue. But I might be wrong ?  What I usually do in such cases is checking out the module commit by commit and see where the problem starts popping up.

So in your case I'd clone RockFrontend to /site/modules and then use some kind of GIT GUI to checkout step by step. I'm using VSCode + Git Graph Extension:

Then rightclick -> reset current branch to this commit -> hard (discard all changes)

Let me know if you find something useful!

12 minutes ago, maetmar said:

I call the .latte files like this: {$rockfrontend->render('includes/_head')}

is this call now wrong and I need to change something?

From what I see this should still work!

[bernhard]

Look what you can do using RockFrontend GROW ?

.ninifee {
    position: absolute;
    bottom: 0;
    /* right position: 0px on mobile, 150px on desktop */
    right: rfGrow(0pxrem, 150pxrem);
    /* container width that scales the ladybug
     * 100px @ 1000 and grow to 500px @ 1920 */
    width: rfGrow(100px, 500px, 1000, 1920);
}

[maetmar]

21 hours ago, bernhard said:

Hey @maetmar sorry for the trouble!

I don't know what version you upgraded from and to - there have been several updates and you can see the commit log. But I don't remember anyone that should cause such an issue. But I might be wrong ?  What I usually do in such cases is checking out the module commit by commit and see where the problem starts popping up.

So in your case I'd clone RockFrontend to /site/modules and then use some kind of GIT GUI to checkout step by step. I'm using VSCode + Git Graph Extension:

 

Then rightclick -> reset current branch to this commit -> hard (discard all changes)

Let me know if you find something useful!

From what I see this should still work!

adding "|noescape" fixed it.

instead of:
{$rockfrontend->render('includes/_head')}

I used:
{$rockfrontend->render('includes/_head')|noescape}

[bernhard]

But it worked without noescape before? Now that you say it I think there have been changes to that specific feature. But the goal is to get rid of those noescape filters as much as possible (as long as it is safe to do). Could you share more details about your setup? Where do you call that ->render() ? And what are you trying to render? The whole html markup??

[maetmar]

yes it worked before (Rockfrontend Version 2.1.11) without the noescape filters. When I upgrade to 2.7.1, I need to add them.

there is a standard.php that has one line of code:

<?= $rockfrontend->render('./standard.latte') ?>

and the standard.latte looks like this now (the whole main body HTML content is rendered from ProField repater matrix):

{$rockfrontend->render('includes/_head')|noescape}
{$rockfrontend->render('includes/_header')|noescape}    
<!-- Render all Layout Blocks defined in page. Output derived from seperate output files -->
{$rockfrontend->render($page->layout_blocks)|noescape}
{$rockfrontend->render('includes/_footer')|noescape}

 

[bernhard]

Hey @maetmar thx! It's still not enough information, but obviously it's ugly to use all those noescape filters!

I tried on my end and if I put this in _main.php

<body>
  <?= $rockfrontend->render('test.latte') ?>
</body>

Everything works as expected!

Even if I do a {$rockfrontend->render('test2.latte')} in test.latte everything works as expected!

I'd appreciate if you could try to debug and fix this on your end and let me know what you had to do. The code in question is here: https://github.com/baumrock/RockFrontend/blob/71f8021c7333533d2e4e1753747a88648687ca03/RockFrontend.module.php#L1397-L1409

There it decides if it returns $html (where you need noescape) or an HTML object via $this->html($html), where noescape is not necessary.

Thx

[protro]

Any good strategies for avoiding FOUT (Flash of unstyled text) when using Rockfrontend? I am loading the styles as in your video tutorial in the <head>:

$rockfrontend
->styles()->setOptions(['autoload'=>true])
// ->add("/site/templates/uikit-3.15.10/src/less/uikit.theme.less")
->add("/site/templates/styles/custom.less")

And then before </head> I import the Google Fonts

<!-- fonts -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?&family=Major+Mono+Display&family=Oswald:wght@200;300;400;500;600;700&family=Silkscreen&display=swap" rel="stylesheet"> 

Wonder what some possible solutions would be. I tried display=block but that causes layout inconsistencies on page load. Any solutions or techniques much appreciated.

[maetmar]

21 hours ago, bernhard said:

Hey @maetmar thx! It's still not enough information, but obviously it's ugly to use all those noescape filters!

I tried on my end and if I put this in _main.php

<body>
  <?= $rockfrontend->render('test.latte') ?>
</body>

Everything works as expected!

Even if I do a {$rockfrontend->render('test2.latte')} in test.latte everything works as expected!

I'd appreciate if you could try to debug and fix this on your end and let me know what you had to do. The code in question is here: https://github.com/baumrock/RockFrontend/blob/71f8021c7333533d2e4e1753747a88648687ca03/RockFrontend.module.php#L1397-L1409

There it decides if it returns $html (where you need noescape) or an HTML object via $this->html($html), where noescape is not necessary.

Thx

sorrry but I am not a big help in debugging this. For now I will live with the extra |noesacpe filter. not nice but no show stopper for me.

[bernhard]

@maetmar I'm quite sure it's just a small thing and since I can't reproduce the issue on my end you could help me a lot in improving the module (for everybody).

It would already help if you could provide the output of 

Debug::backtrace()

for the file in question below the line with the $cache variable here: https://github.com/baumrock/RockFrontend/blob/71f8021c7333533d2e4e1753747a88648687ca03/RockFrontend.module.php#L1400

[maetmar]

@bernhard, thanks with the latest version you provided it works now.

[maetmar]

Now I want to add the first time the Formbuilder ProModule from Ryan together with RockFrontend latte files.

One option to do this is normally you put these lines of code in your template:

<?php echo $form->styles; ?>
<?php echo $form->scripts; ?>
<?php echo $form; ?>

I somehow can not manage to get some output within a latte file.

How do I properly run some PHP code within latte? I tried the below and nothing works / produces some output:

{$form->scripts}
{do $form->scripts}
{php $form->scripts}

using the tag "echo" is not allowed within latte, at least I get some exceptions.

thanks again for any help / input

[bernhard]

RockFrontend does really not care what you output. But if you have troubles with latte files you can still include PHP files from your latte templates:

{$rockfrontend->render('forms/yourform.php')}

The only thing necessary might be to add the |noescape filter when rendering HTML markup in latte files