Leaderboard

I don't know when I last found a tool for my daily work that had such a huge impact as Latte. The last one was ProcessWire I guess (which had an even greater impact of course, but still). Latte uses PHP syntax so you don't have to learn a new language! It plays extremely well with the PW API and it makes my markup files so much cleaner and easier to read and maintain I can't tell you. From time to time I stumble over situations where I'm once more impressed by latte, so this thread is intended to collect small latte snippets to show how one can use it. If you want use Latte for your ProcessWire projects you can either install it via composer or you wait some more days until I release RockFrontend - a frontend module that can render latte files and comes with several other nice frontend helpers ? ----- Breadcrumbs the Latte+PW way: <ul> <li n:foreach="$page->parents()->add($page) as $item"> <a href="{$item->url}" n:tag-if="$item->id != $page->id"> {$item->title} </a> </li> </ul> The cool thing here is that the last item (the page we are currently viewing) is NOT linked. The <a> tag is only rendered for all other items. Still the label of the link is rendered, because we are using n:tag-if and not n:if ----- Output an image, but only if it exists: <img n:if="{$page->yourimage}" src="{$page->yourimage->maxSize(400,300)->url}" alt="..."> Note that the ->maxSize() call will NOT throw an error even if you didn't upload an image! This is one of my favourite features of latte: Write the markup once and then add simple instructions directly within that tag. No more if/else/foreach chaos ?

sorry, me again, I hope you appreciate the feedback. In an upcoming version, could you add the page-ID of the image when listing (or detail view) of an image in the MM? I can see title, name, dimensions, filesize, tags, … but no ID.

This week I've done some work on the core $cache API (WireCache) to make it able to support other cache storage options. To do that, I had to move all the storage code out of the WireCache class and into a separate class that implements the new WireCacheInterface. So it was kind of a major refactor. Now the WireCache class is independent of storage method, which will make it more flexible in the long term. The first class that implements the new interface is the new WireCacheDatabase. This contains the cache database-storage code that was previously in the WireCache class. But the plan is to also add a WireCacheFilesystem (in progress), and make it possible for others to develop WireCache modules, perhaps for Redis, Memcache, etc. I've been wanting to do this because in some cases I've noticed significantly better read performance from file-based caches. (Though admittedly, at the expense of write performance.) But it made me think it would just be better to have more cache storage options, and also be nice to take advantage of even better cache options available in different environments, like in the AWS environment we run this site on. One of the issues with changing the cache used by the system is that the $modules API (Modules class) depends on WireCache for quite a few things. And the modules basically can't load without the relevant caches being available. At present, $cache has to load before $modules, which makes the whole idea of WireCache-modules a bit of a chicken-or-egg first situation. So I've been working to decouple $modules from WireCache, or at least make it able to function if its cache isn't available on occasion. I made some good progress there, but found that there was a little bit of a performance hit in doing so, so I reverted those changes and put them behind a toggle in the Modules class to experiment with further. But while doing that, I found some other ways to improve the performance of the modules loader. So you'll find the dev branch boots a little faster this week. Maybe not noticeably so (since PW already boots fast), but measurably so. I'm always looking for opportunities to improve performance — even small performance improvements amount to large savings over time. While on the topic of caches, I've also added an experimental $pages->loader()->findCache($selector) method which works exactly like $pages->find($selector) method, except that it caches the page IDs that were found for a period of time that you specify in the 2nd argument (default is 60 seconds). I imagine this method would be useful for complicated or slow page finding operations that don't need to restart from scratch on every request. This is an alternative to markup caching for greater control. But since it caches the result of the find operation (page IDs), and not the actual pages, it has a different set of benefits (and drawbacks) relative to markup caches. I'm still experimenting with this method to get more feedback and make sure it's worthwhile, so far it appears to be. This will likely become accessible at $pages->findCache() once out of the experimental stage. That's all for this week. Thanks for reading and have a great weekend!

