Leaderboard

Hi all! I currently have fun using latte templates within ProcessWire via RockFrontend. After trying for many weeks now, I was finally able to implement some code completion / code suggestions by doing this: {varType ProcessWire\DefaultPage $page} <section class="container"> <div class="row"> <div class="col"> {$page->doSomething()} </div> </div> </section> So, by adding the first line, my IDE (PHPStorm) recognizes the $page variable and gives me code completion/suggestions, e.g. listing all available methods of $page (which in this case has the class DefaultPage). But I had no luck with the ProcessWire functions like page(), config(), etc. – they are not recognized at all by the IDE. Does anyone know how to make an IDE aware of those functions in LATTE? It would be great if one could use LATTE exactly as if one was writing PHP.

There's no direct selector option, but you could get all templates that use the field first, then use those in the selector. Unless you use the field in repeaters or related types, fieldgroup name = template name. $tpls = $fields->get('checkbox_export')->getFieldgroups()->implode('|', 'name'); $ps = pages()->find("template=$tpls, checkbox_export!=1, sort=id, include=hidden, status<" . Page::statusTrash);

Yep, see the first two screenshots in my post above 😁

I have a page that has a two repeater fields. Those two repeater fields have nested repeaters, etc. I want to run a hook after the page has been saved, BUT only after all the repeaters and nested repeaters have been saved as well. If I use addHookAfter on Pages::saved(template=mytemplate), the hook fires after the page is saved, but before all the repeaters and nester repeaters are saved. What's the correct way to do this?

Hi all, when using the following selector, ProcessWire finds all pages, not only those with the CheckboxReversed "checkbox_export" checked. $ps = pages()->find('checkbox_export!=1, sort=id, include=hidden, status<' . Page::statusTrash); foreach($ps as $p){ var_dump($p->title); } As a workaround I added the following condition: $ps = pages()->find('checkbox_export!=1, sort=id, include=hidden, status<' . Page::statusTrash); foreach($ps as $p){ if ($p->hasField('checkbox_export')) var_dump($p->title); } I wonder if there is any "native" selector technique, where you can check if a field exists on a page. Something like "has_field", but that does not exists. At least I found nothing in the docs. Does anyone know the trick, if there is any?

Aah yes, it indeed looks like the error doesn't affect the installation. It seems my wire folder was not copied entirely after moving them, so I removed it and copied it again and now the install is working as it should, even with the javascript error remaining 🙂

Hey Ivan, I'll have to get back to this later, but just wanted to say that this is an interesting idea. I've never really gone further than specifying a different layout file for different themes — so basically they've all had their own layouts, styles, etc. but still shared the same template specific views. And had a shared pool of components and partials. Both of your ideas sound feasible, but I must admint that the overrides/theme folder sounds "cleaner". It would probably be conceptually similar to WP child themes, e.g. you can override some features, but those that have not been overridden are the same as in the "parent theme" — right? That being said, the first one sounds like an easy to implement thing as well. I'll have to take a closer look at the code to be sure.

I get the same error, but I can install just fine. I don't think the dev environment plays a role there, it's the browser running the JS. Why is the error preventing you from continuing? The installation page should still be there. However, you should be able to comment out line 843 in wire/modules/AdminTheme/AdminThemeUikit/scripts/main.js with no ill effects if Safari for some weird reasons prevents the page from working because of the error.

