All Activity

Late to the thread, but wanted to add a real-world data point. I run a spirits/wine catalog (~12,000 products) and a chocolate e-commerce store on ProcessWire. Both are in production and both have maintenance contracts attached. What I've found: the "update treadmill" problem simply doesn't exist with PW. Core updates are rare and painless. Module updates — same. That frees up retainer hours for things clients actually care about: new filters, catalog improvements, performance work. My maintenance plans now look like this: Backups + uptime monitoring (minimal time, easy to automate) A fixed block of hours for small improvements, content ops, or feature requests Reduced hourly rate for anything beyond that block The key insight for recurring revenue: clients with active e-commerce always have a backlog of small improvements. The retainer becomes a comfortable way for them to drain that backlog without opening a new project each time. For simpler marketing sites, the retainer is lighter but still justified by the "someone is watching this" peace of mind. SEO and analytics reporting also fit naturally into retainers — especially if you're running something like Plausible and can send a monthly digest.

The structure you want is actually slightly different from what Option #1 describes, but it's achievable. Option #1 assumes all sites share the same web root — the multi-site switching happens via index.config.php in that single root. Your setup (separate vhost docroots) requires a different approach. The cleanest way to do this with separate docroots: In each domain's docroot (/domaintwo/, /domainthree/, etc.) you only need: A symlink (or include-based) index.php that bootstraps from domainone's /wire A site/ directory with its own config.php, templates, modules The trick is the index.php in each secondary domain. Replace it with something like: <?php // /domaintwo/index.php $rootPath = '/var/www/html/domainone'; chdir($rootPath); require($rootPath . '/index.php'); And in each domain's site/config.php make sure $config->paths->root isn't hardcoded — ProcessWire resolves this dynamically, so it usually just works. You also need to copy (not symlink) .htaccess from domainone to each secondary docroot, since Apache serves it per-vhost. No index.config.php needed since routing is handled by vhosts at the server level — each domain already hits its own docroot. So the final structure: /domainone/wire/ ← shared core /domainone/site/ ← site 1 /domainone/index.php ← original /domainone/.htaccess /domaintwo/site/ ← site 2 (own db, templates, modules) /domaintwo/index.php ← bootstraps from domainone /domaintwo/.htaccess ← copy from domainone Each site/config.php points to its own database. Works cleanly without symlinks to /wire (which can cause issues with __DIR__ resolution in some PW internals).

Ahh ok. So 150 million of it is cached and therefore not charged. Makes more sense.

Had to pull the raw data for each session to answer this, but overall about $30 based on their (Z.AI) API pricing and the current free cache hits. I paid around $120 for one year of their Pro plan in a Black Friday deal. That's even sweeter.

What was the cost for that many tokens?

AgeWire has been updated — here's what's new since the original release. Multi-framework support The module now supports four CSS frameworks. You pick whichever one your project already uses: Vanilla CSS — fully self-contained, no dependencies, no CDN required Tailwind CSS — the original experience, 13 themes and 4 animations (unchanged) Bootstrap 5 — renders using native Bootstrap card, btn, form-control and alert classes UIkit 3 — renders using native UIkit card, button and grid components Each framework has an independent CDN toggle. If you already load Bootstrap or UIkit in your templates, just uncheck it and the module won't load anything extra. Security fixes CSRF token is now validated on every verification POST Fixed a bug where ProcessWire would render the full page HTML after the JSON response, causing JSON.parse errors in the browser. The AJAX handler now calls ob_clean() before sending JSON to discard any buffered output Strict date parsing with DateTime::createFromFormat — relative strings like "tomorrow" or "-18 years" are rejected Redirect URL validated to http://, https://, or site-relative paths only Custom CSS field sanitized against </style> injection JS console.log output is now gated behind $config->debug — no noise in production Admin UI The config page is now a two-column layout. General Settings and Framework & Theme are open side by side on first load. The rest (Modal Content, Date Picker, Agreement, Exclusions) are collapsed into logical groups — much less scrolling. PHP 8.2+ The module now requires PHP 8.2 and uses typed return types, match expressions, str_contains, str_starts_with, and unnamed catches throughout. GitHub: https://github.com/mxmsmnv/AgeWire Feedback and PRs welcome as always!

