All Activity

PromptWire is now at v1.9 and includes a few new features and fixes. The list below is AI-generated... Diagnostics can run against production The eight read tools (pw_health, the four pw_db_* ones, pw_logs, pw_last_error, pw_clear_cache) now accept site: local | remote | both. Previously site: remote was silently ignored and queried the local database instead. Bulk page push to remote or both pw_pages_push accepts targets: local | remote | both. Pages go in parent-first order so newly-created parents exist before their children try to attach. Pull pages back from production pw_page_pull source: remote fetches a page that was edited directly in the production admin and writes it into your local sync tree, so you can re-edit and push back without touching the live admin. Phantom diffs eliminated from pw_site_compare Page content is now hashed deterministically across environments. Identical content produces identical hashes regardless of timezone, page-array storage order, or whether a date field has an output format set. pw_modules_list Lists installed modules with version, file path, and install state. Pass site: both to compare local vs production install state in one call. pw_users_list Lists users with id, name, email, roles, and any member_* fields. Pass includeAll: true for every non-system field on the user template. pw_resolve Bulk name-to-id lookup for fields, templates, pages, roles, permissions, users, or modules. Translates names into the equivalent IDs on the target site without one round trip per name. pw_inspect_template Like pw_get_template but each field comes back as {name, type, label}. Designed for spotting fieldgroup differences before pushing changes. File inventories include .module files and symlinked module directories Previously the file sync silently skipped any modules developed in symlinked sibling repos. pw_modules_list bugfix (v1.9.1) The default call with no classes filter was returning null class names. Caught during release validation and patched the same day.

Hi everyone I've started a new module called SEO NEO It's a new SEO module built for today's SEO, on today's ProcessWire. I hadn’t planned another module, but I keep returning to the same niggling thought: SEO is too important to our clients' sites (and businesses) to depend on modules that are not being actively developed keeping pace with how SEO works today. So that's pretty much it. SEO NEO will be free. An Ultra/Pro version will follow and include genuinely useful additions for industry professionals. I'll have more soon, but if you have any SEO requests, my DMs are open. Cheers Peter

There is nothing good about imperial 😜

Thanks Adrian! Since you're in Canada — if you ever deal with cross-border shipments to the US or Europe, the unit conversion comes in handy. Canadians get the best of both worlds — metric by default but imperial just across the border. 😄

Awesome - thank you!

Hi @adrian, great question — happy to clarify. Both modules store L×W×H, but the focus is different: FieldtypeObjectDimensions (juergen) — geometry-oriented: auto-calculates and stores area and volume, useful when you need spatial calculations. FieldtypeDimensions (mine) — shipping/e-commerce-oriented. The reason it exists: I've been building a package forwarding platform (think Qwintry-style — customers ship packages to a US warehouse, we consolidate and forward internationally). That platform, AltaPost, never launched at scale, but the logistics logic stuck with me. When I needed a dimensions field for product catalogs in ProcessWire, the obvious missing piece was weight — you can't quote a shipping rate without it. A lot of our shipments went to Europe, so we constantly needed to show the same package in both metric and imperial at once — 120 × 80 × 50 mm / 4.7 × 3.1 × 1.9 in, 1.5 kg / 3.3 lb. That's why the conversion API exists: no manual math in templates. Main differences: Weight field — fourth subfield alongside L×W×H, optional per-field Unit conversion API — $dim->lengthIn('in'), $dim->weightIn('lb') for passing values directly to shipping APIs (GoShippo, EasyPost, FedEx rates) or displaying both metric and imperial simultaneously Normalized storage — always saves in mm/grams internally; changing display unit never requires data migration 28 admin languages — useful when ProcessWire itself is configured with multiple languages and you want field labels to appear natively for each editor If you need area/volume stored and searchable — @Juergen module is the better fit. If you need weight + unit conversion for shipping integrations — this one covers that case.

Hi @maximus - thanks as always! Would you mind giving us a basic list of differences compared to: https://processwire.com/modules/fieldtype-object-dimensions/ so we can make an informed decision about which might be better for our needs? Is it basically just the additional weight subfield? Thanks.

Hi everyone, I made a small fieldtype module for storing product dimensions: https://github.com/mxmsmnv/FieldtypeDimensions FieldtypeDimensions lets you store length, width, height and optionally weight in a single field. It’s mainly useful for product/catalog/e-commerce pages where dimensions are needed for display, shipping or filtering. Supports different units (mm, cm, m, in, etc. for length and g, kg, lb, etc. for weight) and stores values internally in mm/grams. The module also supports multilingual setups — admin field labels are available in 20+ languages and can be configured globally. Basic usage example: $dim = $page->dimensions; echo $dim; // 120 × 80 × 50 mm, 1.5 kg echo $dim->lengthIn('cm'); echo $dim->weightIn('kg'); Selectors: $pages->find("template=product, dimensions.length>100"); $pages->find("template=product, dimensions.weight>500"); More details in the README. Feedback and suggestions are very welcome.

