Search the Community

Once a ProcessWire site is live, the production database is not a deployable artifact. It is the source of truth for content, users, roles, module settings, and module-owned data. Deploy code from Git. Apply reviewed migrations to the production database. Preserve production data, uploads, configuration, and secrets. If an AI coding agent is involved, write these boundaries down in AGENTS.md and enforce them with scripts rather than relying on the agent to infer what “deploy” means. I arrived at this rule through a real incident. The incident I was rebuilding a ProcessWire site locally with an AI coding agent. The data model had changed substantially, the development site contained useful demo content, and the production site had little activity. I asked the agent to deploy the new version and replace the old data. Technically, the operation succeeded: the code was deployed; the new schema appeared; the development database was imported; development uploads replaced production uploads; the public pages worked. But a database is not just “content”. The import also replaced production-only module configuration, users, roles, support tickets, AI conversations, and records stored in custom module tables. SMTP happened to survive because its configuration matched in both environments. Other settings did not. Backups existed, so the incident was recoverable. The site also had almost no real activity. On a busy site, the same operation could have destroyed orders, form submissions, member accounts, unpublished editorial work, audit history, or messages created during the deployment window. The important lesson was not “the AI made a mistake”. The deployment process allowed an ambiguous instruction to become a destructive database operation. That is a systems problem. Why ProcessWire needs an explicit deployment model ProcessWire's file layout is deliberately clear: /wire/ contains the core, while /site/ contains site-specific templates, modules, configuration, and assets. The official documentation also identifies site/config.php as the site configuration file and site/assets/ as writable runtime storage. That filesystem separation is useful, but a mature ProcessWire project has another boundary that is easier to miss: Deployment ownership map Git release — templates, hooks, module code, and frontend assets. Source of truth: the repository. Database structure — fields, templates, fieldgroups, and module schemas. Source of truth: reviewed migrations. Production database — pages, users, roles, settings, submissions, and module-owned tables. Source of truth: production. Runtime configuration — database credentials, hostnames, and environment flags. Source of truth: the production runtime. Secrets — SMTP, API, and OIDC credentials. Source of truth: a secret store or protected runtime files. Writable assets — uploads, generated files, logs, sessions, and backups. Source of truth: production storage. The initial launch is special. If production is empty, cloning a reviewed development database may be reasonable. After the first real user, form submission, editor change, or module configuration, that direction must stop. Production may flow to development through a protected and preferably sanitized snapshot. Development must not flow back as a whole database. This is the same problem described in ProcessWire's own article introducing migrations: once the live server receives content while features continue to be developed locally, the databases diverge and changes must be merged rather than replaced. Use releases for code and migrations for change A production release should be an immutable Git commit, preferably accompanied by a tag. Build the deployable file list from that commit—not from the current working directory. A release manifest should include only public runtime code and static assets. It should explicitly exclude: .git/ and CI configuration; AGENTS.md and development documentation; site/config.php and environment-specific config; database dumps, credentials, and private keys; site/assets/files, caches, logs, sessions, and backups; tests, fixtures, local tooling, and editor configuration. ProcessWire fields and templates live in the database, so code deployment alone is not always sufficient. Represent structural changes as idempotent, versioned migrations. A migration may use ProcessWire's API, a migration module, or a project-specific CLI script. The important properties are the same: it has a preview or audit mode; it is safe to run more than once; it changes only named structures or records; it preserves unknown production configuration; large transformations are bounded and resumable; destructive steps require a fresh verified backup and rollback data; successful application is recorded. ProcessWire has community options such as ProcessDbMigrate and migration modules, but no tool removes the need to classify production data correctly. A backup is not verified until it can be restored “The backup command returned zero” is not enough. For every production release: create a timestamped database backup outside the document root; verify its size and checksum; verify compressed-stream integrity; periodically restore it into an isolated database; keep a backup of the exact files being replaced; record the rollback path before changing production. This matters because backup tools can produce syntactically valid-looking files that fail only during restoration. Test the recovery path, not merely the backup button. The official ProcessWire upgrade guide likewise recommends backing up both files and database and testing upgrades on a development or staging site first. Add a fail-closed deployment guard Documentation is necessary, but an executable invariant is better. Before deployment, create a private snapshot containing no secret values: row counts for protected tables; page counts by template; stable page IDs by template; installed module names; names and configured/empty state of module configuration keys; intended Git commit; production hostname; verified backup metadata. After code deployment and migrations, take the same measurements and compare them. Block completion if: a protected table disappeared or lost rows; a pre-existing page ID disappeared; a template or installed module disappeared; a module configuration key disappeared; a configured value became empty; the host or release commit does not match. Stable IDs matter. Row counts alone can miss a replacement database containing the same number of different records. Some legitimate migrations intentionally remove obsolete data. That should be an exceptional workflow requiring a change ID, a table-by-table impact report, a tested restore, and a second explicit approval. A generic “deploy everything” instruction must never authorize it. What to tell an AI coding agent An AI agent is fast enough to turn an ambiguous sentence into a complete deployment before a human notices the ambiguity. Give it a narrower contract. The repository instructions should state: development and production paths and hostnames; production is read-only unless a production change is explicitly requested; commit, push, deploy, migrate, publish, and replace data are separate actions; “deploy” means code-only unless named migrations are included; a development database must never overwrite a launched production database; production users, content, module configuration, custom tables, and uploads must be preserved; secrets must not be read, printed, hashed, copied locally, or committed; every mutation needs a fresh verified backup and exact rollback path; migrations run in preview first and must be bounded/idempotent; a data decrease is a blocker, not a warning; if scope is ambiguous, stop after read-only investigation; destructive approval is two-phase: impact report first, explicit confirmation of that report second; maintenance is not removed and success is not reported while checks fail. The open AGENTS.md format is useful here because it gives multiple coding agents a predictable repository-level instruction file. Its documentation explicitly recommends including build commands, testing, security concerns, and deployment details, and supports more specific nested files where needed. I prepared a reusable template and attached it to this post as ProcessWire-AGENTS-production-safety-template.zip. The archive contains a single AGENTS.md file. Download it, replace the placeholders, and commit it to the root of your project. Do not deploy it into the public document root. A practical release checklist Before maintenance Select an immutable Git commit. Review the diff and release manifest. List every migration and classify its risk. Create and verify database and file backups. Create the protected data snapshot. Write the rollback command/path. During maintenance Deploy only manifest files. Preserve production config, secrets, uploads, logs, sessions, and backups. Run migrations in preview, then apply. Run the fail-closed comparison. Stop on any unexplained decrease. Before reopening Test origin and CDN routes. Test authentication and representative member workflows. Verify email delivery readiness and background jobs. Inspect new logs without exposing secrets. Record commit, manifest checksum, migration results, backups, and rollback. Remove maintenance only when every blocker is resolved. Final principle The database is not “the backend version of the code”. On a live ProcessWire site it is accumulated production state. AI does not change this rule. AI makes it more important to encode the rule in files, scripts, permissions, and fail-closed checks—because the agent can execute a bad assumption much faster than a human can recognize it. References ProcessWire file and directory structure ProcessWire: migrating to production ProcessWire upgrade best practices ProcessWire file permissions and protecting site/config.php ProcessWire: Introduction to the Migrations module ProcessDbMigrate module directory entry AGENTS.md open format ProcessWire-AGENTS-production-safety-template.zip

