Jump to content

RockFrontend 🚀🚀 Take your ProcessWire Frontend Development to the Next Level


bernhard
 Share

Recommended Posts

6 hours ago, bernhard said:

Hey @Pavel Tajduš thx for the report. I guess it's a windows issue. It should just convert those paths to urls automatically.  @zoeck has no problems on windows I think?

I had problems with the latest RockFrontend version also under laragon/Windows. But could not analyze it yet exactly what it is (Corona, vacation, etc. ? ).

But the topic paths has always been a problem under Windows ? @bernhard

But on my Mac it works without problems under DDEV.

Link to comment
Share on other sites

RockFrontend got some really cool updates over the last days thx to some inputs from @gebeer! The latest additions improve SVG rendering and finally I found a way to get rid of the need to add |noescape to every alfred() call in latte files ??

SVGs

You can use the render() method to write SVG markup directly to your template file:

// latte
// icon is in /site/templates/img/icon.svg
{$rockfrontend->render('img/icon.svg')}

// php
echo $rockfrontend->render('img/icon.svg');

You can even provide variables to replace, so you can create completely dynamic SVGs with custom rotation angles or colors etc...

{$rockfrontend->render('img/triangle.svg', [
  // replace the {rotate} tag in the svg markup
  'rotate'=>45,
  'color'=>'blue',
])}

// add the replacement tag to your svg file
// img/triangle.svg
<svg style="transform: rotate({rotate}deg); border: 2px solid {color};">...

PS: You can also use $rockfrontend->svg('img/triangle.svg') if you want ? 

  • Like 4
Link to comment
Share on other sites

Hi Bernhard,

I have the following issue with livereload.

I run a test installation in a sub-folder (not the root) - lik "custom-domain.com/processwire"
Now the first time livereload is called it works, cause its called with the proper path "custom-domain.com/processwire/livereload.php",
But the second time it fails with a 404 because the sub-folder is not considered anymore: "custom-domain.com/livereload.php"

Any idea what I need to change? I have mod-rewrite set to correct path, but it must be something else.

thanks

Link to comment
Share on other sites

btw, don´t really need right now, but I realized this has the same issue with sub-folders (same for styles as well):

echo $rockfrontend->scripts('body')
    ->add('site/templates/bundle/main.js')
    ->render();
  ?>

the URL added does not consider the sub-folders. you may want to fix this as well in your next release?

thanks

  • Thanks 1
Link to comment
Share on other sites

sorry, but I have a bit a stupid question. 
If I want to disable loading of styles or srcipts or turn-off debug, but how do I actually achieve this?

the produced HTML says this (see below): but where do I put this exactly. Can I use the config.php in the site folder and what exactly do I need to put in?
I tried a couple of things, nothing worked.

  <!-- DEBUG enabled! You can disable it either via $config or use $rf->scripts()->setOptions(['debug'=>false]) -->
  <!-- autoloading of default scripts enabled - disable using ->setOptions(['autoload'=>false]) -->

what I want to achieve is to have only the autorelead and the LATTE template engine working for me. So far, I don´t need to have all other features. Maybe this can be de-/activated in the configuration of the module in the future? 

  • Thanks 1
Link to comment
Share on other sites

Thx @maetmar for the valuable feedback.

I see that this can be confusing ? Something like this:

<?php namespace ProcessWire;
/** @var RockFrontend $rockfrontend */
$rockfrontend->styles()
  ->setOptions(['autoload'=>false])
  ->add(/path/to/your/file.css)
  ;
$rockfrontend->scripts()
  ->setOptions(['autoload'=>false])
  ->add(/path/to/your/file.js)
  ;
?><!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <?= $rockfrontend->seo() ?>

Does that help? I'm short on time but I'm definitely happy to improve that part ? 

Link to comment
Share on other sites

thanks Bernhard,

What is a bit confusing to me is the fact, that if you don't put "$rockfrontend->styles()...." into your template, it still seems to be somehow called and involved (the fact that I got the comment in the HTML for example). In fact I even got some errors because I did not have it in my template.

So, If I understand you correctly, in order to not use it or turn it off, I still need to put it into the template with the option autoload = false?

Wouldn't it make more sense, to just load/use it if the tag is available at all and in all other cases, it simply is ignored and turned-off by default?

 

Link to comment
Share on other sites

23 minutes ago, maetmar said:

Wouldn't it make more sense, to just load/use it if the tag is available at all and in all other cases, it simply is ignored and turned-off by default?

IMHO no. Did you watch my video about that? The reason why it injects that automatically is to have a standardised way to inject scripts or styles to the frontend. So if one has RockFrontend installed every module can then modify the frontend to its needs. Without having to add something to the readme like this:

"To make the module work, you first need to add this and that and that to your main markup file..."

The ALFRED editor is an example for that, which needs both JS and CSS files to work and then is extremely easy to use (just by calling alfred($page) in your template file).

28 minutes ago, maetmar said:

In fact I even got some errors because I did not have it in my template.

Which errors?

Link to comment
Share on other sites

6 minutes ago, bernhard said:

IMHO no. Did you watch my video about that? The reason why it injects that automatically is to have a standardised way to inject scripts or styles to the frontend. So if one has RockFrontend installed every module can then modify the frontend to its needs. Without having to add something to the readme like this:

 

I did watch the video and then started to try it out, because I like what this module is able to do. Don't get me wrong. This is your module and I am not in the position and its not my intention to criticize it in any way.