I'm both embarrassed to say that I didn't even realize this was here (despite it being front-and-center in the UI) and elated to discover it today thanks to this sentence. ♥ PW has so many (amazing) things included, it's hard to keep track. Even though you've built it all, I'm surprised you're able to keep track of them all too!!

I tried this approach but I get Value set to field 'mema_images' must be a MediaManagerArray (mema_images being the field of type "MediaManager" on the template for the pages where I want to "add" images or technically speaking refer to the image-pages)

It's pretty easy to implement that without a module. Create a page reference field and add it to all applicable templates. Let's call it 'redirect_page'. In your prepend template file, add a little snippet of code that checks if redirect_page is set and issues the redirect if it is. <?php if($page->redirect_page) $session->redirect($page->redirect_page->url);

SiLooks like if I was lucky 😉

Hi @bernhard , yes I agree, we can leave it as it is. And in the case if there are more issues in the future we can consider the transition 😉.

Hi @Richard Jedlička thx for the update! Sorry for not replying to your request. I wanted to suggest taking the module under my control, but then I thought it might make more sense to create some RockMigrations tweaks instead. But I think your module is really useful and complete as it is (now with the fix 😉 ) and I guess it will work like this for a long time without any necessary maintenance, so I think there is no real pressure in changing anything. Or do you see that differently?

YESSSSSS... A million thanks, also for the quick response!

could you please also add the option: Exact as processed filename (I mean without any case changes) to:

Thanks for chiming in @Robin S - I was out when I replied above. Good point about reporting vs causing. Also, in case it helps, I do on rare occasions see lock errors in PW even without SessionHandlerDB. PS - That issue you pointed to is unfortunately not fully solved - I am still hoping Ryan might provide a better solution for that string issue.

Are we sure Tracy is causing the error as opposed to only reporting the error? As in, maybe the session lock times out regardless of whether Tracy is installed, but without Tracy installed you never learn about it. The timeout is a configurable setting in SessionHandlerDB so maybe the solution is that if you expect to run tasks that can take longer than the 50 second default you increase that setting, or if the long task is triggered by your own code do a $session->close() immediately before the task. Or is the sort of exception thrown by SessionHandlerDB when the lock times out supposed to be more silent? There was a Tracy issue similar to that but it was fixed a while back: https://github.com/adrianbj/TracyDebugger/issues/58

This looks so much cleaner and easier to use than the current version. The context menu looks very nice already. The other elements could need some more polishing - I know that's not been a priority yet, still you asked for feedback 😉 Some things I noticed on the video - a breadcrumb navigation should be visible to reflect the directory navigation (when you click on people it disappears, when you click on "men" it should show People > Men) - the selected category and parent categories should be visible (when you click the "men" category nothing is active) (it would probably look nicer to use bold text instead of green) - the spacings and alignments look a bit off. Some inspiration: https://demo.filerun.com/?username=admin&password=admin and the screenshots below

Hi @franciccio-ITALIANO I suppose url_bg and box_url_img_SX both are image field. If it is the case, your code should be like <script src="<?= $page->url_bg->url ?>"></script> or: <img style="padding-left: 15px;" src="<?=$page->box_url_img_SX->url ?>" alt="<?=$page->box_img_alt1?>"> Gideon

Hi Boost, Yes. You can enable multi-language later. Gideon

Just stumbled over this... https://www.slant.co/topics/5409/~php-cms

@bernhard you might want to check this one out as it works perfectly well with the free ChatGPT 3.5 (GPT 4 is acting weird with this prompt). https://flowgpt.com/prompt/qGQmSnF-MDsfhDhpfzZEM Copy the whole prompt Send it and wait a moment Explain what you want to accomplish Answer questions or add details if needed Ask GPT to write the code You have to get used to it as it's quite verbose sometimes.