I ended up modifying the module (FieldtypeSecureFile) of Wanze to my needs. Wanze's module doesn't delete the files nor the sub-directories where the files are in. Also, the module didn't work in the latest version of PW. Now it does, but I don't know about the old versions (and I don't care). I left out the download part and the roles, because I don't need that. I'm sure there are some things that could be approved in the code, but it works for me. I can now safely upload and delete files in a directory outside the webroot. Example: /home/username/securedir The link to the module: FieldtypeSecureFile (GitHub)

Hello ProcessWire Community! I'm thrilled to announce that RockCommerce has finally arrived! Some years ago, after building a custom shop solution, I swore I would never create another ecommerce system again. 😅 Yet here we are! After months of hard work and completely rethinking my approach, I'm confident RockCommerce will be a game-changer for ProcessWire ecommerce. I can't wait to see what you'll create with it! 🚀 This video guides you through the Quickstart Tutorial, which was written by @Sanyaissues (THANK YOU SO MUCH!!!) He rose his hand when I asked for beta-testers 💪😎 He had never done E-Commerce before and wanted to understand how it works - so I sent him a copy of RockCommerce and let him play and this is what he came up with!!! Absolutely remarkable! Hat off to him! Docs & Download: https://www.baumrock.com/rockcommerce P.S.: To celebrate the RockCommerce release, I've applied discounts to all module licenses in my shop! If you've had a successful year, this is a great opportunity to invest in yourself and potentially reduce your taxes 😉

I have been able to get it to work. I think it was sneaky syntax that wasn't really clear and easy for me to miss! I think the challenge in our conversation was that it was hard for me to describe more robustly because it ended up being difficult to understand myself. I'll recap. Let's assume I have a file called 'buttons.latte' and inside of it I have a couple of reusable definitions, this goes along with what I was describing earlier- nothing new. {define button-default, $label} <button class="bg-blue-200 hover:bg-blue-300 transition-colors"> {$label|noescape} </button> {/define} {define button-danger, $label} <button class="bg-red-500 hover:bg-red-600 transition-colors"> {$label|noescape} </button> {/define} I can import all of those definitions using {import} and the file name in my templates and other components/partials/files etc. Then I use {include} with a specific name rather than individually from different files. Using {define} and {import} is a little like named exports in JavaScript. {import 'buttons.latte'} <h1>Welcome to the internet cafe, have a Latte</h1> {* ...A bunch of stuff on the page... *} <div class="modal"> <h2>Do you really want to do that?</h2> {* Here I can use include with button-danger instead of including a file like 'button_danger.latte' *} {include button-danger, label: 'OK'} {include button-default, label: 'Cancel'} </div> {* ...The rest of the stuff on the page... *} The problems all started when using an {embed} on the page and then attempting to use an element that was imported, in this case button-danger and button-default. Here's what happens if we create a reusable "modal" that can be embedded and populated using blocks. {import 'buttons.latte'} <h1>Welcome to the internet cafe, have a Latte</h1> {* ...A bunch of stuff on the page... *} {embed 'modal.latte'} {block content} {* The block inside the embed tag is a whole new scope and fails when you attempt to include the buttons imported outside that embed tag *} <h2>Do you really want to do that?</h2> {include button-danger, label: 'OK'} {include button-default, label: 'Cancel'} {/block} {/embed} {* ...The rest of the stuff on the page... *} This was confusing because this {embed} and the content inside the {block} were mixed in with the rest of my template markup so it wasn't easy to catch where the issue was actually occurring. Even with the improved error reporting you added, the error that was shown by Latte by this did not make it clear it was a scope issue so at the time I thought it was because the 'buttons.latte' file was not being included whatsoever. The real story here is that Latte does not provide errors with specific messages for scoping issues. It will just show an error that looks like a file can't be found. HOWEVER. Solution ahoy! The following does work because the {import} is placed inside the {embed} tag so now the elements in 'buttons.latte' are now scoped within that embed tag so they can be included by name. In this example I've left the {import} at the top of the page because that would necessary should you want to use one of the button elements anywhere outside the scope of that {embed} tag. {import 'buttons.latte'} <h1>Welcome to the internet cafe, have a Latte</h1> {* This required that import above for the parent scope *} {include button-default, label: 'Here is a random button'} {* ...A bunch of stuff on the page... *} {embed 'modal.latte'} {import 'buttons.latte'} {block content} {* These work now that the buttons have been imported in the embed scope and can be included by name *} <h2>Do you really want to do that?</h2> {include button-danger, label: 'OK'} {include button-default, label: 'Cancel'} {/block} {/embed} {* ...The rest of the stuff on the page... *} I thought that Latte's scoping rules were specific to files not tags- in this case the {embed} tag. This was really easy for me to miss in a couple of larger Latte files where noticing the {embed}{/embed} scope while surrounded by a bunch of other markup was really not easy to catch, and combine that with the not-so-clear errors, it made it seem like {import} was broken, but it isn't. This is no problem once you add that to your knowledge of Latte. That said, I think that the fact that Latte uses {include} interchangeably for files like "button.latte" and elements created using {define button}{/define} can be a point of confusion. Well, it was for me. So, Latte scope is serious business but errors leave something to be desired 🤣 I've been able to use all of the features of Latte with RFE and it's great. Hopefully my mistake will help others. Thanks as always for your help @bernhard this was a tough one 🤷‍♂️ This is a pretty smart solution! I didn't think about that. I'm still wrapping my head around the Latte === PHP situation. My brain hasn't connected the two yet. Slowly but surely... Since I already had it set up, I'm using the hook RFE provides to access the Latte instance and a custom extension. I posted this above, but I'll mention it here again in case it's helpful for someone to see this info all in one place. (I added a custom filter as well) <?php use Latte\Extension; final class CustomLatteExtension extends Extension { /** * Define functions available in all Latte files * These can be anything ProcessWire related or not, any functions defined here will be available everywhere */ public function getFunctions(): array { return [ 'wire' => fn (?string $property = null) => wire($property), ]; } public function getFilters(): array { return [ 'bit' => fn (mixed $value) => new Html(filter_var($value, FILTER_VALIDATE_BOOLEAN) ? 1 : 0), 'bitInverse' => fn (mixed $value) => new Html(filter_var($value, FILTER_VALIDATE_BOOLEAN) ? 0 : 1), ]; } } $wire->addHookAfter( "RockFrontend::loadLatte", fn (HookEvent $e) => $e->return->addExtension(new CustomLatteExtension), ); That hook in practice does this: // Defining the wire() function above means that you can use it in any Latte file anywhere {wire()->modules->get('SomeModule')} // The $property parameter is a little syntactic sugar that for calling wire() with arguments for a native feel {wire('modules')->get('SomeModule')} // I have a need to output booleans to the rendered markup and it was getting laborious. My use case is outputting to AlpineJS that exists in // Latte templates {var $someVariableOrPageProperty = true} function someJsInYourTemplate() { // This does nothing because you cant echo a boolean to the page and neither will Latte if ({$someVariableOrPageProperty}) { //... } // You can do this, but it gets ugly when you're working with a lot of booleans. if ({$someVariableOrPageProperty ? 1 : 0}) { //... } // With the custom filter. Clean. if ({$someVariableOrPageProperty|bit}) { //... } } Anyway, those are what I came up with and it's working out great for me.

@bernhard I think it's difficult to explain with actual code examples from my project, other than to say that in this case it is more complex than other projects. I would be simplifying my code to match the examples in the documentation. Here's an example of my workaround to use {include} vs. using Latte's {embed} tag. {* Using capture to assign to a variable *} {capture $modalContents} <h2>{=__('Welcome to my humble modal')}</h2> {$page->body|noescape} <hr> {include 'button-primary.latte'} {/capture} {include 'modal.latte', butonLabel: __('Random Details'), buttonType: 'link', size: 'lg', height: 'fit', content: $modalConents} {* Using embed *} {embed 'modal.latte', butonLabel: __('Random Details'), buttonType: 'link', size: 'lg', height: 'fit'} {block content} <h2>{=__('Welcome to my humble modal')}</h2> {$page->body|noescape} <hr> {include 'button-primary.latte'} {/block} {/embed} There are pages with multiple modals and using {embed} just makes use of the Latte features as documented. For me, it's easier to read, provides indentation, and it's useful to see the {block} feature of {embed} would come in handy- especially when there are multiple blocks. So, true- the same thing can be achieved with using {include}, but more complexity starts to feel like it's compounding. Beyond that, I can't really make a case for why embed is better or not, it's just a feature of Latte that has been helpful. Providing specific examples of where the Functions API would be used is less useful than to say that none of the ProcessWire variables or functions work in Latte files included using {embed}. That is why I mentioned the custom hook I wrote to overcome that error in my earlier post. I don't really have a strong preference whether the Function or object API (or anything else) is made available, it only matters if it's going to be implemented. I just need to know if there's any way that this would be available in RFE or if I should just keep managing it using the RockFrontend::loadLatte hook. I guess you're right about it being a preference. When I first talked about the {define} {import} style and the errors I was getting, I didn't think that had something to do with RFE. I didn't know where to start and figured I did something wrong so that's where I was troubleshooting from. I can't really make a case for this other than to say it's just a feature in Latte that works very well for me. So there's only to things I'm struggling with at the moment- Can some form of the ProcessWire API be made available through RPB to files using {embed}? Can it be possible to use {define} and {import} using files as shown in the Latte docs? I think I was too specific in my other response and didn't mean for it to get in the way of what I was trying to say. I posted before coffee this morning. I didn't mean to be poorly communicative or aggressive.

Hey @FireWire sorry to hear that you are having troubles. It seems that you are doing some quite complex stuff. I've never experienced any of these problems - maybe because I keep things very simple! What is "better" is a very subjective thing, but there are two things I want to mention upfront: Instead of listing all API variables you can just pass the $wire variable and then access anything you need in your template from there: // if you passed the wire variable you can do this: {$wire->pages->find(...)} {$wire->modules->get(...)} {$wire->...} // if you passed "page: $page" do this {$page->wire->pages->find(...)} // or this {var $wire = $page->wire} {$wire->pages->find(...)} I guess I don't have these problems because I'm always working with custom page classes, so I most of the time add those things to the pageclass and then I can just use $page->myMethod(). That has the benefit that template files stay very simple and I have all the logic in PHP and not in Latte, which has a ton of benefits. For example you can do this for debugging: // in site/ready.php bd(wire()->pages->get(123)->myMethod()); Or you could access ->myMethod from anywhere else, like in a cronjob etc. If you have your business logic in latte then you have to refactor at some point or you are violating the DRY concept if you are lazy and just copy that part of your logic from the latte file to the cronjob. I'm not sure I can follow... I put this in whatever.latte: {block foo} <h1>Hello World</h1> {/block} {define bar} <h1>Hello World</h1> {/define} {include foo} {include bar} And I get 3 times "Hello World" as expected. {block} does immediately render while {define} waits for the final include Also I don't know why you make things "complicated". When I need a reusable portion of code like for a button, I simply put that into /site/templates/partials/my-button.latte and then I use {include ../partials/my-button.latte} in my latte file. I'm usually always either in /site/templates/sections or in /site/templates/partials. That's it. Sections are full width elements, like hero, slider, breadcrumbs, main, footer, etc. and partials are things like buttons, cards, etc. Having said that I see that there might be potential to improve the experience though. For example we might make the functions api available to all latte layout files or we might make API variables always available. But to make that happen I'd need some easy to follow real world examples and not complex code examples like your specific setup. Also I'm hesitant as I didn't experience any of these "problems" for maybe two years or so. So we have to identify the real problem first. Maybe the problem is only lack of documentation for example.

I came back to the thread to share some experiences and they are very similar to what @sebibu is running into. Latte introduces a lot of challenges with scoping and augments how you interact with ProcessWire. This is most pronounced for me when working with different inheritance types provided by Latte. When working with `include` there is no scope so anything that is added using {include 'file_name.latte'} will have access to the parent variables. This includes $page and $wire. Unfortunately the limitations with Latte is that you can't define blocks inside them, they only take parameters in the {include} statement. This is fine for most applications, but if you have a reusable component, such as a modal where the markup for the modal stays the same but complex contents should be contained in that markup, it would best be served by using {embed} because you can define something like {block content}{/block}. So while variables are available in primary template files, using all available features in Latte starts to lock out ProcessWire. Files included using {embed} are isolated in scope, so anything you want/need available in that file must be passed as parameters or added as rendered content within a {block}stuff here{/block}. This can get laborious for developers that are used to having ProcessWire's global variables and functions available anywhere. From my experience, there are two options. {embed 'file_to_embed.latte', page: $page, wire: $wire, foo: 'foo', bar: 'bar } {block content}waddap{/block} {/embed} You can choose to add parameters to an {embed} file that provide ProcessWire's API. I'm not entirely a fan of this because it feels laborious and if we're just going to have to pass the ProcessWire API into Latte components to overcome the limited scope, then it's just an extra step that ends up adding additional parameters passed to components all over your templates very repetitiously. I'm also used to working around the concept of only providing objects the specific data they are supposed to work with like best practices for dependency injection containers. The second option is to add custom functions to Latte using a hook at runtime. This method allows you to declare functions that will be available globally within all types of Latte reusability methods. Here's an example of a hook file on my current project. I have a dedicated latte_functions_extension.php file where I can declare these in an organized way. <?php declare(strict_types=1); namespace ProcessWire; use Latte\Extension; final class CustomLatteFunctions extends Extension { public function getFunctions(): array { return [ // Latte templating paths 'definitions' => fn (string $file) => $this->createComponentPath('definitions', $file), 'embeds' => fn (string $file) => $this->createComponentPath('embeds', $file), 'imports' => fn (string $file) => $this->createComponentPath('imports', $file), 'layout' => fn (string $file) => $this->createPath('layouts', $file), 'partial' => fn (string $file) => $this->createPath('partials', $file), // Expose ModernismWeekSite.module.php as site() 'site' => fn () => wire('modules')->get('ModernismWeekSite'), // Ensure that wire() is available in all components 'wire' => fn (?string $property = null) => wire($property), ]; } /** * Creates a path for including a component * @param string $file Dot notation subdir and filename, * @return string */ private function createComponentPath(string $componentSubdir, string $file): string { return $this->createPath("components/{$componentSubdir}", $file); } /** * Creates a component file path for a given filename does not require .latte suffix * @param string $templatesSubdir Name of directory in /site/templates * @param string $file Name of .latte file that exists in the directory */ private function createPath(string $templatesSubdir, string $file): string { !str_ends_with($file, '.latte') && $file = "{$file}.latte"; return wire('config')->paths->templates . "{$templatesSubdir}/{$file}"; } } $wire->addHookAfter( "RockFrontend::loadLatte", fn (HookEvent $e) => $e->return->addExtension(new CustomLatteFunctions), ); I've defined a 'wire' function that will be available in every component with a parameter that allows you to use it like you would expect to such as 'wire('modules')'. I have a custom site module so I've exposed that as 'site()'. If you wanted to make it easier to work with modules in your templates and included files you could define a more terse 'modules' function: <?php final class CustomLatteFunctions extends Extension { public function getFunctions(): array { return [ // ... 'modules' => fn (string $moduleName) => wire('modules')->get($moduleName), ]; } } I feel that there is a tradeoff when using Latte in ProcessWire. There are some great features in Latte, but it requires introducing abstractions and feature management to make Latte act like ProcessWire, like manually defining functions. This just means that you'll have to keep a balance of complexity/abstraction vs. using as minimal enough of a approach to keep it sane. The other challenge here is that now there can be a deviation between where the native ProcessWire API is used in Latte and other places where it isn't. So some files will use $modules, and other files will use modules(), and it's not clear whether that's referencing the ProcessWire functions API, or whether it's leveraging Latte's custom functions extension feature. Something to keep in mind when determining how other files will be included/rendered in other files. In my case I have two examples that brought this challenge out for me today. Here's one // Native behavior provided by the module // Does not work everywhere due to scoping in Latte. This caused an issue when trying to embed forms // in a modal within a {block} {$htmxForms->render($page->field_name)} // With one level of abstraction using a custom function // Because this replicates how ProcessWire provides the wire() function natively, the usage feels // natural and predictable, especially for core behavior, but this introduces a lot of verbosity // that starts to make files pretty messy {wire('modules')->get('FormBuilderHtmx')->render($page->field_name)} // With two levels of abstraction in Latte via a custom function // This looks better and still adheres to the syntax of the ProcessWire functions API // The issue is that every native ProcessWire function has to be manually replicated in our custom // functions hook class. Managing this in the long term requires extra work and cognitive load {modules('FormBuilderHtmx')->render($page->field_name)} // With 3 levels of abstraction // This has restored the feel of the variables provided by the module, but again we have to track // And implement them on an as-needed basis to manage them within the context of usage in Latte {htmxForms()->render($page->fieldName)} The level of abstraction you choose depends on how much customization you want vs. how much extra work it will take to maintain simplicity by hiding complexity. The other functions, 'embeds', 'definitions', 'imports', etc. are to overcome the relative paths all over the place in Latte. // In my home.latte file {layout './layouts/main.latte')} {var $collapseNavOnScroll = true} {import './components/definitions/headlines.latte'} {import './components/definitions/event_activity_card.latte')} {block subnav} {embed './components/embeds/event_subnav.latte', eventPage: $page->eventPage()}{/embed} {/block} // ...etc // Becomes {layout layout('main')} {var $collapseNavOnScroll = true} {import definitions('headlines')} {import definitions('event_activity_card')} {block subnav} {embed embeds('event_subnav'), eventPage: $page->eventPage()}{/embed} {/block} // etc. // In RPB blocks {embed '../../../components/embeds/example.latte', content: $block->body()}{/embed} {embed embeds('example'), content: $block->body()}{/embed} This really helps when working with Latte templates that embed components that have nested embeds and imports because the functions are generating absolute paths that Latte can handle. With these functions, I don't have to think about relative paths anywhere. As for the directory structure that I chose that requires the different paths, here's what it looks like: /templates ...etc /components /definitions /embeds /imports ...etc I chose that method because Latte has many different ways of including, embedding, and importing code from other files. It made more sense to organize my code by how Latte treats it. It wasn't my first choice, but this overcomes confusion that I was experiencing when working with all of the files sharing the same components directory. Without this type of organization it can be challenging to because of scoping and how {embed}, {include}, {define}, and {import} behave differently. Some accept parameters, export values, or use blocks, but not all of them do. So having a "modal.latte" component file that provides a {block content}{/block} next to 'button.latte' that doesn't render anything and only exports items created using {define}, next to a file that is only added to a template using {include} that doesn't take parameters or provide blocks had me jumping between files a lot and slows down development checking to see that the file is being used correctly. Just sharing some of my experiences in case it helps anyone else out. If anyone sees anything here that can be done better or if I'm missing out on features that Latte has that don't require some extra steps, let me know!

Does hook fire on Modules::saveModuleConfigData?

The Admin Actions module lets you do this (assuming the fields are not used by a template). It has some pretty helpful features including cleaning up unused fields and templates.

You can match in either the filename, description, or tags via any of the DB-find functions too. $pages->find("files=myfile.jpg"); $pages->find("files%=myfile"); $pages->find("files.description*=some text"); $pages->find("files.tags%=mytag"); One thing to note is that description and tags have fulltext indexes, but the actual filename doesn't. As a result, if you need to perform a partial match on filename, you can only use the "%=" operator.