Module: Template Latte Replace

[Mikie]

On 2/20/2019 at 8:36 AM, tpr said:

 I solved it without regex in v0.6.1 and the exact template name is checked. I have only tested it thoroughly so be aware ? 

HI! I've encountered a problem with the above changes, in that $templateFile->page->template->name doesn't work when checking templates called by the TemplateFile class. The test need to be against $templateFile->filename to work properly in all cases. I submitted an issue on GitHub before seeing this recent conversation, just thought I'd come here to notify.

 

[porl]

Added a small pull request to allow the choice to not use a default layout file.

Quickly tested it and it doesn't appear to affect things by default, but blanking out the "Default layout file" field disables the feature so you can go back to manually including any necessary {layout ...} tags as desired without having an overriding default layout.

[porl]

Another small issue - looks like the Tracy Debugger module's console is still being directed through the latte renderer for the consoleCode "template" (works fine in the admin screens but not in front end).

Copied the default list of templates to exclude in the module settings (which includes consoleCode in the list) to make sure it wasn't something I'd accidentally changed, but it still does not work (gives an error locating consoleCode.latte).

As a work-around (if this isn't something that is easy to fix) is there some way I could make a template file for the consoleCode that would "pass-through" the Tracy module's AJAX output?

[adrian]

@porl @tpr - I am not using latte, so can't easily test, but let me know if there is a change I can make to Tracy to help fix this. 

[tpr]

@porl

I don't think there is. The exclude templates feature had caused some troubles in the past, perhaps it would be better to use an include templates feature instead, or some kind of naming convention (eg. basic-page.tlr.latte or .tlr.php, but that doesn't look nice)?

[porl]

@tpr @adrian

I have just made a (very dirty) "proof of concept" change to the code so that in the render hook it checks if the view file (e.g. views/template.latte) exists, and if not then returns to the normal render function as it would for admin templates etc. This way, any template that does not have a .latte view file will be run as normal "vanilla" ProcessWire templates. This might be handy in a lot of other situations too (and could theoretically remove the need for excluded templates and the logic to test if we are trying to render the admin template etc.). Could make for easier porting of an existing site - only running the latte code for templates that have been migrated, leaving the rest of the site running as-is.

Are there any major downsides to this (other than my messy copy/pasted code)? The code is in this commit: https://github.com/porl/TemplateLatteReplace/commit/63ff03059a5278806d5525a1bb8f10fb8e9b3cf1 but I didn't want to do a pull request as it is definitely not the most elegant method of doing this check - just copied a chunk of code from your render latte string function) and there is already my pull request open for allowing for no default layout files.

Let me know what you think - it certainly solved the Tracy console issue at least

[porl]

Just refactored the code a little to remove the redundancy (moved getViewFile to a separate function). I noticed for some reason the line endings were all CRLF on the module file (but seem to be LF for all other files, excepting the .md ones) so I ran it through dos2unix to clean that up. Kept the two things as different commits for clarity of course. Changes are again in my https://github.com/porl/TemplateLatteReplace fork. I've been testing this since the dirty hack attempt early yesterday and so far haven't come across any troubles.

[porl]

Figured since I was on a roll I'd update to the latest latte.

I noticed that it has undergone a bit of a change in the way it is loaded and would prefer to be imported with composer (as does the newer Twig Engine module). I'd rather keep the module self-contained as it already is, so I re-used the old latte.php (with some minor changes) and tweaked a couple of namespace things. All seems good at least on my test site.

My commit history is getting messy now as I've just been pushing to Github as I go, but should now hold all of the above changes.

[tpr]

Thanks @porl, I need to allocate some time to check the updates, which is not an easy task because I'm outside of the PHP world nowadays. It would be great if the excluded templates settings could be eliminated. What I'm concerned is that does it work OK with setting template extension to .latte besides .php as well? Plus since you were changing latte.php, wouldn't that mean update issues?

[porl]

latte.php is no longer included with the Latte download. Not sure why (probably to do with why they chose to make the composer option the main one in the get started guide I think). So I pulled it out of the latte directory and put it in the module directory itself, so now the Latte directory is directly under that (instead of latte/Latte).

I think the logic to bypass latte for any templates that do not have a view file makes the "excluded templates" unnecessary, but I wasn't sure if I just wasn't aware of others' use cases so didn't remove it myself. Not sure how it would play with the template extension being set to latte, haven't tried that option myself.

Unfortunately since I did the update that changed the line endings, the diff will be messy if you look at the difference between my latest commit and yours. If you want to check my code then you may want to do it up to that point between yours and mine and then again check the changes after that point just on mine. That way you can ignore the commit that changed the line endings when looking at how it has changed.

[porl]

Update: Just did a quick test of the template extension as .latte and it seems to behave correctly. Gives an error if the .latte file doesn't exist (which makes sense) but otherwise behaves identically to before. As I don't use this option I'm not sure if that is the intended behaviour.

[porl]

Hmm just had a thought (sorry to spam replies): If you choose the .latte as template extension option, then the only way to have templates not use latte would be to use something like the excluded templates option. Is this a big enough issue to make the excluded templates field still required? Or could we do something similar to what I have done with the view file detection and just have processwire go through its normal process if the .latte template file is missing?

