porl

Well then... I guess I can delete my module haha Nice one, I'd heard of AOS but didn't think to check it for this feature. As I said, I was just playing with it for my own sake and thought that since it was a small change it might be able to be included. Didn't think to use hooks (and to be honest I'm not sure I would have known which ones to use and how to do it in this case). Thanks for the input, happy to learn!

Hi all. I've made a small tweak to the ProcessPageList core module. I like the page actions hover feature but find it a bit fiddly hovering over the page labels. I made a change to (optionally, toggleable in settings) show the actions when hovering over the entire page row. I mostly did this for myself but is there any interest in people using this? I'm not sure it is worth releasing as a full module, as it then would require tracking updates etc. and is just a small change in a couple of files. If there is interest though I guess I could request a pull request (if @ryan doesn't want to just use the diff file below). ProcessPageList.diff

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.

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?

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).

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. 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. 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. 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. 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).

Nice work! Does this module handle subscriptions?

Nice work! I made a Twig module way back as I was doing similar things to what you do here. Since then others have made (far cleaner) Twig modules too and I recommend these for most people. Getting your hands dirty and seeing how relatively straight-forward it is to use Twig or similar engines from scratch with ProcessWire is extremely valuable though - even if you go back to using the modules in the end. It gives a much clearer picture of what is going on (and therefore what could go wrong too). I've started playing with the Latte templating engine recently and love it (though I hate Php's $ style variables and -> style object notations which Latte uses), but Twig will always hold a special place as it was the first templating engine that actually felt good to use and not a chore! Thanks for the great tutorial!

Just found this thread and on my Debian server I have the same values (last one is 86400 but first two are 0 and 1000). Added your config setting in, hopefully this stops the logging out! Thanks!!

Definitely! Started playing with it around 1998 and learnt by busting installs over and over. I have a couple of Windows VMs for work but only fire them up when I really have to. Other than that I am in Linux all the time. Currently running Manjaro on my laptop, with an Arch VM for testing and a Debian VPS for my web stuff. Started off with Redhat, Mandrake/Mandriva, Debian, Gentoo (its first release... STAGE 1 INSTALLS BACK THEN TOOK A LONG TIME) before falling back in love with Debian. Then I used Ubuntu from its first release (2004(?)) up until last year when I needed to reformat my laptop and figured I'd give the Arch style thing a go but didn't have enough time to play around with an Arch install from scratch.

Oh wow, I've just been putting together my own custom dashboard module for a client but this might save me a lot of work!

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

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.

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.

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.

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.

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.

@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

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?

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.

Just saw my site was featured in this week's newsletter! Thanks guys ?

Hi Nicolas Thanks! I'm not usually one for single page sites but I thought it would be an interesting challenge. I sent a pull request just after I made the changes to work with Twig 3. Not sure how my changes would affect compatibility with earlier versions of Twig (I believe they added namespace support to at least Twig 2 but not sure) so I don't know if my changes could be accepted as-is. Having said that, using composer to install the module as is required anyway installs Twig alongside, so the module would essentially come with Twig 3 anyway. I have come across a bug but I don't know if that is related to my changes or not - disabling automatic template rendering made it so I could not have any '%' characters in my templates outside of the Twig tags themselves. Re-shuffling things to allow myself to re-enable automatic rendering works fine though, and I had a deadline so didn't investigate further.

Hi all. Just thought I'd add the updated site I made for the Judo/BJJ club I run. For some odd reason I decided I wanted to try making a single-page website but still use ProcessWire's great page management tools. The site uses the excellent Template Engine Twig module (slightly modified to work with Twig 3) and dynamically builds itself using the page tree (no hard-coded sections). I'm no great designer, but using the above along with Bootstrap 4 and some probably-excessive animate-on-scroll effects I think it looks clean enough to differentiate itself from more standard martial arts websites. Anyways, you can visit the site at http://jkma.club and hopefully enjoy!

Never mind, I refactored the site to be able to use the auto-render function and it solves the issue.

Hi there. Not sure if my problem is specific to the twig engine or to this factory module. If I enable automatic rendering, I have no issues, however if I turn it off (and call the render function as follows), I can't use any '%' character in the template or in Processwire fields. The render function is called like this: $twigVars is just an array I'm passing it (and tested working fine). I have tried using Twig with raw php (no processwire) and the templates render fine (obviously without ProcessWire functionality), so I believe the $factory->render function may be trying to interpret the '%' character in some way. The % character is fine to use within twig tags (including using {% and %}), but anywhere else the method just returns null. I tried replacing these lines with calls to twig directly, which rendered the template fine, however it is unfortunately not a workaround for me as my templates are making calls to other page render functions (this is why I can't use auto render) and those are not getting the php template files called correctly as twig obviously doesn't know about this.