@nbcommunication - my main goal is giving PW module developers a guaranteed way to add a nonce to script calls. I have set up a very strict CSP and I am having to modify some modules to add the nonce. If PW had this it would make life easier. I'd even be ok with a core wireGetNonce() helper function that module authors could use instead of a $config->cspNonce() to define one. I feels really good to have a strict CSP set up - most sites don't seem to bother, or if they do, the restrictions are pretty useless in reality.

Both hard refresh of browser and modules refresh did not help. I'll try a fresh install and see if that fixes it. I tested it on two different setups, but both were on version 4.27.7 before the update.

Hi @androbey - I haven't seen any issues like that, but I wonder if a modules > refresh and a hard reload in the browser might fix it? Also, what version did you upgrade from when it was working ok?

I don't know if this a the right place, but with the latest version 5.0.12 and a recent ProcessWire version, I can't use the console anymore. On ProcessWire 2.0.255 when trying to exec a simple "bd('hi');" the exec takes forever and never finishes, on ProcessWire 2.0.259 I only get an error back ("403: Forbidden CSRF token validation failed"). Is there anything I miss or do I have to make any changes?

Hi Jonathan. It was quite difficult to buy a Mac Mini recently when Open Claw was released. People realised the little machines were quite happy chugging along on local LLMs and they were selling like hot cakes. Is that any interest to you? Have to admit, I like the idea of having a replaceable GPU but not sure my gaming machine would be up for any serious work.

I was experimenting with Ollama using its cloud models the other day, on its $20/month plan. I had good results. For my next project, I am considering using Kimi-K2.6, GLM 5+, and others. You can use Opencode or Claude for it: `ollama launch claude --model minimax-m2.5:cloud`