Just tested - with this option on the Tracy debugger console has issues again (this time it has no rendering output rather than an error). Adding it to the excluded templates (consoleCode) field still doesn't help though, so I don't think that field is working for this either way.

[porl]

Just tried out @Mikie's fix for the excluded templates field and it seems to be working. I changed the hardcoded ".php" extension to use $this->wire('config')->templateExtension) instead (so sites with other extensions selected or the use .latte extension option should still work).

Tried with and without the default .latte extension option and the excluded templates field seems to be working.

Oddly enough, the issue with the Tracy console appears to be resolved even without adding it back to the excluded list (yesterday that didn't work with the .latte template extension). Not sure what I've done differently there, maybe it was a weird caching issue or something.

Since I've made a few posts in a row, to summarise the changes I've made:

• Allow for no default layout file (handy if you have a number of very different parts of the site, json "pages" etc.
  • Still works identically if you want a default layout so shouldn't have any downsides.
• Added logic to ignore latte rendering if a view file doesn't exist.
  • Makes most cases of the ignored templates field unnecessary.
  • Makes for easier site migration to latte - keep everything as-is, and you can migrate one template at a time without having to manually put everything in the ignored templates field.
• Added in @Mikie's suggested fix for the ignored templates field
  • This field could still be useful even with my above change, even if just to temporarily disable a template for instance.
  • Changed Mikie's hard-coded ".php" extension to use the templateExtension config option from PW to hopefully make this work in more configurations.
• Updated to latest Latte version
• Replaced CRLF line endings with LF in the .module file as well as README.md and CHANGELOG.md as they were the only files to use this format.
  • This should make any future git diff commands cleaner, especially on non-Windows systems.

I think that is everything I have changed.

All these can be found on my "fork" here: https://github.com/porl/TemplateLatteReplace

[Mikie]

@tpr are you still using this? Seen mentioned elsewhere you weren't doing much php anymore.

@porl nice stuff! Tested here and all working fine. A few more notes if you are mucking around with things...

1. With the below, does it make more sense to have a checkbox that lets you add a default layout file? I know this isn't 100% backwards combatable but the toggle could checked by default.

On 1/30/2020 at 10:13 AM, porl said:

Allow for no default layout file (handy if you have a number of very different parts of the site, json "pages" etc.
Still works identically if you want a default layout so shouldn't have any downsides.

2. Should there be an option to disable automatic rendering, thus needing to call the module and manually render views? I know its less magic but I prefer being declarative about this stuff, this would add some flexibility with file naming and management, plus would solve a lot of issues with other types of files and capturing things.

3. A way to render latte snippets that aren't view files would be nice. Maybe I can call latte directly to do this?

<?php
$tlr = $modules->get("TemplateLatteReplace");
$view->social = $tlr->renderSnippet("partials/social-icons.latte");

4. Should the render hook be Page::Render not TemplateFile::Render as Wanze discusses here for TemplateEngineFactory? Would this move towards fixing any of the render issues? 

• The rendering via template engine is now integrated correctly into Page::render(). You can call the render() method on any page, and the module will render it via template engine. In version 1.x, this is only true for the current page.

5. Errors get logged with reference to the compiled cache file and not the .latte template itself.

Just a brain dump of nice to haves, the module still works great.

[porl]

1. I suppose that shouldn't be too difficult. Is it really necessary? Currently just leaving the field blank disables it, but if you think a checkbox would be clearer then I could try to add that. Not sure if it would clog up the interface though.
2. The TemplateEngineFactory modules allow for this, although I did come across a bug that meant that the templates could not have a '%' symbol in them (outside of the Twig tags). Not sure if that is related to the Twig module or the Factory module though. I wonder how much work it would take to re-use the Twig module and make a TemplateEngineLatte one. And whether or not it would be worth doing - there are some things I like about those modules and other things I prefer in tpr's way of doing it. My original Twig module was pretty unintelligent and not much different to how one would use it manually.
3. Haven't tried that, I have made dummy pages with templates that I render from other pages though. I guess it would be nice to be able to do it more cleanly than that.
4. I wonder if that is the reason I was having trouble using the technique from point 3 I mentioned - I had to explicitly pass $page variables etc. so as to not have the other page's template render fields from the current one. I wonder if it requires a big change, worth looking into.
5. I noticed this one. Can't remember if other modules like the Twig one can generate errors from the template process step rather than the final php output run. Might be a bit beyond my level to work out how to pass those on though (if they even occur - Twig seems to do a lot more processing of its variables before deciding to allow the output to be generated, Latte from my understanding is a bit more directly transpiled).

[porl]

Just made the change to after Page:render. I also removed a few redundant checks:

• template filename being '' doesn't seem possible (tested it with a die(); statement to be sure, but the whole Page:render does not seem to be called if this occurs)
• template name === admin: since we now no longer render any template that does not have a latte view file this seems unneeded.

Hmm.... I did just have the thought though that using the .latte template extension option might conflict with the above logic. I don't use this option and didn't think to check. I'm a bit tired now though so I'll have to play again tomorrow if someone else doesn't test it first (again from my github fork).

[tpr]

Thanks, these seem to be useful updates. I'll try to try things out on the weekend.

I wouldn't mind if somebody could take over this module. I'm doing asp.net and angular things nowadays and I don't plan to go back to php, and I have no time to jump back and forth, unfortunately.

I started a major rewrite that affected filters and macros, namely I built a separate module that contained helper methods that could be used separately and by Latte as well. I added a great number of unit tests (via ProcessNetteTester) but the overall project was halted because of time. I can handle this over as well, though that one is really a time-consuming one ?

[tpr]

I've checked on a site that was using .latte extension and a rather old module version (0.3.7). After the update I had to re-add the admin template check, otherwise I got errors complaining undefined variables, that I set in ready.php.

    public function ready()
    {
	    if ($this->wire('page')->template == 'admin') {
            return;
        }

In theory this could also work:

'autoload' => 'template!=admin',

but unfortunately all pages go 404 because PW doesn't find template files (I guess).

Furthermore there's a simpler way to set fuels, so the entire "fuels" array item in the getDefaultData() could be deleted:

$view->fuel = $this->wire('fuel')->getArray();

I removed the ignored templates module setting and there were no errors. First I emptied and saved it to make sure it's removed from the db.

With these settings this particular site was working OK (Tracy as well). Unfortunately I don't have any other sites locally on my computer to but I can copy prod sites and check (all uses .latte).

[porl]

Hi @tpr

Thanks for checking it! I appreciate you are very busy. Playing with things a bit more today I now understand why you need the !=admin check. When I switched on the .latte template extension option in my test site I didn't realise I was still using a non-empty "views directory" field, which meant that any templates (including admin ones) that didn't have a .latte file in there were disabling the module for that rendering. This meant that I didn't see any issues with the admin side of things at all.

When I emptied the field (which is how I assume your site must be) I got similar issues to what you were describing. Unfortunately I had the same lack of luck as you in trying to get the autoload to not occur for admin files.

I had deleted the admin template check because I thought it would be nice (though unlikely) to allow someone to replace the admin theme with a .latte one should they so choose, but after mucking around a while I can't see a clean way to allow this and since that is such an unlikely use case I figured I'd add it back in as you had to. I even thought it might be a good use of the "ignored templates" field but putting admin in there doesn't help as I can't seem to find a way to get the page's template information before the .latte extension override function in the code. Is there a way to get the page or template information that early? Even doing something like wire('pages')->get(wire('input')->url())->template doesn't work because for some reason admin pages return a NullPage. Other pages return the correct template so I assume there is something different about how admin pages are rendered.

One more thing, I couldn't quite get your changed fuel loading line working - can you show me where you put it? I tried to replace the relevant foreach loop in the ready() function but I got errors about missing page variables etc. and my understanding of that line is that it would result in something like $view->fuel->page etc. Is this correct?

[porl]

Success!

Found this nice little snippet that basically just requires the url. This is similar to how I tried to do it but doesn't require a specific page at the url (some admin urls aren't actual pages which is likely why I got the NullPage issue doing it my way):

if(strpos($_SERVER['REQUEST_URI'], $this->wire('config')->urls->admin) === 0) {
	...
}

Now it works even better - no need to rename admin.php to admin.latte (which was a little annoying as it wasn't a latte file!).

I also made a second commit to remove the ignored templates field as you suggested.

[Mikie]

Hi @porl, I have a functioning TemplateEngineLatte for TemplateEngineFactory module going which covers all my notes above (except the error logging). Figuring out the best way to be able to render independent snippets. So maybe ignore all my comments above. Can send to you if you want, its wip for personal use at the moment, but it works.

 

[porl]

Nice! I was tempted to try the same just to see what was involved. Definitely curious to check it out!

On a side note, can you see if it works with the "auto render" option in TemplateEngineFactory off and with '%' characters in the markup (outside of the latte tags)? I found this bug with the Twig render engine but not sure if it is specific to the Twig module or the Factory part itself.

[Mikie]

Seems to work fine. If you mean the below (also in template filename):

[Mikie]

This set up definitely helps. I am working on a pretty complicated site with Padloper, ProMailer, SearchEngine, LoginRegister and a bunch of other modules that want to render their own markup in different places. Also I am using url segments and query strings all over the place. Disabling auto rendering makes this all much easier to manage.

Eg in screenshots above I am testing the SearchEngine module.  Url /search/ does latte with the rendered SearchEngine markup, url /search/index/ is outputting json of the whole index with different content headers. I don't think this is possible with auto rendering, at least not in my attempts.

[porl]

Looks like it might have been specific to the Twig module then.

Yes, auto rendering is nice and handy but sometimes gets in the way. I made my Judo/BJJ club's site as a single-page website but wanted to keep all the partials separate and combine them dynamically. It was trivial to pull pieces from wherever I wanted with auto rendering off but when I hit that bug (and was on a tight timeline so couldn't dig into it more) I had to restructure to allow the auto rendering to be on. Not as clean but still worked okay. I'd imagine in more complex setups it would be harder to work around if it wasn't an option!