All Activity

Ha! I love discovering new stuff like that and then feeling, how did I live without it? I think the tree drawer is only available since one of the later UI themes.

I added the ProcessWire namespace as shown below. This seems to have fixed the wireRenderFile not found and the page now displays. I do not know why it works without that on my localhost. Perhaps it could be something to do with this forum post I found that gave me the idea to try adding the namespace? https://processwire.com/talk/topic/11815-undefined-variable-pw-3-wirerenderfile-use-compiled-file/#comment-109884 <?php namespace ProcessWire; ?> <div id="ajax-content" pw-replace> <?=wireRenderFile('_ajax-home.php', array('id' => $page->id))?> </div>

I know a reasonable amount about the output formatting basics. But I keep finding it behaving unreliably so I'm looking to enhance my understanding, or find fixes. Example: A template ('basic page') contains a Page Table Next (ptn) field. One of the templates in use in the ptn field has a repeater field. I'm rendering with Latte and I wish vars holding Page[Array] objects exposed to my templates to have of(TRUE) Let's say $thePage holds the basic page in question. There's 2 overarching contexts, front and back end. On admin screens pages default to of(FALSE) on front end, of(TRUE) This is already a bit of a problem that need workaround, since Page Table Next renders the front end output in the back end. But the question is, after $thePage->of($bool) what is the output formatting state of: $thePage->ptn->first ? $thePage->ptn->first->repeaterField->... ? It's not reliably $bool. I've sometimes tried to bolster the reliability by also calling $wire->pages->of($bool). But I still find it's not always as expected. In the case of linked pages, as above, how does an instantiated page object know whether its output formatting should be on or off? Where is it inherited from? None of the following appear reliably correct (I could be wrong, there's a lot of combos) It could be from $thePage Page object. It could be from $pages. It could be from the back/front end context. (worst case, since then you have to explicitly call of() on every page you reference which makes a real mess of templating, requiring a temporary variable to store the page so you can make the call before using a property) It could be to do with one of the first two options at the time the referenced page is loaded, which would account for the unreliability in the case that rendering involves a process where of() is called in turn with FALSE and TRUE... Can anyone help? I guess ideally what I'm after is $thePage->setOutputFormattingOnSelfAndAllReferencedPages($bool). (Aside: yes, I'm aware of using $thePage->getFormatted() and getUnformatted() but if you have to rely on these you can't use more convenient formats like ->each() or ->get() etc.)

For those who may have missed it, MarkupJsonLDSchema has undergone some major updates lately in light of the importance of structure data with AI. See for the latest info and d/l info

Ok, we are back in business. Stemplates (Free) is now working more cleanly with the 3rd party module. This won't be an issue again for any other module that relies on template names to function. I had to make a few other changes, but Stemplates is better for it. Here's the updated list: ✅ completely non-destructive ✅ doesn't modify your templates or fields ✅ doesn't touch system templates (admin, repeaters, etc.) ✅ doesn't alter your workflow (if anything, it simplifies it) ✅ free from manual aliases, no mapping files, no rewrite rules to maintain ✅ template files follow your renames automatically (no manual moves, no copy-paste, no backup file shuffle) ✅ third-party modules that reference template names keep working after a rename ✅ API calls using the old template name continue to work transparently ✅ every rename and every config update is logged to Setup → Logs → stemplates so you always have a full audit trail ℹ️ adds a Setup → Stemplates admin page for browsing your folders (purely additive, you can ignore it) ℹ️ writes to the database only when you rename a template, and only to keep other modules' template pickers in sync

Well, just to show that life has a sense of humour. After sitting on Stemplates and testing without problems for weeks, literally 1 hour after posting this, I found an issue. It's more a compatibility issue with a popular 3rd party module, really. Not a huge blocker in itself. It's actually easily fixed manually in the affected module. But the core premise of Stemplates is that you can install it without editing existing templates, modules, or configuration. So this matters philosophically to me. So I'm going to go back to the drawing board a little and see what I can do for the free version before I push this any further. The good news is that Stemplates Pro doesn't suffer the same issue as it uses a different approach.

❤️❤️❤️

Very cool. How difficult do you think it would be to make it multi-site compatible? So that when the structure is like this: /root /website 1 /website 2 /website 3 Each website could get its own analytics. Would it be a major refactor or do you see it easily doable? @Roych

Caveat 01 For transparency, I should note that the only files presenting issues were include files where the path was not absolute. The solution was to change: include("includes/get-widget.inc"); to include($config->paths->templates . "includes/get-widget.inc"); You need to do this for every include and require that uses a relative path. But, it's a one-time change, and once it's updated, the template location does not matter.

Support for sub-agents has been added in version 7, now posted to GitHub. Your primary agent can now delegate to other agents when it deems it worthwhile. They can be more instances of the same agent, or instance of other agent models you've defined in the module configuration. More details further down. This version also adds a public API method for sharing agent configuration with other modules, which was requested by @psy. To get agent configuration use $at->getAgents(); (to get all) or $at->getPrimaryAgent() to get the primary agent. See the README file (near the bottom) for instructions on how to use it. Each of the returned $agent objects also includes an ask() method, for when you want AgentTools to handle the request/response process for you as well: $agent = $at->getPrimaryAgent(); $answer = $agent->ask('What is the capital of France?'); echo $answer; Claude Code both requested and developed the sub-agents feature and I asked it to describe some examples of when/where it might be used:

The imminent dangers of "vibe coding", developer shouldn't "vibe", they should control imho.

Do you happen to know https://daun.github.io/processwire-dashboard/#/ ?? I mean your module looks fantastic! But I feel it's something what could have been added to ProcessWire Dashboard?

