maetmar

@cwsoft, yes got Option 2 working. Also including my custom variables. Regarding Option 1: I tried your proposals to but didn´t get it to work. LATTE is properly installed, otherwise Option 2 would also not work I guess. But anyway. I am happy with Option 2 for my purposes. Thanks

On 11/24/2023 at 2:07 PM, bernhard said:

If you don't need that, don't use it 🙂 

that is exactly what I try to do, find a solution to use LATTE without any of the modules that offer support for LATTE. That is what this thread is about and I didn´t post this in the RockFrontend thread 🙂

From the existing modules that I tried, RockFrontend offers in my opinion the best LATTE support and is the easiest to use. But if I find a solution w/o a module needed, for me that would even be better. So I try to find that out now.

fyi, I used an older backup from the site where I got the issues, and I tried to reproduce the error, but I can not manage to reproduce it anymore. So I take back the statement that it was RockFrontend causing the issues, it might have been also something else.

13 hours ago, cwsoft said:

Bernhards RockFrontend is at a complete different level than my two Latte implementations in this thread. If RockFrontend works for you, you may be better of staying with Bernhards module. It‘s by far more advanced than my code example and offers tons of other handy features like hot reload, translation functions from Latte templates and much more.

I used it for quite some time now. But recently I revisted an older project and wanted to upgrade all modules to the newest versions. When upgrading Rockfront from a very old to the newest version it broke my whole site and needed to restore it. The only thing I really used was LATTE, that made me think about a solution where I am not depending on another module. RockFrontend offers great things, but as said I personally dont need a module to take care of loading google fonts, managing font-sizes, etc. 

16 hours ago, cwsoft said:

P.P.S.: I‘ve refactored a medium site project recently from Delayed Output with default PHP Templates to Latte Templates (slightly modified 2nd setup of my tutorial) in combination with PageClasses. This allowed me to use a simple but powerful MVC approach, which made the entire code much more structured and improved readability a lot. I added the namespace cwsoft to my LatteTemplateEngine class, so it won‘t interfere with other template classes out there in the wild and did some code cleanup. I can provide the updated code if needed. I will stick with this approach for my next projects and see how far I can go with this approach. For now I am very happy with what was possible with this simple approach. 

thanks for your reply. I will try that out.

And yes, I would be interested in the code you mentioned. Always good to see other approaches to learn something.

I wanted to add, that I experience the same (or similar) issue when using TemplateEngineLatte. However, with Bernards RockFrontend this works out of the box

Hi @cwsoft, 

thanks for this tutorial. I absolutely support what you write in the beginning, to have LATTE support without dependencies to any modules.

While RockFrontend is in regards to LATTE supporting and doing everything I need, and it works perfect for that, the drawback is, that it comes with too many things, I don´t need and don´t want to have in my project. 

So I tried out your proposals.

Option 1 ends up with this error: "Uncaught Error: Class "Latte\Engine" not found in site/classes/DefaultPage.php:61"
But Option 2 works without issues. 

I also have a question to you that you might be able to answer.

standard.php

<?php namespace ProcessWire;
echo $website_name; 
echo wire('latte')->renderTemplate('views/standard.latte');

$website_name is defined in my _init.php which is automatically called before standard.php. And within standard.php the value for $website_name is properly available end rendered when the template is called. In the 3rd line I now call the latte template, which looks like this:

latte.php

{$website_name} 

now I get the following warning "PHP Warning: Undefined variable $website_name in .../Latte/templates-views-standard.latte"

What do I need to do to make $website_name also available within the latte template?

thanks

In my templates I normaly call a _init.php file as prepend to initialize / set some variables, etc.

However, as soon as I activate "Enalbe automatic page rendering" in the "Template Engine Factory" Module, this _init.php seems to be nor longer called and therefore my default setting values are undefined and can not be used.

Any Idea how to fix this behaviour?

If I disable this feature, the system still calls my "standard.php" file including the _init.php call upfront. So maybe I could just load the latte template (as I wnat to use the latte extension) from within standard.php ? But I donßt know how to call it properly. 

thanks for any help

will do so.

but could you give me a working example of how to call and render standard.latte from within standard.php?

would be great

In my templates I normaly call a _init.php file as prepend to initialize / set some variables, etc.

However, as soon as I activate "Enalobe automatic page rendering" in the "Template Engine Factory" Module, this _init.php seems to be nor longer called and therefore my default setting values are undefined and can not be used.

Any Idea how to fix this behaviour?

If I disable this feature, the system still calls my "standard.php" file including the _init.php call upfront. So maybe I could just load the latte template from within standard.php ? But I donßt know how to call it properly. 

thanks for any help

thanks, it works that way!

One more thing, I found to get this warning due to PHP 8.2:

Deprecated: Using ${var} in strings is deprecated, use {$var} instead in /usr/www/users/xxxxxxxxxx/site/modules/TemplateEngineLatte/src/TemplateEngineLatte.php on line 139

Does someone have a working example of using LATTE to parse through a Repeater Matrix (pro fields)?

Similar like here: https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/ just using LATTE files instead of PHP

I would like to add my 50cents here as well. I basically agree to what @Stefanowitsch mentioned above.

I love to use RockFrontend for the following reasons: LATTE, LATTE, LATTE then AutoRefresh and thats it for me personally.

I also like to keep all my modules as much as possible to the latest version.
With RockFrontend this means, I get lots of new stuff, which might or might not affects my site (I always need to test this), but which I do not really need most of the time.

Maybe it would make sense to split the module into two parts. RockBackend and RockFrontend where RockFrontend needs to have RockBackend as a dependent module somehow?

I personally find it strange that a module which offers neatless integration with LATTE and auto compiles LESS files also provides scritps for fluid font sizes, animations, downloading fonts to local folders, etc.
I know this is just my personal preference and the way I work, and others will have a different approach here and will use many features of what the module offers.
And by no means I want to criticize Bernhard for the way he develops his module. 

23 hours ago, Stefanowitsch said:

Always interesting how people approach ways to create and manage content in ProcessWire in so many creative and different ways. For handling and sorting different content sections on a page the Repeater Matrix was my go-to module in the past.

Nowadays I use the RockPageBuilder from @bernhard which is far better in my opinion 🙂

RockPageBuilder -> where can I find that? In the module directory there is no such module

regarding overview and handling in the backend, also the Repeater Matrix version looks quite nice for the enduser:

thanks for sharing. 

just fyi. I think you can do something very similar using the Pro Module and Repeater Matrix

thanks for this! Struggling with this since I started using PW

solved with a workaround using module "Custom Inputfield Dependencies"

thanks, it´s fixed now

Hi @bernhard,

I realized that RockFrontend is adding "<div edit=title hidden>title</div>" before the closing body tag, because of line 260 in RockFrontend.module.php (faketag)

Is this used for Alfred? And if yes, is there a way to only output this if Alfred is actually used?

Thanks for checking

Hi,

I have two users. One is an admin (myself) and then a "normal" user, which is my customer using the backend to edit content.

In my templates, I have one field "layout_options", which is from type "select options" where I can toggle with checkboxes the visibility of some other fields (headlines, texts, images, etc.). 
On those other fields I, which I want to toogle with this switch, I simply use this feature described here:
https://processwire.com/docs/fields/dependencies/

This all works fine and looks like the following screenshot.
I actually use this to prepare the available elements in a repeater matrix block and I also use it in the template files to check if a specific layout option should be dispalyed or not.

Later the actual content should be entered by the user, who is not an admin.
To avoid that the user changes the "layout options", I want to hide or better just make this "layout_options" field "read-only" for the normal user.
This is to prevent he is messing around with the layouts and add stuff, which he is not supposed to do.

It also works to do this by using the respsective settings in the access control of the field "layout_options".
However, and now I come to my issue, when I do this and hide it or make it read-only, then also the field dependencies don´t work properly anymore - see below:

I played around with all settings in the access control for the field "layout options", but nothing works. 

Any idea how to solve this?

thanks

@bernhard, still the same behaviour.

I get the error whenever I am not loged into the backend or I open whenever I open the page in an incognito browser window (tested with chrome).

When I am loged in and view the frontend in another tab it works fine.

I tried it on two different installations of processwire and both have the same behaviour.

It´s not a big issue, as I use livereload anyway only during develoment of a new site and it should anyway be turned off once the page is live.

in a nutshell. if you are loged in in the backend as an admin then it works and otherwise you get the error message mentioned above. 

On 11/16/2022 at 3:36 PM, bernhard said:

Then it would be nice to get a step by step guide to reproduce it 😉 

I've seen that error here and then but don't know when it occurs or why. And a simple reload fixes it.

This error does cause issues, because if it occurs then livereload is not working (since it needs the eventstream to work). So if you find anything helpful I'm happy to improve that piece of rockfrontend.

this is what I was able to find out, I hope it helps

if an admin is loged in the backend and you have another tab open with the frontend --> no issue

if an admin is loged in the backend and you have another inqognito window open with frontend --> error

if no one is loged intp the backend and you have any session open with frontend --> error

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.

I got the Formbuilder working now with LATTE.

Actually this works fine with latte: {$form} 

the problem was that I had to put this code into my _init.php: <?php $form = $forms->render('kontaktformular'); ?>

in the documentation of the formbuilder it says put it in _init.php or on top of your template file.
Firs, I put on top of my template file, which did not work, only after putting it into the _init.php it started producing output. But obviously also what Bernhard suggested worked fine.