RockFrontend 🚀🚀 The Powerful Toolbox for ProcessWire Frontend Development

[Stefanowitsch]

15 hours ago, bernhard said:

v3.3.0 is out!

So many great new feature - I hope I find the time to write docs for them one day 😞 

v3.3.0 Latest

 

Features

• add view folder feature (dab548b)

Can you explain what this feature does?

[bernhard]

On 8/12/2023 at 11:28 AM, Stefanowitsch said:

Can you explain what this feature does?

Hey @Stefanowitsch thx for the question. I tried, but it's not so easy. The feature has been developed for RockCommerce where I ship a fully working checkout that is both easy to integrate and to customise. All files are in /site/modules/RockCommerce/frontend/... and can be overwritten by placing the same file in /site/templates/RockCommerce

I don't think that this will be very helpful to anybody else, so I thought it's better not to bloat the docs with that feature at the moment.

But I've added docs for the static rendering feature, which can be very helpful for many projects I think:

Static Rendering

Static Rendering is a convenient feature offered by RockFrontend that simplifies the process of developing new websites or features. It provides an alternative approach to generating markup by allowing developers to write static markup for specific pages or components, rather than utilizing multiple includes and delving into the intricacies of the entire project's architecture.

How it Works

If your project is already using RockFrontend's renderLayout() method to generate page layouts, integrating the Static Rendering feature is straightforward. All you need to do is create static markup files and place them within the designated folder: /site/templates/static.

When a user requests a particular page, RockFrontend's Static Rendering functionality kicks in. It examines the requested page's URL and checks whether there is a corresponding static file in the /site/templates/static directory that matches the URL's structure.

For example: If a user requests your.site/foo/bar, RockFrontend will search for a static file located at /site/templates/static/foo/bar.[php|latte].

Benefits

Static Rendering offers several benefits for developers, including:

• Simplified Development: Writing static markup can be more straightforward than dealing with complex includes and understanding the project's full architecture.
• Quick Prototyping: Static Rendering enables developers to quickly prototype ideas without the need to set up dynamic functionality.
• Unique Custom Layouts: With Static Rendering, you can craft highly distinctive layouts for individual pages, allowing you to create designs that stand out from the rest of the website and cater to specific visual and functional requirements.
• Isolation: Developers can work on specific pages or components in isolation without affecting the rest of the application.

Implementation Steps

1. Create Static Files: Write the static markup for the desired pages or components and save them with filenames that match the URL structure. Place these files in the /site/templates/static directory.

2. Access Static Rendered Pages: Once the static files are in place, RockFrontend will automatically use them for rendering when a user accesses the corresponding URLs.

[protro]

Hi @bernhard is it possible to load a <script> tag or to load specific javascript file for only a specific page and/or template using Rockfrontend ? Right now _main.php is handling all scripts site-wide. Was wondering how granular this can go.

Thanks for such a great module.

[Stefanowitsch]

6 hours ago, protro said:

Hi @bernhard is it possible to load a <script> tag or to load specific javascript file for only a specific page and/or template using Rockfrontend ? Right now _main.php is handling all scripts site-wide. Was wondering how granular this can go.

Thanks for such a great module.