Hi everyone, I’m releasing Liora, a ProcessWire module that turns unanswered searches and incomplete content pages into useful conversations — and turns those conversations into actionable editorial demand. Most site search ends in one of two places: a list of matching pages, or an empty result. That works when the visitor already knows the right words and the database contains an exact match. It is less useful when the real question is comparative, contextual or incomplete: “Which bottle fits this occasion?”, “What does this term mean?”, “What should I try next?”, or simply “I expected to find something here.” Liora adds a second path. It can answer the question, continue with follow-ups, ground the answer in public site content, and record the complete demand signal so an editor can improve the underlying website later. How it works in practice I am already using Liora on LQRS, a large ProcessWire drinks-discovery site. 1. Search no longer stops at “no results” A search such as smoky whisky from Scotland currently has no direct structured record matching the complete phrase. The normal ProcessWire results correctly say that no direct match exists. On the same page, Liora produces a concise AI overview, explains the relevant styles and regions, and links to useful internal sources such as the Scotch Whisky collection and Highlands region. The visitor can then ask a follow-up without starting again. This is important: Liora does not replace the deterministic search results or pretend that a generated answer is a canonical database record. The page shows both layers clearly — a conversational overview and the actual structured matches. 2. A content page can answer the next question At the bottom of selected collection and discovery pages, Liora appears as an “Ask about this collection” surface. The widget knows the current ProcessWire page and can use relevant Atlas excerpts and published Vox discussions when those integrations are enabled. A static collection therefore becomes a useful starting point for questions about selection, comparison, terminology or pairings, while the original page remains the source of truth. 3. A 404 becomes a recovery path On the LQRS 404 page, Liora asks what the visitor expected to find. It can help locate a product, recipe, article or guide instead of leaving the visitor at a dead end. 4. Questions become an editorial backlog Every tracked frontend conversation appears in Setup → Liora Insights. Editors can see repeated unmet searches, the source page, referrer, conversation history, status, model, response time, token usage, cache state, retrieval sources and failures. This is the part I find most useful. The generated answer is immediate help for one visitor; the collected demand shows what the site should fix for everyone. Repeated questions can become better structured data, a missing product page, a clearer explanation, a new guide, improved navigation or a search synonym. What Liora includes A reusable frontend conversation widget and InputfieldLiora. Normal JSON responses and real-time streamed responses. One tracked Thread per visitor conversation with chronological messages. Follow-up continuity that preserves recent constraints. Automatic page, source and referrer attribution. Setup → Liora Insights for review, diagnostics and editorial status. Repeated unmet-demand reporting. Optional Atlas retrieval from indexed public site content. Optional published Vox reviews, questions, replies and discussions. Optional live public search through compatible Squad providers. Optional coarse GeoIP enrichment. Validated light and dark themes. Safe Markdown rendering and verified same-site links. Localized widget text and ready-made language presets. A tracked JSON endpoint for completely custom frontends. Public PHP APIs for direct application use. Architecture Liora deliberately does not store provider credentials or implement low-level AI transport. That remains the responsibility of Squad. Liora owns conversations, tracking, retrieval orchestration, the widget and Insights. Squad owns providers, credentials, model discovery, requests and streaming transport. Atlas can supply excerpts from indexed public site content. Vox can supply published community evidence attached to relevant pages. ProcessWire remains responsible for pages, permissions, sessions, localization and persistence. Atlas, Vox, GeoIP and live web search are optional. Liora works with Squad alone and fails back cleanly when an optional context source is unavailable. Basic integration <?php namespace ProcessWire; if($modules->isInstalled('Liora')) { $liora = $modules->get('Liora'); echo $liora->renderWidget([ 'context' => $page->template->name, 'sourceUrl' => $page->url, 'pageId' => $page->id, 'heading' => 'Still looking? Ask Liora', 'theme' => 'default', ]); } The tracked endpoint itself can remain deliberately thin: <?php namespace ProcessWire; $modules->get('Liora')->handleEndpoint(); The consuming site decides where the widget belongs. Liora never inserts itself automatically and does not take over routes, content models or publishing decisions. Privacy and safety Provider credentials remain in Squad. Raw model HTML is never trusted. Atlas excerpts, community content and web results are treated as untrusted reference material. Same-site links are validated; external destinations can be restricted. CSRF protection, rate limits and conversation ownership checks apply to the tracked endpoint. Liora stores a hashed session owner, not a plaintext session identifier. Raw IP addresses and browser user agents are not stored. Conversation review and destructive actions use separate ProcessWire permissions. Stored conversations are preserved on uninstall by default unless destructive uninstall is explicitly enabled. Requirements ProcessWire 3.0.210 or newer PHP 8.1 or newer An installed and configured Squad module A ProcessWire endpoint page for tracked frontend conversations Installation Copy the Liora directory to /site/modules/Liora/. Refresh modules in ProcessWire and install Liora. Configure at least one active provider in Squad. Review the model, prompt, widget, retrieval, privacy and retention settings. Create or reuse the JSON endpoint page and keep its URL synchronized with Liora configuration. Add the widget, Inputfield or custom frontend only where it belongs in the site architecture. Live examples LQRS search with an AI overview: https://lqrs.com/search/?q=smoky%20whisky%20from%20Scotland Page-aware collection widget: https://lqrs.com/collection/best-drinks-of-france/ Dedicated conversation page: https://lqrs.com/ai/ Links GitHub: https://github.com/mxmsmnv/Liora Download ZIP: https://github.com/mxmsmnv/Liora/archive/refs/heads/main.zip README: https://github.com/mxmsmnv/Liora/blob/main/README.md API documentation: https://github.com/mxmsmnv/Liora/blob/main/API.md Integration guide: https://github.com/mxmsmnv/Liora/blob/main/docs/INTEGRATION.md Issues and support: https://github.com/mxmsmnv/Liora/issues I would especially appreciate feedback about where this pattern is useful outside search: documentation, support, directories, product catalogues, knowledge bases and editorial sites — and how you would turn real visitor questions into better ProcessWire content.