I use VSCode and have been a subscriber to GitHub Copilot for a few years. I didn't pay much attention to the plan I was on until I started using agentic coding in ~October 2025. I then realized what made GitHub Copilot a ridiculously good value, as others discovered as well, was that it works on a "per-request" billing model. In short, if you knew what you were doing (I didn't realize this fully at the time), you could use a high-end model like Opus 4.5, which costs 3 credits, and if just have it rip for HOURS on a task and it would only cost 3 requests (lower end models would be 1 request). With the cheapest plan on GitHub Copilot, it is (well, now WAS), $10/month which gave you 300 requests. A lot of people took advantage of this... imagine paying $10/month and getting like $5000/$10,000 worth of value (ie, what would be the real cost of per-token billing) out of it per month! Absolutely insane. Microsoft understandably put an end to that last week because they were losing their shirts: https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/ In short, they are one of the first to go per-token/per-usage billing and I suspect others like Anthropic and OpenAI will eventually follow suit. It's only a matter of time given the economics of it all. However as you may know, the Chinese AI labs are extremely competitive with their AI offerings and have both monthly plans and token-based plans (generally 90% less cost) and of course, they release the models outright. Because of what Microsoft did, I've been experimenting with the various Chinese models via OpenRouter (and still using VSCode GitHub Copilot "Bring Your Own Key" which they support), so it's basically the same experience. However there seems to be a lot of advancements in high density, low parameter models (Qwen3.6 27B, Deepseek V4 Flash) which can be run on consumer hardware at good speeds and output that is not far behind something like Sonnet or Opus, or at least catching up quickly. I haven't owned a discreet GPU in many many years (I don't game), but I believe with a RTX 5090 and 64-128GB of RAM, it can be done. Don't quote me on any that however... I haven't dived into this world yet and don't yet have an understanding of all the settings that determine how well an LLM runs and how it affects its intelligence. I'd be interested to hear anyone who is playing with this idea: What models are you using? What hardware? What software are you using to run it?

@monollonom Bingo! 🙂 I was not aware of this config setting. Never used it on any templates. And that said, i wouldn't have investigate in this direction. Especially all source templates do not have this flag set. Maybe it is a good idea to check/set this while adding pages through the API, though. Many thanks, cheers Olaf

When setting $config->advanced = true you can specify in a specific template whether you want the name field to appear in the content tab. Is it maybe your case?

Hi, i used to add pages per API. In only one particular case (structural identical to other added pages) the path settings appears in the content tab ("Inhalt") and not as usual in the settings tab ("Einstellungen") (s.screens). While this is only a display issue,- i am just curious,- anyone a hint what this could be caused by? PW 3.0.222 dev greets Olaf

Good day! I have a module that sets a url hook. But then I have code in site/ready.php that stops page rendering process under certain conditions based on a page being viewed. So I need to modify that condition to include all url/path hooks. How do I do it? I thought of setting a custom $config variable. Or checking for $config->requestPath(). But maybe there is something universal?

Hi @ryan there are a lot of modules I was working on. I began creating them even before the company project itself got underway (these are apps intended for internal use), anticipating what I would need based on the initial requirements and my prior experience with ProcessWire projects. I wanted to avoid conflating module development with the development of the core application itself. That said, this meant I was able to test some of the modules incrementally, as the need arose; however, a significant portion of the project remains to be completed, and there are other modules—on which I performed only limited initial testing—that I haven't actually put into use yet. In fact, they could be considered by the community as proofs of concept, given that I am not strictly a "professional" developer; I'm a graphic designer, and my role within the company is as Webmaster. Nevertheless—thanks to ProcessWire's ease of use—I have spent years implementing tools that assist the various departments in their daily operations. All these modules were built around a philosophy of "Simple": they get straight to the point regarding my specific needs, though I am not sure whether they would prove useful to others. I have never worked with Git or a version control system, nor have I ever published modules before, so I have no idea what the best way to proceed would be; if you could offer me any guidance, I would be very grateful. SimpleWire current modules list: SimpleAsset: Asset management for ProcessWire. Resolves, groups, and renders CSS/JS assets from CDN sources or local paths with cache-busting, SRI, and inline threshold support. SimpleAttempt: Error-first pattern helper for ProcessWire. Returns [error, data] arrays instead of try-catch blocks for explicit, predictable error handling. SimpleAttribute: HTML attribute-based template syntax (.attr.phtml) with pw-* directives, {{ }} interpolation, and file-modification caching. SimpleClient: Fluent cURL-based HTTP client with retry, file download, and concurrent pool support. SimpleForm: Programmatic HTML form builder with fluent API and DomQuery. SimpleHelper: GitHub-based utility vault management with local caching, ETag updates, and discovery. SimpleIcon: Tabler Icons renderer with local SVG caching. Supports data URI, inline SVG, and image tag output formats. SimpleQuery: GraphQL-like query engine (WireQL) for ProcessWire pages with caching, rate limiting, and write support. SimpleQueue: Background job queue with priority, delayed execution, retry, and LazyCron-based processing. SimpleRender: Template rendering with views, components, partials, JSON, XML, and fragment extraction. SimpleRequest: HTTP request abstraction with input handling, validation, and content negotiation. SimpleResponse: HTTP response builder with HTMX support, redirects, and content negotiation. SimpleRouter: URL routing with pattern matching and caching for ProcessWire. For use as a URL segments engine. SimpleSSE: Server-Sent Events (SSE) helper for ProcessWire. Provides a simple API for streaming real-time events to the browser. SimpleFlow: In planning. A basic visual workflow module for ProcessWire. SimpleHook: In planning. A support module for the SimpleFlow module. SimpleFront: In planning. Islands architecture component framework SimpleAuth: In planning. A thin wrap around ProcessWire user/role/access APIs.

@WireCodex It sounds like a lot of people here would be interested. Is it something where you'd want to make it a public and supported module in the modules directory, or more interested in sharing as a proof of concept?

@AndZyk I was able to duplicate the issue when using openrouter. It turned out that because the openrouter string starts with "anthropic", it was getting interpreted as a line having a "provider" property, which is something that we deprecated, but still supported for backwards compatibility, and so it was causing the properties to get mixed up. I've updated the detection logic so that it shouldn't happen anymore. Thanks .

ProcessTranslatePage 1.5 + 1.6 Two new versions released — improved glossary handling and a second translation provider. 1.5 — Better glossary management The module now detects free DeepL accounts (limited to one glossary) and warns instead of showing an error. Existing glossaries on your account are shown as a dropdown so you can select one manually, and there's a new "Delete glossary" option in the settings that removes it from DeepL while keeping the entries in the language fields. 1.6 — Added Google Cloud Translation option My main motivation here was that I just discovered DeepL has discontinued new free API plans, so Google Cloud Translation is now available as an alternative. Both providers support the same field types and write modes. Setup for Google requires a GCP service account; the full steps are in the readme. Glossary support remains DeepL-only for now, as Google's glossaries require a Cloud Storage bucket which seemed a little bit too much effort for the effect. Locale codes (DE, de, EN-GB, en_gb …) are normalised automatically on runtime now, so the format in the language fields doesn't matter anymore.

@ryan Thank you for the explanation. When I try to enter all values manually in the primary agent: It mixes the values after saving: I cannot leave all fields empty, because then it throws an error. My module config is correct, but ignored because of the primary agent setting. I hope this helps.

Hi @All Module is updated. In Modules listing it say: Version 0.0.0 but it is 9. IDK why. Anyway, module is updated to support multilanguage fields and added some cosmetics to look nicer.