All Activity

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. The fix is straightforward once you're aware of it, but the danger is you might not be. Everything on the site continues to look completely normal. No errors, no warnings. Something just quietly stops working. The good news is that Stemplates Pro doesn't suffer the same issue as it uses a different approach. 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.

❤️❤️❤️

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

A few tweaks and a major improvement to the d() and db() calls from the Console panel - these now make use of Tracy's Lazy loading option so the DOM is not populated with huge nested objects - it gets generated dynamically as you toggle open each element with the object. This should solve the massive browser slowdown I am sure we've all experienced at times when dumping lots of large objects. This together with the change from localStorage to IndexedDB has made a huge improvement to the Console panel.

That sounds great, thanks! Can you explain about “Replaced global wire() calls with $this->wire() for correct PW3 multi-instance scoping”? I've been using global wire() calls in lots of places and would like to understand if that's a bad thing.

Looking forwarding to trying out the memory feature @ryan Here's something of related interest: https://github.com/memvid/claude-brain I do love this description of the issue: You: "Remember that auth bug we fixed?" Claude: "I don't have memory of previous conversations." You: "We spent 3 hours on it yesterday" Claude: "I'd be happy to help debug from scratch!"

The memory feature is now active in AgentTools and it's enabled by default. I have to say it makes the experience a whole lot better. Also, we've updated it so that agents can now decide what API.md files they want to receive, and whether or not they want sitemaps/schema, rather than is sending stuff the may or may not need. So the "Include extra context" setting in engineer is now removed since it's no longer necessary. More coming by Friday.

Thanks Soma. I've been away from this for a while! Has ProcessWire changed to use other than myISAM ? I just noticed during the install it sets innoDB by default. Would this matter if importing an old d.b saved as myISAM ? I'm getting some very strange problems on all my old projects now