Hi everyone, I’m releasing Radar, a content-intelligence and content-operations module for ProcessWire. Radar helps you inspect and improve content across a ProcessWire site without silently changing published pages. It starts with deterministic scans, can add evidence-backed research and optional AI interpretation, and produces reviewable drafts before anything is written. What Radar does Maps ProcessWire templates and fields to reusable Content Types. Scans individual pages, sections, templates, Content Types or a complete site. Includes focused quality, freshness, accessibility-content, conversion, duplicate, relation and taxonomy scans. Finds missing mapped content, weak structure, coverage gaps, duplicates and broken content relationships. Supports internal, URL-based, competitor, official-source, catalog and optional Atlas knowledge-base research. Generates field, multi-field, rewrite, summary, CTA, FAQ, metadata, taxonomy, relation and translation proposals. Stores reports and compares compatible snapshots. Provides an editorial review queue with author, reviewer, status and timestamps. Includes admin workspaces, diagnostics and deterministic CLI commands. Bundles French, German and Spanish admin translations; English is the source language. Safe workflow Deterministic scans are read-only. AI generation creates a proposal and does not silently modify a page. Before applying a draft, Radar shows the current and proposed values and checks ProcessWire permissions and whether the source content has changed since the draft was created. AI is optional. The core audit, quality, conversion, duplicate, relation and taxonomy workflows work deterministically. Requirements ProcessWire 3.0.244 or newer PHP 8.3 or newer Squad for optional AI analysis, research interpretation and generation Atlas only for optional knowledge-base research Installation Copy the Radar directory to /site/modules/Radar/. Refresh modules in the ProcessWire admin. Install Radar; the companion ProcessRadar admin module is installed automatically. Open Setup → Radar → Diagnostics. Define or confirm Content Type field mappings before running broader scans. Screenshots Basic API example $radar = $modules->get('Radar'); $pageScan = $radar->scanPage($page); $siteScan = $radar->scanSite([ 'limit' => 1000, 'relationScan' => true, ]); // This creates a proposal; it does not modify the page. $result = $radar->generateField($page, 'summary', [ 'instruction' => 'Explain the value proposition clearly.', ]); The repository includes detailed administrator, API, CLI, safety and integration documentation. Links GitHub: https://github.com/mxmsmnv/Radar Feedback and real-world content-model examples are welcome.