As far as I know (and I haven't used this feature yet!) this should be possible (found here: https://processwire.com/modules/rock-frontend/)

You can make use of the addIf() function to load a script only under special circumstances.

Adding assets to your site (JS or CSS)

---

While you can always add custom <script> or <link> tags to your site's markup it is recommended that you use RockFrontend's AssetsArray feature:

$rockfrontend->scripts()
  ->add('/path/to/your/script.js')
  // you can add any custom flags to your $rockfrontend variable at runtime!
  ->addIf('/path/to/foo.js', $rockfrontend->needsFooScript)
  ->addIf('/path/to/slider.js', $page instanceof HomePage)
  ->addIf('/path/to/blogscript.js', $page->template == 'blogitem')
  ;
$rockfrontend->styles()
  ->add(...)
  ->addIf(...)
  ;

There are several reasons why this is preferable over adding custom script/style tags:

• addIf() keeps your markup file cleaner than using if / echo / endif
• It automatically adds timestamps of files for cache busting
• You can inject scripts/styles from within other files (eg PW modules)

RockFrontend itself uses this technique to inject the styles and scripts necessary for frontend editing (ALFRED). Have a look at the module's init() method!

[protro]

very helpful @Stefanowitsch thank you very much for pointing out those different conditions. Another awesome demonstration of Rockfrontend's capabilities 🙂

In my case I spoke too soon and what I was actually attempting to do was to inject code into the _main.php <head> if I was on a certain template / page / etc. But because I am using the ProcessWire $config->urls->templates method to obtain the url for the script via php, I can't do that by loading an external.js file via AddIf … for example:

<!-- threejs code -->
    	<script async src="https://unpkg.com/es-module-shims@1.6.3/dist/es-module-shims.js"></script>
		<script type="importmap">
			{
				"imports": {
					"three": "<?php echo $config->urls->templates?>scripts/build/three.module.js",
					"three/addons/": "<?php echo $config->urls->templates?>scripts/jsm/"
				}
			}
		</script>

But then I came across a section of the Markup Regions in ProcessWire post which explained what I was attempting to do, and for me is a new discovery of ProcessWire 🙂

Quote

The above _main.php represents our common document markup, though if we need something entirely different for any particular templates (like our homepage, RSS feed, or the like) we can do so by editing the template settings in the ProcessWire admin to use a different file, or no file at all, when appropriate. (This is found in Setup > Templates > [template] > Files [tab]).

So what I did was create a _main_webgl.php file and specify in my template to ignore _main.php and load this one instead. Maybe not the most elegant solution, but it is separating the logic nicely and allowing me to not have to load unnecessary scripts depending on the page / template. Very nice!

[bernhard]

49 minutes ago, protro said:

In my case I spoke too soon and what I was actually attempting to do was to inject code into the _main.php <head> if I was on a certain template / page / etc. But because I am using the ProcessWire $config->urls->templates method to obtain the url for the script via php, I can't do that by loading an external.js file via AddIf … for example:

I don't understand what you are saying here. And it sounds totally contrary to what you say afterwards.

RockFrontend's "addIf()" for adding single scripts depending on conditions is one thing, but replacing the whole markup is something totally different.

If you are trying to do the latter you have two options. One is what you describe and make ProcessWire NOT use the _main.php file.

Another option would be to be more explicit in _main.php and put something like this on top of the file:

<?php

if($page->template == 'foo') return $rockfrontend->render('my/custom/markupfile.[php|latte]');

...

// content of _main.php here that will be loaded for all templates except 'foo'

Another concept that RockFrontend provides is the renderLayout() method.

The concept is to put this in _main.php:

<html>
  <head>...</head>
  <body>
    <?= $rockfrontend->renderLayout() ?>
  </body>
</html>

Which will tell RockFrontend to load /site/templates/layouts/default.php by default and load /site/templates/layouts/foo.php for all pages with template "foo".

So you have lots of options 🙂 

[protro]

On 11/16/2022 at 6:29 AM, maetmar said:

Hi @bernhard, 

I found an issue with the livereload feature. When enabled, I get the following error message in chrome development console:

"EventSource's response has a MIME type ("text/html") that is not "text/event-stream". Aborting the connection."

https://stackoverflow.com/questions/53591954/eventsources-response-has-a-mime-type-text-html-that-is-not-text-event-str

It is reproducable, as soon as livereload is turned off, the error message is gone.
The message is not causing any issues, as far as I can tell, but I was spending now a lot of time just to find out it was caused by livereload.
So maybe you can check and make sure it gets fixed.

Hi @bernhard I recently acquired a new work machine and am getting this unexpected EventSource error every 2-3 saves with PW + Rockfrontend. It's driving me mad because I know you are seeking reproducible steps and I can't seem to pinpoint exactly what is causing it, except for editing CSS classes within pre-existing HTML markup is OKAY and livereload is triggered, but addition of new HTML syntax and/or Latte syntax throws the error.

pseudo-Reproducible Steps:

Hardware: MacBook with macOS 13.6.1
Software: VS Code 1.84.0, MAMP 6.8, ProcessWire 3.0.229, Rockfrontend 3.7.0, Chrome 119.0.6045.105

php no longer ships with new macOS versions so I installed via brew install php.
MAMP has its own php 8.2 binary, which I thought I needed to set VS Code's settings.json to:

php.validate.executablePath": "/Applications/MAMP/bin/php/php8.2.0/bin/php",

but that seems to have no effect. Either way, just wanted to bring this to your attention. I am quite perplexed.

[bernhard]

1 minute ago, protro said:

php no longer ships with new macOS versions so I installed via brew install php. MAMP has its own php 8.2 binary, which I thought I needed to set VS Code's settings.json to:

php.validate.executablePath": "/Applications/MAMP/bin/php/php8.2.0/bin/php",

but that seems to have no effect. Either way, just wanted to bring this to your attention. I am quite perplexed.

I fear I don't have any idea for you, but have you considered using DDEV? I think it would be worth trying, because it is such a great and hassle free dev environment and maybe your issue will be solved as well!

 

[protro]

Thanks @bernhard I will check out DDEV.

One last thing I am seeing is this in the Inspector Application Tab

Deprecated:  Creation of dynamic property RockFrontend\LiveReload::$config is deprecated in /Applications/MAMP/htdocs/my-project/site/modules/RockFrontend/LiveReload.php on line 24

[bernhard]

11 minutes ago, protro said:

Deprecated:  Creation of dynamic property RockFrontend\LiveReload::$config is deprecated in /Applications/MAMP/htdocs/my-project/site/modules/RockFrontend/LiveReload.php on line 24

I'm not seeing this. Neither with 8.1 nor with 8.2..