From what I can tell until now is that your module seems to be (or will be soon if further features are added) a bit of a "swiss army knife" for front-end development.
So I just thought it would make sense to be able to turn on / off some of the features as not everyone is probably going to use all features at the same time.
But again, this is your module and it's your call how it should work!

Link to comment
Share on other sites

Hey @maetmar sorry it seems you got me wrong! I really appreciate your feedback!! I was just a little short in my answer, sorry for that ? 

I'm happy to improve the module of course. Some things are opinionated of course - but you never know if anybody will use your module at all, so it's just inefficient/stupid to think of every edge case upfront.

But if people want to use the module I'm happy to hear that ? And if they have suggestions for improvements I'm happy to hear them as well of course. So please tell me what error you got so that I can check if that is something that needs to be changed/improved.

20 minutes ago, maetmar said:

From what I can tell until now is that your module seems to be (or will be soon if further features are added) a bit of a "swiss army knife" for front-end development.

That's the goal, yes ? I hate repetitive and boring tasks. And when it comes to Frontend imho there are many of them. This might be partly because I'm more into backend, but still I think the basics like adding fonts from google (gdpr complient) or adding a favicon, or adding a manifest file for better mobile experience, or adding SEO tags etc etc should be easy and fun.

25 minutes ago, maetmar said:

So I just thought it would make sense to be able to turn on / off some of the features as not everyone is probably going to use all features at the same time.
But again, this is your module and it's your call how it should work!

Yeah I agree and I thought I've already said that, just wanted to explain that it might not be the best idea to turn it off completely because other modules could rely on it. So it just needs a little more thinking. And it's easier if I get good reports by the community, so a little more details on your mentioned error would be good ? 

Link to comment
Share on other sites

PS: One goal of the module is to be "zero-setup" and that's why I think some things should be enabled by default. But an option to disable them is of course valid. As another goal is to be "progressive" or "unobtrusive".

Link to comment
Share on other sites

this is one error I can see when activiating your module (I was wrong, its not related to the scripts/css tag), but still something I found:

In my main template I have this entry on top:

<?php 
/* Include Header File */
wireIncludeFile("./_header"); 
?>

when I now activate your module, I see the following error on the very top of the source code that is generated, although it loads and includes _header.php:

  <br />
 

<b>Notice</b>: Undefined index: func in <b>/xxxx/xxxx/processwire/wire/core/WireFileTools.php</b> on line <b>1572</b><br />

when I turn off your module, the error is gone.

 

UPDATE:

if I use your tag instead it works and I guess that is the whole point of using your module to use your render method.

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

 

 

Link to comment
Share on other sites

Hey @maetmar I'm not sure there is an easy way to add this to the module... The problem is that I need to use the render() method of the module somewhere to make a _main.LATTE file work.

But you can easily just use your _main.php file to just render a _main.latte file. I think the module could not make this process any easier, because at least you'd need to adjust the setting of $config->appendTemplateFile which is the same amount of work as just adding "echo $rockfrontend->render('_main.latte')" in _main.php ?

Does that make sense?

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

I want to use RockFrontend and Latte in my first "real" Project, but now I have a question about RockFrontend/Latte:

If I use  $rockfrontend->render() with a .latte file, is it no longer possible to use "normal" PHP inside of the .latte file?

Link to comment
Share on other sites

7 minutes ago, zoeck said:

f I use  $rockfrontend->render() with a .latte file, is it no longer possible to use "normal" PHP inside of the .latte file?

The whole thing about template engines is to avoid PHP ? LATTE is different in that you can still use PHP (which I think is great!), because it actually compiles its templates to regular PHP files. So you can do a lot from within LATTE files, but not everything. So it depends what you want to do?

You can't use foreach, if, else and such as PHP syntax. But for these things you have the latte equivalents and n:attributes.

If you need lots of PHP in your template file you should maybe create a custom page class and put your PHP code in a dedicated method there, that you can then reference in your latte file:

<p>{$page->outputSomething()}</p>

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Just now, bernhard said:

So it depends what you want to do?

I am currently reworking some old templates, and there's some PHP code in it ? 
I was just surprised that the php code is not executed...
But I initially thought I did something wrong ? 

Link to comment
Share on other sites

4 minutes ago, zoeck said:

I am currently reworking some old templates, and there's some PHP code in it ? 

Would be interesting to see the difference (before/after) ?? 

5 minutes ago, zoeck said:

But I initially thought I did something wrong ? 

No. You can execute PHP code like {alfred($page)} or {bd('foo bar')} or assign new variables like {$site->color = 'blue'} but not much more..

Link to comment
Share on other sites

Just now, bernhard said:

Would be interesting to see the difference (before/after) ?? 

When I have a good example ? But it is significantly less code

1 minute ago, bernhard said:

assign new variables like {$site->color = 'blue'}

You mean {var $site->color = 'blue'} ? 
I forgot the var yesterday and wondered why it does not work ? 

Thanks for the infos!

Link to comment
Share on other sites

55 minutes ago, zoeck said:

You mean {var $site->color = 'blue'} ?

No, I mean {$site->color = 'blue'} ? which sets the "color" property of my site module to 'blue' and later I can echo that setting (also in other latte files!): 

<h1 style="color: {$site->color}">foo bar!</h1>

{var ...} does only define a variable in the current latte file. That is a latte thing. What I tried to show is how you can use regular PHP. ? 

  • Like 1
Link to comment
Share on other sites

  • bernhard changed the title to RockFrontend 🚀🚀 Take your ProcessWire Frontend Development to the Next Level

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...