Hi everyone, I made a small helper called MampWire for quickly creating local ProcessWire development sites with MAMP Pro on macOS. Repository: https://github.com/mxmsmnv/MampWire The idea is simple: you create the site/domain manually in MAMP Pro, point it to an empty local folder, open that folder in the ChatGPT desktop app in Codex mode, and ask it to install MampWire. Example prompt: Install https://github.com/mxmsmnv/MampWire MampWire then: downloads the ProcessWire dev branch creates a MySQL database through the MAMP CLI creates a dedicated database user, instead of using root for the site runs the ProcessWire CLI installer generates a local admin path and login saves credentials to .local/admin.md It also reads MAMP-generated config files to detect things like MySQL port and local web ports, so it should work with common MAMP Pro setups without hardcoding everything. Typical result: Site URL: https://example.test/ Admin URL: https://example.test/aoife/ Admin user: aoife Database name: pw_example_test Database user: pw_example_test This is intended for local development only. It is not a ProcessWire module and does not modify ProcessWire itself. I built it because I often need to spin up fresh local ProcessWire installs for testing, and I wanted the workflow to be easy for agent-based coding tools: create the MAMP site, open the folder, send one prompt, get a working ProcessWire install. Feedback is welcome, especially from anyone using MAMP Pro with different ports, Apache/Nginx settings, or MySQL versions.

