Jump to content
tpr

Module: Template Latte Replace

Recommended Posts

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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@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)?

Share this post


Link to post
Share on other sites

@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

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
  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).

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 🙂

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

11537893-7B92-4D12-A743-298A35CADAE9.png.65f77ed8d9e9fe3021cbfc52bb8176a0.png

254045CF-2891-4653-BD63-BDA2A134AC23.png.4a7c9f8f8332a4d714fad3b43010791d.png

6C23108D-2EA8-4F72-B8DD-30768C80A156.png.ee8464043538f34188b499003f44852e.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By MoritzLost
      This is a new module that provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions.
      The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu:
      Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides:
      An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README.
      Beta release
      Note that I consider this a Beta release. Since the module is relatively aggressive in deleting some caches, I would advise you to install in on a test environment before using it on a live site.
      Let me know if you're getting any errors, have trouble using the module or if you have suggestions for improvement!
      In particular, can someone let me know if this module causes any problems with the ProCache module? I don't own or use it, so I can't check. As far as I can tell, ProCache uses a folder inside the cache directory to cache static pages, so my module should be able to clear the ProCache site cache as well, I'd appreciate it if someone can test that for me.
      Future plans
      If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind:
      Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions!
      Links
      https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory

    • By joshua
      This module is (yet another) way for implementing a cookie management solution.
      Of course there are several other possibilities:
      - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/
      - https://github.com/webmanufaktur/CookieManagementBanner
      - https://github.com/johannesdachsel/cookiemonster
      - https://www.oiljs.org/
      - ... and so on ...
      In this module you can configure which kind of cookie categories you want to manage:

      You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience.
      Currently there are four possible cookie groups:
      - Necessary (always enabled)
      - Statistics
      - Marketing
      - External Media
      All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ...
      When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax:
      <script type="optin" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="optin" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="optin" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="optin" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The type has to be "optin" to get recognized by PrivacyWire, the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision.
      If you want to give the users the possibility to change their consent, you can use the following Textformatter:
      [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie.
      You can also add a custom link to output the banner again with a link / button with following class:
      <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> This module is still in development, but we already use it on several production websites.
      You find it here: https://github.com/blaueQuelle/privacywire/tree/master
      Download: https://github.com/blaueQuelle/privacywire/archive/master.zip
      I would love to hear your feedback 🙂
      Edit: Updated URLs to master tree of git repo
       
    • By David Karich
      Admin Page Tree Multiple Sorting
      ClassName: ProcessPageListMultipleSorting
      Extend the ordinary sort of children of a template in the admin page tree with multiple properties. For each template, you can define your own rule. Write each template (template-name) in a row, followed by a colon and then the additional field names for sorting.
      Example: All children of the template "blog" to be sorted in descending order according to the date of creation, then descending by modification date, and then by title. Type:
      blog: -created, -modified, title  Installation
      Copy the files for this module to /site/modules/ProcessPageListMultipleSorting/ In admin: Modules > Check for new modules. Install Module "Admin Page Tree Multible Sorting". Alternative in ProcessWire 2.4+
      Login to ProcessWire backend and go to Modules Click tab "New" and enter Module Class Name: "ProcessPageListMultipleSorting" Click "Download and Install"   Compatibility   I have currently tested the module only under PW 2.6+, but think that it works on older versions too. Maybe someone can give a feedback.     Download   PW-Repo: http://modules.processwire.com/modules/process-page-list-multiple-sorting/ GitHub: https://github.com/FlipZoomMedia/Processwire-ProcessPageListMultipleSorting     I hope someone can use the module. Have fun and best regards, David
    • By dimitrios
      Hello,
      this module can publish content of a Processwire page on a Facebook page, triggered by saving the Processwire page.
      To set it up, configure the module with a Facebook app ID, secret and a Page ID. Following is additional configuration on Facebook for developers:
      Minimum Required Facebook App configuration:
      on Settings -> Basics, provide the App Domains, provide the Site URL, on Settings -> Advanced, set the API version (has been tested up to v3.3), add Product: Facebook Login, on Facebook Login -> Settings, set Client OAuth Login: Yes, set Web OAuth Login: Yes, set Enforce HTTPS: Yes, add "https://www.example.com/processwire/page/" to field Valid OAuth Redirect URIs. This module is configurable as follows:
      Templates: posts can take place only for pages with the defined templates. On/Off switch: specify a checkbox field that will not allow the post if checked. Specify a message and/or an image for the post.
      Usage
      edit the desired PW page and save; it will post right after the initial Facebook log in and permission granting. After that, an access token is kept.
       
      Download
      PW module directory: http://modules.processwire.com/modules/auto-fb-post/ Github: https://github.com/kastrind/AutoFbPost   Note: Facebook SDK for PHP is utilized.


×
×
  • Create New...