Btw, in addition to the memory/conversation history feature coming in the next version, we're also adding a sub-agent feature, so that your selected agent can launch other sub-agent instances of itself or other agents you've defined. Like maybe you've got different agents that specialize in one thing or another, or cost less for specific tasks, it can launch the best agent for the job. In this case, you've got a main agent that's in charge, but it can delegate tasks to other agents. Example would be using Claude Opus 4.7 for main agent but it delegates to Haiku or Groq or another for tasks that don't need as much horsepower, though that may be just scratching the surface on what's possible.

That's amazing!

Awesome, thanks a lot!

Okay multi-model support is now ready and in the current posted version (v5) of AgentTools: Multi-model support — configure additional AI providers/models beyond the primary; each uses its own API key and endpoint Additional models textarea in module config accepts one model per line in pipe-separated format: model | api-key, model | api-key | endpoint, or model | api-key | endpoint | label; provider is auto-detected from the key prefix (sk-ant-* = Anthropic, all others = OpenAI-compatible); whitespace around pipes is optional; lines beginning with # are ignored Control room collapsible fieldset in the Engineer form with model selector and context options; auto-expands when non-default settings are saved Context selector radio in Control room: All (site maps + API docs), Custom (choose individual items), or None (no extra context, useful for general questions or token-limited providers) There's still about 2-3 hours left on the memory feature, which I don't have today, so that'll be in a day or two. If anyone wants a free AI tool (api key) to use with AgentTools, Groq ("groq" not "grok") seems to do fairly well with ProcessWire: https://console.groq.com/home -- note however that on the "Engineer" screen in AgentTools, you'll want to select "Extra content to include: None" because the free Groq doesn't not accept a lot of data in the submitted prompts. But it can still query your ProcessWire installation for all of that info, so it works just fine.

@wbmnfktr Okay we've got support for multiple models now. I'm just working out some details, but should have the AgentTools version updated today with that feature.

It looks amazing! So much work has been done and so much more is still to come... And then I'll want to make custom blocks and so on. Keep going, it's so exciting!

Context Module v1.4.0 - Pure UIkit Design System 🎨 Complete dashboard redesign following ProcessWire standards! What's Changed 100% UIkit Compliance Removed ALL custom CSS Removed ALL inline styles Pure UIkit components throughout ProcessWire CSS variables for theming Dashboard Components: Cards: uk-card-default / uk-card-primary Tables: uk-table uk-table-divider uk-table-small Labels: uk-label uk-label-success/danger/warning Alert: uk-alert uk-alert-success Buttons: Clean HTML with uk-button classes Visual Improvements: Templates/Fields/Pages: Light cards Success metrics: Brand color cards (green) Adaptive grid: 2 cols mobile, 3 tablet, 6 desktop Automatic light/dark theme switching UI Cleanup: Removed "NEW!" label Removed version footer Removed "Edit configuration" link Consistent spacing and typography Bugfix: Removed duplicate formatBytes() method Why This Matters: ✅ Matches ProcessWire admin design ✅ Automatic theme support ✅ Zero maintenance CSS ✅ Better accessibility ✅ Mobile-first responsive Install/Update: cd /site/modules/Context/ git pull Then: Modules → Refresh

I am now playing with HTMX for building something like that

@szabesz TinyMCE support is on the list! CKEditor conversion was the first priority since it's still widely used, but TinyMCE is the logical next step given it's now the default RTE. I'll add it in an upcoming version. @Sergio Great suggestion! A /md/ URL segment or .md extension that returns the Markdown version directly would make the module much more useful for static site generators, AI pipelines, and content migration workflows. Added to the roadmap.

Thanks for the kind words and the thoughtful question! Just to clarify — Rapid is a ProcessWire fieldtype wrapper around EditorJS, the open-source block editor from the Codex team. The editor itself is their work — my contribution is the PW integration: field storage, server-side PHP renderers, upload handling, and the admin UI. Why I built it: I needed a press release submission system — companies fill in their details, write a press release, pay via Stripe, and it goes to moderation (similar to manufacturingdive.com). The site already used TinyMCE fields across many templates. Giving external users access to those fields was a security risk — one wrong permission and they could edit content site-wide. Creating a dedicated FieldtypeRapid field isolated the editor completely: external users write in their own field, the rest of the site is untouched. So the isolation and the clean JSON output were the primary drivers, not just "try a new editor." On your FieldtypeMulti question — I went with a single JSON column because block order needs to be preserved, EditorJS saves atomically, and I wanted to keep v1 simple. Per-block translation is a real limitation — if that matters to you, FieldtypeMulti might be the better foundation. Would love to see your original implementation if you revisit it.