@bernhard Usually ProfilerPro would be great for this, but in some cases I can't use it because ProfilerPro is a module and I'm timing something that happens prior to modules loading. When PW is in debug mode, it times all of the boot processes, so I can just look at those. I also add other Debug::timer() calls as needed to time specific things. When testing in the admin, you can finish a timer with Debug::saveTimer($timer); and it'll show the result in the Debug > Timers section of the admin. But you can't look at any one instance of a timer. You've got to take several samples before you really know if there's a trend in the numbers. I'm usually looking for consistently 10 ms or more when it comes to improvements. @Ivan Gretsky The cache supports an expiration flag represented by the WireCache::expireReserved constant. It means that rows with that flag are reserved and should never be deleted. If you use the $cache API to clear the cache, it'll do it in a safe way. But if you just omit the caches table from a DB dump or manually delete all the rows in the caches table, then it would be problematic. I agree it would be better not to have to consider this. I'm not sure we need to keep that flag other than for modules, so this is one reason why I'm looking to have the modules use some other storage method for its cache. Though if new caching options came along (Redis, etc.) it would sure be nice for modules to be able to utilize that caching method too, so there are tradeoffs. Ideally, the modules would still use WireCache, but be able to recover easily if its caches get deleted, so that's probably what I'm going to work towards, but it's not as easy as it sounds. @teppo Sounds great! I have no experience with Redis but this server seems to have it and I've also been curious about it. I really like the idea of dedicated cache systems independent of the DB or file system. I'd definitely like for PW to be able to support them, and am glad to hear you are interested in it too.

Those are awesome news for us! We've had a long standing problem with moving ProcessWire installations from one server to another concerning the caches table. It would be great to completely decouple the modules cache from the user generated cache. Maybe move the modules cache to a separate db table. It seems intuitive (and most administrators seem to take this as granted) that you can simply purge the caches table to reduce the database dump size. But it is not like that ATM. Just had this problem yesterday with an experienced ops engineer, who doesn't have any PW experience... so your are magically right on time @ryan, as multiple times before!

My post above actually does what @Pete described but not what the title of this topic says. Needed to remove a submit action today so the latest dev version of RockMigrations now has this if the page is a magicpage: public function editForm($form) { $rm = $this->rockmigrations(); $rm->removeSubmitActions(['next', 'exit']); } 😎

Just an FYI for everyone who may upgrade to the latest PW dev version today. If you make use of AOS's excellent "Add button to check/uncheck all checkboxes" feature, it will break the top level menu dropdowns in the PW admin (and maybe other JS). The fix is to replace: ("[data-no-checkall-checkboxes="1"]") with: ([data-no-checkall-checkboxes="1"]) in: /site/modules/AdminOnSteroids/scripts/aos.min.js

After all the research I have done on how we can train chatGPT specifically for ProcessWIre, I came to realize that it knows already knows PW and its API quite well. I experimented with prompts to make GPT-4 into a PW specialist. This is what I came up with and what seems to work really well: This primes GPT-4 and brings really good results when asking further questions. This example shows that it knows a lot about the API in detail: Q: Are you aware of the ProcessPageClone class and its methods? Not bad at all 🙂 What I'm still having difficulties with is prompting copilot, tabnine or codeium to give me PW specific code. But thats a different story...

Sorry for the delay — Combo field is now supported in SearchEngine 0.31.0. The end result should be very similar to that generated by @xportde modification to Indexer, but I decided to implement it in a slightly different way. Let me know if you run into any issues with this solution, though. Just trying to figure out an approach that would/could work for other, yet unforeseen fieldtypes in the future ?

@dotnetic I picked it up after developing our API in Slim and looking at some best practices. It would be really great if this was the ProcessWire default.

HTMX is quite good. $config->ajax won't detect HTMX requests though, so I recommend adding this to your /site/ready.php: // if htmx request, DO NOT use _main.php if(array_key_exists('HTTP_HX_REQUEST', $_SERVER)) { $config->appendTemplateFile = ''; $config->htmxRequest = true; } That assumes you are using the Markup Regions output strategy by the way. Use $config->htmxRequest as needed.