Hi everyone! AiWire is now Squad — same module, same author, cleaner name, and a lot more under the hood. Squad is a provider-independent AI gateway for ProcessWire: write your code once and switch model or provider with a single option — no provider-specific glue in your templates. GitHub: https://github.com/mxmsmnv/Squad (old AiWire links redirect) What it does $squad = $modules->get('Squad'); // Simple call echo $squad->chat('What is ProcessWire?'); // Full structured result (content, usage, raw) $res = $squad->ask('Summarize this page', ['provider' => 'openai']); // Generate multiple fields at once, cached $squad->generate($page, [ ['field' => 'ai_overview', 'prompt' => 'Write an overview...'], ['field' => 'ai_seo_meta', 'prompt' => 'Generate meta...'], ], ['cache' => 'W']); 14 providers, one API Anthropic, OpenAI, Google, xAI, OpenRouter — plus direct Chinese providers: DeepSeek, Qwen (Alibaba), Moonshot/Kimi, Zhipu/GLM, MiniMax, 01.AI/Yi, Doubao, Ernie (Baidu), Hunyuan (Tencent). Switch with ['provider' => '...']. More than text $squad->embed('text to vectorize'); // embeddings (OpenAI / Google / Qwen / Zhipu) $squad->image('a mountain at sunrise'); // images (xAI Grok Imagine, OpenAI gpt-image-1) $squad->run([ 'message' => '...', 'tools' => [...], 'onTool' => fn($n,$i)=>... ]); // agentic tool-use Built-in niceties: encrypted key storage (libsodium — a DB dump shows only ciphertext; or reference an env var with env:MY_KEY), prompt caching, multi-key fallback/rotation, per-page file caching, save-to-field, and a current model catalog (Opus 4.8, Fable 5, latest GPT/Gemini/Grok). Upgrading from AiWire (order matters) Install Squad first — it auto-migrates your key table and settings (your encrypted keys are preserved). Then uninstall AiWire. ⚠️ Do it in that order — uninstalling AiWire first drops the old key table, so you'd have to re-enter your keys. Requirements: ProcessWire 3.0.210+, PHP 8.1+ · MIT, by Maxim Semenov — smnv.org Feedback and issues welcome 🚀

Working with AI in PageGrid Inspired by projects like AgentTools, I began investigating how well an AI could handle PageGrid’s native PW structure (Pages, Templates, and Fields). The results were surprisingly good and with a few targeted optimizations, the workflow has become remarkably solid. With the latest updates, an AI agent is reliably able to create and design PageGrid layouts, create new block templates, or perform content updates. To teach AI how to "speak PageGrid", I created a small AGENTS.md file that acts as a central hub. I’ve then added specific "skills" in separate .md files for various tasks ensuring the AI only loads the documentation it actually needs. This approach is highly optimized to minimize token consumption, allowing even "smaller" models like GPT-4o mini or Claude Haiku to produce error-free migrations. To make this possible, I also introduced dedicated Migration Functions that allow the AI to programmatically add items or set styles. For CLI-based projects, I highly recommend the AgentTools Module to streamline the integration. Beyond CLI support, AgentTools also provides a native AI interface directly within the ProcessWire backend editor. Getting Started Install the lastest version of the FieldtypePageGrid module (try for free). Tell your AI agent to read the PageGrid agent guide first: That file gives the agent everything it needs to understand PageGrid and routes it to the right documentation for your task. What You Can Ask the AI to Do Build or modify a layout Create pages with blocks, apply styles, set up responsive layouts using CSS grid columns. Example prompts: "Create a landing page with a full-width hero section and a 3-column feature grid below it." "Add a text block and an image block side by side inside the first group on my homepage." "Make the hero block have a dark background and white text, with 60px padding on desktop and 24px on mobile." The core advantage here is that the AI doesn't write your frontend code from scratch. The HTML and logic are already defined in your PageGrid Block Templates. The AI simply acts as an orchestrator, assembling these blocks and applying styles. This ensures the output remains clean, semantic, and easy to maintain via drag-and-drop later on. Create a custom block template Define a new block type with custom fields and register it with a PageGrid field. Example prompts: "Create a custom block called pg_testimonial with a quote text field and an author name field." "Create a custom card block with a title, description, and link field, and add it to my homepage PageGrid field." Write a site template Render a PageGrid field inside your own PHP template file. Example prompts: "Show me how to render my PageGrid field inside my home.php template using markup regions." "Generate a site template for pagegrid-page that includes the PageGrid output between the header and footer." Docs Documentaion