In Kilo Code there is this: You can set a model for each mode.

Great work! It's exciting to see a solid EditorJS integration for ProcessWire. I actually started working on a similar Fieldtype a few years ago and got it nearly production-ready, but I had to shelf it due to a heavy workload. I’ve recently been re-evaluating whether to pick it back up, especially because I agree that building page builders with PageTable or RepeaterMatrix can become quite complex and difficult to maintain/update over time. While thinking about the architecture, I had a question: Have you considered using FieldtypeMulti instead of a standard Fieldtype? Since EditorJS essentially stores "version" and "time" (which aren't always critical for the PW side), I’ve been wondering if storing each block as an individual entry in a multi-value field would be more efficient. For example, you could store the main block content in a data column and other attributes/settings in a props column. This approach might make it easier to handle multi-language support on a per-block basis within ProcessWire's native logic. I’d love to hear your thoughts on this, though I understand if you’ve taken a completely different architectural path for specific reasons. I’m looking forward to testing your module and providing more feedback soon. Thanks for your hard work on this!

Aider has an interesting “architect mode”, where you can define a “strong” and a “week” models for reasoning and acting. This can keep costs much lower https://aider.chat/2024/09/26/architect.html

Hi guys, I've been working on a full EditorJS integration for ProcessWire and it's reached a point where I'd like to share it and get some testing feedback before calling it stable. GitHub: https://github.com/mxmsmnv/FieldtypeRapid This is a development preview. The core functionality works, but I'm looking for testers on different server configurations and ProcessWire setups before a stable release. Please report issues on GitHub. Why EditorJS instead of CKEditor or TinyMCE? CKEditor and TinyMCE are document editors — they produce a single blob of HTML. That HTML is hard to restructure, style consistently, or repurpose for different output targets (web, mobile, PDF, API). EditorJS is a block-based editor. Every paragraph, heading, image, and quote is a separate JSON object with a type and structured data. This means: Content is stored as clean JSON, not tangled HTML Each block type can be rendered differently per context Easy to add, reorder, or remove blocks without breaking surrounding content Output is fully controlled server-side via PHP renderers — no frontend JS required It's closer in concept to Notion or Gutenberg than to a traditional WYSIWYG. What Rapid does: 17 block types: paragraph, header (h1–h6 with auto anchor IDs), quote, nested lists, table, code, delimiter, warning, checklist, raw HTML, image (WebP convert + resize), file attachments, YouTube/Vimeo embed, alert (8 color variants), toggle/accordion, link preview with OG metadata Inline tools: bold, italic, underline, inline code, marker, link Template API: echo $page->body; // render all blocks echo $page->body->toText(); // plain text for meta/search echo $page->body->renderWith($renderer); // custom renderer 4 CSS frameworks — Vanilla, Tailwind, Bootstrap 5, UIkit 3 Frontend editing — inline editor on frontend for authorized users No build step needed — pre-built js/dist/editor.js included. Requirements: ProcessWire 3.0.200+, PHP 8.2+ Any feedback on installation, rendering edge cases, or block behaviour is welcome!

Thanks Ryan - just starting to play with this now. Remember that for some reason Claude needs to be reminded to add a version check around around curl_close Deprecated: Function curl_close() is deprecated since 8.5, as it has no effect since PHP 8.0 in site/modules/AgentTools/AgentToolsEngineer.php:592

That's what I was thinking about. Like in other tools (Kilo Code Extension in VS Code in the screenshot). With this we come close to OpenClaw and Hermes territory.

I like that idea, maybe a select/drop-down under the engineer prompt box where you can select the model to use? And we should be able to share memory between them too, once it's added.

What about being able to configure multiple models and then selecting the one for each specific task? Planning: Opus 4.x (or GLM 5.1, Kimi K2.5) Workload: MiniMax, Qwen, ... Most plans (I use) support Anthropic-, OpenAI-compatible, and custom endpoints. Right now we have Anthropic and OpenAI available (should cover 90% i guess).

Used Droid (https://factory.ai/) and OpenCode (https://opencode.ai/) in this project for now and they both had no issues at all (besides learning that the project is running in a DDEV environment). Also Z.AI GLM 5.1 and MiniMax M2.7 did a really great job. Not as fast (and by far not as expensive) as Opus 4.6 but planning everything in GLM 5.1, spawning subagents (only really works in OpenCode) with MiniMax that does the heavy lifting and then using GLM 5.1 again to confirm and double-check everything. 🤯