Hey everyone. I have a new Module in the works. It's 99.9% 75% ready for general release, but already running on my own sites for weeks. [Edit: see post about bug re. 3rd party module] If you've ever opened /site/templates/ on a project that's been running for a year, you know the feeling. 20-50 PHP with no structure, no grouping - an alphabetical avalanche. I usually get so far by namespacing all my files, but sometimes I wish for more organisation. Stemplates lets you organise your templates into folders. That's real directories on the filesystem - the way you're used to working. So, instead of leaving everything in a flat directory, you can go from this… site/templates/ ├── account-dashboard.php ├── account-billing.php ├── shipping-methods.php ├── shipping-tracking.php ├── blog-index.php ├── blog-post.php └── blog-category.php to this… site/templates/ ├── account/ │ ├── dashboard.php │ └── billing.php ├── shipping/ │ ├── methods.php │ ├── tracking.php └── blog/ ├── index.php ├── post.php └── category.php I've been running it on my own sites without issues for a while, and it takes just minutes to set up, even on a large site. Setup takes even less time if you're using AI/MCP. Even better, Stemplates is: ✅ completely non-destructive ✅ doesn't touch your database ✅ doesn't modify your templates or fields ✅ doesn't change anything in the admin UI ✅ doesn't alter your workflow ✅ free from manual aliases, no mapping files, no rewrite rules to maintain ✅ doesn't touch system templates (admin, repeaters, etc.) It also works with page classes and supports nested subfolders (50 levels tested). Understandably, I was reluctant to mess around with such a fundamental part of my sites, so a few safeguards exist... Migrate one template at a time at your own pace - no big switchover required Your existing flat templates keep working untouched, alongside any you've already moved If a file can't be found in its subfolder, ProcessWire falls back to its normal flat-folder behaviour automatically - the site doesn't break Uninstall cleanly at any time. Stemplates Free is undergoing a slight rework available now DM me for access. Stemplates Pro (coming soon) takes Stemplates even further. More soon, but honestly, Stemplates (Free) will take care of 99% of your new template -> folders world. Thanks for reading! Peter

I have googled and ai-ed about it... We can call that a breaking change or not to our liking. Or holywar about it) My point was if someone downloads the new code to a site with PHP 7 the site will actually break 😎 But 2.0 is better anyway for marketing purpose and community spirit IMHO as it symbolizes the new era for the module)

This looks great @psy. Going to try it out later this week.

You're absolutely right. I know where you're going with this. 😄 Is it breaking? I guess not by definition. It now requires PHP>=8.0, ProcessWire>=3.0.0. So you can't update it on older install, and it's not changing any features or API calls, so it still works with same code when you update. v2.0 would mean it has new features or breaking API changes. This is just a "maintenance" update.

I guess this one deserves v.2.0, as we got Soma 2.0 back and finally ready for action! And it is a breaking change after all)

https://www.rand.org/pubs/research_briefs/RB10014.html "...examines nonviolent...", like: Reposturing bombers within easy striking range of key Russian strategic targets... Reposturing fighters so that they are closer to their targets.. Deploying additional tactical nuclear weapons to locations in Europe and Asia Repositioning U.S. and allied ballistic missile defense systems... The United States might goad Russia into a costly arms race... Lot's of nonviolent means, for sure. And it was all published on Apr 24, 2019. It is not even a secret.

I'm using github copilot now since 6 months to do all sort of testing and playing around with various projects. It offers a lot of the different agents, but it's mainly for use with IDE like VS code. I like it a lot and am always surprized at it's capability. Claude is able to help me A LOT updating a very old big online shop to the latest PW (currently local dev only) It has access to powershell to do db stuff and it understood PW very well without much help or special skills. Tho it's great to have it specialize for PW for sure. So I can't use Claude models and some of the others with my github copilot API endpoint with AgentTools, but it allows me to use gpt-4.1 and gpt-4o for free which is cool for simple stuff like engineering and migrations. I'm testing it locally currently. I now also made an account at Antropic to use that as well in case I need it. I have a local docker environment with php, mysql and apache running in a container. Claude had to adapt the pw-at.sh script quite a bit to make it work. I have no clue about this stuff, but it's working now. Thanks very much for the AgentTools module.

Oh I didn't see that. I was gone for 7 years 😄 Thanks for the heads up.

Welcome back Soma, nice to have you here again, after such a long time.

Ryan did a nice blog post about this a few months back - https://processwire.com/blog/posts/api-variable-best-practices/

Sorry for confusion Soma. I meant that post on Tuesday was my first for a long time. Everything has been running fine with my PW sites for years so I haven't been here and that's what I meant. But now I have this problem ..and others. But for now I am concentrating on solving this one I posted above on Tuesday. I'm going back to basics and trying to find out why it works on my localhost but not on the live server. A clean install of the latest PW 3.0.255 blank site profile does work on the live server. During that I saw that the SQL storage engine is innoDB by default (good thing) but my sites were always myISAM but I think you're right - it shouldn't matter when importing a d.b. The wireRenderFile undefined is strange because I can find the function in the core files on the live server so file is not missing. I will continue playing and report back any progress. Thank you Soma for your interest.

https://processwire.com/blog/posts/multi-instance-pw3/ Not 100% sure it really matters tho you should be fine with global wire(). But Multiinstance PW installation could be an issue in some edge cases with modules that save data. Tho can't really tell for sure in detail. Maybe @ryan would have some more insight.

You posted this thuesday? Not sure what you mean been a while. Not sure about the innoDB, but I don't think it matters unless for some index stuff? Surely not related to your problem I guess. Even tho I don't know what problems you mean.