Hello y'll, I so happy introduce technical template for ai generate templates on Tailwind from ProcessWire fields. How to work: Select templates you want to design interfaces for Copy the generated JSON structure Ask AI to "Create a Tailwind CSS design for displaying this ProcessWire data" Specify any preferences like: mobile-first, card layout, table layout, etc. Push button "Copy Prompt" Insert prompt to Claude AI, ChatGPT or another ai services. How to Setup: Use ftp for transfer lego.php to template folder On ProcessWire create template with same name. Create new page with select template. Enjoy. Note: It is not always possible to generate a template from the first time, but by debugging you can make even more or less excellent variants. On example screenshot finish page with adjusting elements, blocks on Tailwind. If you have questions or wishes ask me below. Thank you. UPDs: 04/14 Update prompt lego.php

What is this about? When working with AI enhanced IDEs like Cursor or Windsurf, we often tend to give somewhat ambiguous requests like these exaggerated examples: or Much better wording for these examples would be AI tends to deliver much better results when we give it concise, technical instructions that fit the context. My approach I have tried to "automate" this in some ways with simple AI rules. Both Cursor and windsurf have a feature called AI rules where you can set global and project specific rules that the assistant will follow. This snippet is in my global rules: ## User Prompt Rephrasing Every time you encounter the exact keyword "rephrase" in a user prompt, do the following: 1. rephrase the user prompt in concise technical terms focusing on: - specific technical task scope - affected components/files - required functionality changes 2. preserve the users intent in the rephrased prompt 3. output the rephrased prompt and ask for confirmation with exact phrase "Act on the rephrased prompt? [y/n]" 4. IMPORTANT: after asking for confirmation, STOP and wait for explicit user response 5. proceed ONLY after receiving "y" confirmation, otherwise ask for clarification 6. when proceeding, act only on the rephrased prompt How it works Now, whenever I add "rephrase" to my prompt, the assistant will act accordingly. Example: Benefits The rephrased version offers several benefits over the original version: Component Clarity - Original was vague, rephrased version explicitly lists required components (GUI framework, drag-drop handler, PDF converter) Scope Definition - Clearly separates existing functionality (PDF conversion) from new requirements (GUI wrapper) Implementation Direction - Suggests specific technical approaches (tkinter/PyQt) while maintaining flexibility The AI assistant will perform better with the rephrased prompt because: More precise input leads to more precise output - technical specifications eliminate ambiguity about what to implement Breaking down into components helps the AI reason systematically about the solution architecture Explicit requirements (e.g., "single file processing") prevent the AI from making incorrect assumptions about scope Clear instructions to AI yield clear results. Or as the old saying goes: garbage in, garbage out :-) A bit of theory behind the concept The idea for a rule like that came to me when I heard about the concept of "Latent Space Activation" in Large Language Models. Very brief explanation from Claude: My rephrasing prompt supposedly has some impact on latent space activation. Claude again: Does it really work? I've been experimenting with this for several days now and my subjective impression is that I really get better results with this approach. Better, working code often on the first shot. Try it yourself Have a play and let me know if you get better results, too.