Search the Community

I tried to import pages from another pw-installation The process results in an error as soon as it starts doing the import. All steps before ok (choosing destination, linking fields, …) working fine. PW creates one page, sets the page name but is not able to set the page title and gives this error: Schwerwiegender Fehler: Uncaught Error: Call to a member function setLanguageValue() on null in wire/modules/LanguageSupport/FieldtypeTextLanguage.module:159 #0 wire/modules/LanguageSupport/FieldtypeTextareaLanguage.module (114): FieldtypeTextLanguage->___importValue(Object(Page), Object(Field), Array, Array) #1 [internal function]: FieldtypeTextareaLanguage->___importValue(Object(Page), Object(Field), Array, Array) #2 wire/core/Wire.php (425): call_user_func_array(Array, Array) #3 wire/core/WireHooks.php (952): Wire->_callMethod('___importValue', Array) #4 wire/core/Wire.php (484): WireHooks->runHooks(Object(FieldtypeTextareaLanguage), 'importValue', Array) #5 wire/core/PagesExportImport.php (957): Wire->__call('importValue', Arr (Zeile 159 in wire/modules/LanguageSupport/FieldtypeTextLanguage.module) Diese Fehlermeldung wurde angezeigt wegen: Sie sind als Superuser angemeldet. Fehler wurde protokolliert. Both sites have the same languages installed (default/de) This is an example of my json: { "type": "ProcessWire:PageArray", "created": "2023-05-18 11:32:25", "version": "3.0.200", "user": "admin", "host": "website.com", "pages": [ { "type": "ProcessWire:Page", "path": "/path/path/some-title/", "class": "ProcessWire\\Page", "template": "team_member", "settings": { "id": 13702, "name": "some-title", "status": 1, "sort": 31, "sortfield": "sort", "created": "28-03-2022 18:39:22", "modified": "28-03-2022 18:46:39", "name_en": null, "status_en": 1 }, "data": { "title": { "default": "Name LÖL", "en": "Name LÖL" }, "headline": { "default": "", "en": "" }, "phone": "0987654321", "email": "email@website.com", "body": { "default": "<p>text</p>", "en": "" } } }, …

Hello, A small utility I built for my own workflow — export any page directly from the editor as a clean Markdown file. Useful for documentation, content migration, and feeding page content to AI tools. GitHub: https://github.com/mxmsmnv/PageMarkdown What it does: Adds an Export to Markdown button to the page edit form Smart HTML conversion — CKEditor content (tables, lists, headings, links, bold/italic) → standard Markdown Supports ProFields: Table, Combo, Repeater Matrix (with type labels and nested structure) Images and files render as Markdown image/link syntax Page references render as links or titles MapMarker, Email, URL, Color fields all handled Configurable: toggle field labels as headings, ignore lists per field/type, datetime format, empty HTML cleanup Requirements: ProcessWire 3.0+, PHP 8.0+ MIT License.

Export your ProcessWire site structure as comprehensive, AI-optimized documentation for ChatGPT, Claude, Copilot, and other AI coding assistants. What It Does Context automatically generates complete documentation of your ProcessWire site in formats specifically optimized for working with AI: 📊 Site Structure Complete page hierarchy exported as JSON, TOON, and ASCII tree Shows all relationships, templates, URLs, and metadata Smart collapsing for large page lists 📋 Templates & Fields All template definitions with complete field configurations Field types, options, requirements, default values Special handling for Repeater, Matrix, Table fields 📦 Content Samples Real page examples exported for each template Shows actual data formats and field usage Helps AI understand your content patterns 💾 Code Snippets Customized selector patterns for your site type Helper functions and utility code API implementation examples 🤖 AI Prompts Ready-to-use project context file Template creation prompts Debugging assistance prompts Session continuity templates 🖥️ CLI Commands Export from command line for AI agents Query templates, fields, and pages directly Perfect for Claude Code, Cursor, Windsurf integration Dual Format Export (The Game Changer!) Context exports in two formats simultaneously: JSON Format Standard format for development tools, APIs, and compatibility TOON Format (AI-Optimized) ✨ Token-Oriented Object Notation designed specifically for AI prompts: 30-60% fewer tokens than JSON Significantly reduces API costs Same data, more compact representation No external dependencies - pure PHP Real Savings Example For a typical ProcessWire site with 50 templates: structure.json (15,000 tokens) → structure.toon (8,500 tokens) = 43% savings templates.json (8,000 tokens) → templates.toon (4,000 tokens) = 50% savings samples/*.json (12,000 tokens) → samples/*.toon (6,500 tokens) = 46% savings Cost Impact (Claude Sonnet pricing): JSON export: $0.105 per AI interaction TOON export: $0.057 per AI interaction Save ~$5/month if you use AI assistants 100 times/month Installation cd /site/modules/ git clone https://github.com/mxmsmnv/Context.git Then in admin: Modules → Refresh → Install Or download from ProcessWire Modules Directory Quick Start Web Interface Setup → Modules → Context → Configure Choose your site type (Blog, E-commerce, Business, Catalog, Generic) ✅ Enable "Export TOON Format" (recommended for AI work!) Enable optional features: ✅ Export Content Samples ✅ Create Code Snippets ✅ Create AI Prompts ✅ Generate SKILL.md for AI Agents Click "Export Context for AI" Files appear in /site/assets/cache/context/ CLI Interface # Full export php index.php --context-export # Export TOON format only (fastest, smallest) php index.php --context-export --toon-only # Query specific data php index.php --context-query templates php index.php --context-query fields php index.php --context-query pages "template=product, limit=10" # Quick stats php index.php --context-stats # Help php index.php --context-help Perfect for AI coding agents like Claude Code, Cursor, and Windsurf! Generated Files /site/assets/cache/context/ ├── README.md # Complete documentation ├── SKILL.md # AI agent skill definition ├── structure.json / .toon # Page hierarchy ├── structure.txt # ASCII tree ├── templates.json / .toon # All templates & fields ├── templates.csv # Templates in CSV ├── tree.json / .toon # Combined structure ├── config.json / .toon # Site configuration ├── modules.json / .toon # Installed modules ├── classes.json / .toon # Custom Page classes │ ├── samples/ # Real content examples │ ├── product-samples.json │ └── product-samples.toon # 46% smaller! │ ├── snippets/ # Code patterns │ ├── selectors.php # Customized for your site type │ ├── helpers.php # Utility functions │ └── api-examples.php # REST API examples │ └── prompts/ # AI instructions ├── project-context.md # Complete project overview ├── create-template.md # Template creation guide ├── create-api.md # API creation guide ├── debug-issue.md # Debugging helper └── project-summary.md # Session continuity template Using with AI Assistants Web Interface Upload Upload TOON files to save tokens and costs: 📎 structure.toon 📎 templates.toon 📎 prompts/project-context.md Then ask your AI assistant: "Help me create a blog post template with title, body, author, categories, and featured image. Follow the existing patterns from templates.toon" AI Coding Agents (Claude Code, Cursor, Windsurf) 1. Tell your agent to read the docs: Read /site/modules/Context/AGENTS.md 2. Agent can now export context: php index.php --context-export --toon-only 3. Agent queries specific data: php index.php --context-query templates 4. Agent reads exported files: Read SKILL.md, then structure.toon and templates.toon The AI has complete context of your site and can generate code that follows your exact patterns! Site Type Customization Code snippets automatically adapt to your site type: Blog / News / Magazine Post listings, author archives, category filtering Recent posts, popular content, related articles E-commerce / Online Store Product listings, cart logic, order processing Inventory management, payment integration Business / Portfolio / Agency Service pages, team members, case studies Testimonials, project galleries Catalog / Directory / Listings Brand hierarchies, category filters Advanced search, sorting, pagination Generic / Mixed Content General purpose patterns for any site type Features Overview Always Exported (Core) ✅ Complete page tree structure ✅ All templates with field definitions ✅ Site configuration and settings ✅ Installed modules list ✅ Custom Page classes ✅ README with complete documentation ✅ SKILL.md for AI agents Optional (Configurable) ⚙️ Content samples (1-10 per template) ⚙️ API JSON schemas ⚙️ URL routing structure ⚙️ Performance metrics ⚙️ Code snippets library ⚙️ AI prompt templates ⚙️ Field definitions metadata Advanced Settings Auto-update on template/field changes Custom export path (supports absolute paths) Maximum tree depth (3-20 levels) JSON children limit (prevent huge files) Compact mode for large lists Custom AI instructions CSS framework detection (or manual override) Why TOON Format? TOON is specifically designed for AI prompts. Here's the difference: JSON (verbose): { "products": [ {"id": 1, "title": "Dark Chocolate", "price": 12.99}, {"id": 2, "title": "Milk Chocolate", "price": 9.99} ] } TOON (compact): products[2]{id,title,price}: 1,Dark Chocolate,12.99 2,Milk Chocolate,9.99 Same data, 50% fewer tokens! Use Cases 🤖 AI-Assisted Development Upload your site context to Claude/ChatGPT and get code that follows your exact patterns 🤖 AI Coding Agents Claude Code, Cursor, Windsurf can export and query your site via CLI 📚 Developer Onboarding New team members get complete site documentation instantly 🔄 Site Migration Export complete site structure for documentation or migration planning 📖 Code Standards Maintain consistency across your team with AI that knows your patterns 💰 Cost Optimization Reduce AI API costs by 30-60% with TOON format 🔁 Session Continuity Maintain context between AI coding sessions with project-summary.md API Variable In your ProcessWire code: // Get Context module instance $context = wire('context'); // Programmatic export $context->executeExport(); // Get export path $path = $context->getContextPath(); Links GitHub: https://github.com/mxmsmnv/Context TOON Format Spec: https://toonformat.dev Screenshots Example Workflow Export your site Click one button or run php index.php --context-export Upload to AI Upload .toon files to Claude/ChatGPT for maximum efficiency Build features faster AI knows your exact site structure, templates, and patterns Save money Use 30-60% fewer tokens on every AI interaction Perfect for ProcessWire developers who use AI coding assistants! The TOON format support makes it significantly more cost-effective to work with Claude, ChatGPT, and similar tools. Now with CLI support for seamless AI agent integration! Questions? Suggestions? Let me know! 🚀

Hi everyone, in particular @ryan @Peter Knight@ukyo @gebeer @maximus who seem to have been most AI active lately. I've just added dai() and bdai() dumping calls so that objects and arrays are rendered in plain text format more friendly to LLMs, but I am curious what AI/LLM integration features you think would be most useful? Claude suggested an MCP server - here is its plan. Does this sound useful? Any other ideas? Two processes, loosely coupled: ┌──────────────────┐ ┌──────────────────────────┐ │ Claude / Cursor │ stdio MCP │ TracyDebugger site │ │ client │ ─────────────────► │ │ │ │ HTTP + token │ tracy-ai/* endpoints │ └──────────────────┘ ◄───────────────── └──────────────────────────┘ MCP server — a tiny program the agent launches over stdio (the MCP transport). Ships as a sibling module (TracyDebuggerMCP/) or a standalone npm package the user npx's. TracyDebugger HTTP endpoints — new authenticated tracy-ai/* routes inside the ProcessWire site. The MCP server is just a thin translator between MCP tool calls and these HTTP requests. The MCP server holds no site logic. It's a dumb adapter. All the real work (reading panels, redacting secrets, rendering plaintext) stays inside TracyDebugger where the ProcessWire API is available. What the agent sees A handful of tools in the MCP catalog: tracy_export_bundle(preset: "debug" | "performance" | "template" | "full") tracy_get_request_info() tracy_get_last_errors(limit: int = 10) tracy_get_slow_queries(limit: int = 10) tracy_get_template_schema(template: string) tracy_list_dumps() tracy_run_console(code: string) ← gated, opt-in only Every tool returns the scrubbed plaintext/JSON produced by AIExport — same output Phase 2's "Copy" button produces. Config on the site New module-config section: aiExportHTTPEndpointEnabled (default off) aiExportMCPToken — a random token generated once per site, shown to the user to paste into their MCP client config aiExportAllowConsoleExec (default off) — gates tracy_run_console aiExportAllowedIPs — optional whitelist Config on the client User's ~/.config/claude/mcp.json or equivalent: json { "mcpServers": { "tracy": { "command": "npx", "args": ["-y", "tracy-mcp"], "env": { "TRACY_URL": "https://mysite.test", "TRACY_TOKEN": "<paste token from module config>" } } } } The agent launches the MCP server locally; the MCP server talks to the site over HTTPS with the token. Auth Per-site token (generated in module config, rotateable). Token sent as Authorization: Bearer … header on every HTTP call. Optional IP whitelist on the site side. tracy_run_console additionally requires aiExportAllowConsoleExec=true — otherwise the MCP server gets a 403 and reports "console execution disabled for this site" to the agent. Example flow — agent debugging an error User in Claude: "Why is /about/team throwing a 500?" Agent: Calls tracy_export_bundle(preset: "debug"). MCP server hits GET https://mysite.test/tracy-ai/export?bundle=debug with the bearer token. Site responds with scrubbed JSON: request info, PW info, last error with stack, slow queries, recent PW logs. Agent reads the traceback, sees TemplateFile.php:123 Undefined index "featured_image", asks tracy_get_template_schema(template: "team"). Site responds with the template's fields — no featured_image field exists. Agent suggests the fix, possibly calls tracy_run_console (if enabled) to verify. No human pasting. Agent pulls what it needs on demand, scoped by the tool it calls. What ships where In TracyDebugger itself: the tracy-ai/* HTTP endpoints + auth + token config + AIExport (already built in Phase 1, extended in Phase 2). In the MCP server (separate repo, ~200 lines): tool definitions, HTTP calls, response shaping for MCP. This separation matters because the MCP server can be installed independently of the site, and the site is still useful without it (you can hit tracy-ai/export with curl directly). Footprint on production Zero unless you explicitly enable it. The endpoints, token, and MCP config are all opt-in behind module settings. That's the shape. The main design choices worth confirming before building: Token-only auth, or also require the existing Tracy access? — i.e., should the agent's token have to belong to an allowed Tracy dev user, or is a separate machine token fine? I'd lean separate machine token for agents; reusing session auth is awkward over stdio. Read-only by default? — I strongly recommend yes. tracy_run_console is the only write path and should be a separate opt-in. Does the MCP server live in this repo or a separate repo? — I'd say separate. Different language, different release cadence, and the site works without it.

PW: 3.0.255 PHP: 8.3.3 Sadly I now have the same issue and I can't find a way around it. Duplicate sites, create a new page on one then try to export the page to the duplicate site and get this error: Error: Call to a member function getLanguageValue() on null in wire/modules/LanguageSupport/FieldtypeTextareaLanguage.module:126 #0 [internal function]: FieldtypeTextareaLanguage->___importValue() #1 wire/core/Wire.php (425): call_user_func_array() #2 wire/core/WireHooks.php (1018): Wire->_callMethod() #3 wire/core/Wire.php (484): WireHooks->runHooks() #4 wire/core/PagesExportImport.php (998): Wire->__call() #5 wire/core/PagesExportImport.php (685): PagesExportImport->importFieldValue() #6 wire/core/PagesExportImport.php (535): PagesExportImport->arrayToPage() #7 wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeaterPorter.php (255): PagesExportImport->arrayToPages() #8 wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module (1006): FieldtypeRepeaterPorter->importValue() #9 [internal function]: FieldtypeRepeater->___importValue() #10 wire/core/Wire.php (425): call_user_func_array() #11 wire/core/WireHooks.php (1018): Wire->_callMethod() #12 wire/core/Wire.php (484): WireHooks->runHooks() #13 wire/core/PagesExportImport.php (998): Wire->__call() #14 wire/core/PagesExportImport.php (685): PagesExportImport->importFieldValue() #15 wire/modules/Process/ProcessPagesExportImport/ProcessPagesExportImport.module (619): PagesExportImport->arrayToPage() #16 wire/modules/Process/ProcessPagesExportImport/ProcessPagesExportImport.module (320): ProcessPagesExportImport->processImportItemToPage() #17 wire/modules/Process/ProcessPagesExportImport/ProcessPagesExportImport.module (242): ProcessPagesExportImport->processImportSubmit() #18 wire/modules/Process/ProcessPagesExportImport/ProcessPagesExportImport.module (76): ProcessPagesExportImport->processImport() #19 wire/core/Wire.php (413): ProcessPagesExportImport->___execute() #20 wire/core/WireHooks.php (1018): Wire->_callMethod() #21 wire/core/Wire.php (484): WireHooks->runHooks() #22 wire/core/ProcessController.php (362): Wire->__call() #23 wire/core/Wire.php (413): ProcessController->___execute() #24 wire/core/WireHooks.php (1018): Wire->_callMethod() #25 wire/core/Wire.php (484): WireHooks->runHooks() #26 wire/core/admin.php (174): Wire->__call() #27 wire/modules/AdminTheme/AdminThemeUikit/controller.php (15): require('/home/u99035861...') #28 site/templates/admin.php (15): require('/home/u99035861...') #29 wire/core/TemplateFile.php (328): require('/home/u99035861...') #30 wire/core/Wire.php (413): TemplateFile->___render() #31 wire/core/WireHooks.php (1018): Wire->_callMethod() #32 wire/core/Wire.php (484): WireHooks->runHooks() #33 wire/modules/PageRender.module (547): Wire->__call() #34 wire/core/Page.php (3152): PageRender->render() #35 wire/core/Wire.php (416): Page->___renderPage() #36 wire/core/WireHooks.php (1018): Wire->_callMethod() #37 wire/core/Wire.php (484): WireHooks->runHooks() #38 wire/core/Page.php (3097): Wire->__call() #39 wire/core/Wire.php (413): Page->___render() #40 wire/core/WireHooks.php (1018): Wire->_callMethod() #41 wire/core/Wire.php (484): WireHooks->runHooks() #42 wire/modules/Process/ProcessPageView.module (193): Wire->__call() #43 wire/modules/Process/ProcessPageView.module (114): ProcessPageView->renderPage() #44 wire/core/Wire.php (416): ProcessPageView->___execute() #45 wire/core/WireHooks.php (1018): Wire->_callMethod() #46 wire/core/Wire.php (484): WireHooks->runHooks() #47 index.php (56): Wire->__call() #48 {main}

I wanted a way to chat with my Processwire site and built a Module (PW MCP) and an MCP server to connect into it. It's a private repo at the moment but it can be public if anyone finds it useful. It's basically a way to use the Cursor Chat Ui to query my site, fields, templates and content. Here's part of the readme which explains it better. What Is It? ProcessWire MCP is a bridge between ProcessWire and Cursor IDE (the AI-powered code editor). It lets you query your ProcessWire site's structure and content directly from Cursor's chat interface using natural language. Instead of writing selectors or browsing the admin, you can just ask: "What templates does this site have?" "Show me the fields on the blog-post template" "Search for pages containing 'summer'" "Find all images with 'lake' in the filename" Why I Built It Cursor can see your template files and code in the local directory, but it can't see what's actually in your ProcessWire database — which templates and fields are registered, what pages exist, or what content they contain. With ProcessWire MCP, the AI can: Query the actual database schema (not just parse template files) Look up page content by ID, path, or selector Understand field configurations (types, settings, which templates use them) Search across all text content and find files/images Get RepeaterMatrix content with type labels See file metadata (dimensions, descriptions, URLs) It's the difference between seeing $page->body in code vs. knowing what that page's body actually contains. Architecture Cursor Chat → MCP Server (Node.js) → PHP CLI → ProcessWire API The module consists of: PwMcp — A ProcessWire module with a CLI interface mcp-server — A Node.js server that speaks the Model Context Protocol The CLI can also be used standalone for quick queries from terminal. Available Commands Command Description health Check connection and get site info list-templates List all templates with field counts get-template [name] Get template details and fields list-fields List all fields with types get-field [name] Get field details and usage get-page [id\|path] Get page by ID or path with all field values query-pages [selector] Query pages using PW selectors search [query] Search content across all text fields search-files [query] Search files by name/extension export-schema Export complete site schema Example: Health Check php site/modules/PwMcp/bin/pw-mcp.php health --pretty { "status": "ok", "pwVersion": "3.0.241", "siteName": "www.example.com", "moduleLoaded": true, "counts": { "templates": 45, "fields": 72, "pages": 960 } } Example: Content Search Ask Cursor: "Search for pages containing 'summer'" { "query": "summer", "count": 5, "results": [ { "id": 1764, "title": "Lake District walks in summer", "path": "/guides/lake-district-summer/", "template": "page-guide", "matchedField": "Body", "snippet": "The Lake District offers some of the best walking trails in summer. From gentle lakeside strolls to challenging fell walks..." } ] } Example: File Search Ask Cursor: "Find images with 'lake' in the filename" { "query": "lake", "count": 5, "results": [ { "filename": "lake-windermere-sunset.jpg", "url": "/site/assets/files/1070/lake-windermere-sunset.jpg", "size": 31207, "sizeStr": "30.5 kB", "description": "Sunset over Lake Windermere", "field": "Images", "page": { "id": 1070, "title": "Lake District walks in summer", "path": "/guides/lake-district-summer/" }, "width": 500, "height": 626 } ] } Example: Get Page with All Fields Ask Cursor: "Get the page at /about/" { "id": 1050, "name": "about", "path": "/about/", "url": "/about/", "template": "basic-page", "status": 1, "statusName": "published", "parent": { "id": 1, "path": "/", "title": "Home" }, "numChildren": 5, "created": "2023-05-15T10:30:00+00:00", "modified": "2024-11-20T14:22:00+00:00", "fields": { "title": "About Us", "body": "<p>We are a team of dedicated professionals...</p>", "Images": { "_count": 2, "_files": ["team-photo.jpg", "office.jpg"] } } } Example: RepeaterMatrix Support The module fully supports RepeaterMatrix fields, returning the actual content with type labels: { "matrix": { "_count": 3, "_items": [ { "_typeId": 1, "_typeLabel": "Body", "Body": "<h2>Welcome to our guide</h2><p>This guide covers...</p>", "Images": null }, { "_typeId": 2, "_typeLabel": "FAQs", "faq_question": "What is the best time to visit?", "faq_answer": "The summer months offer the best weather for walking..." }, { "_typeId": 3, "_typeLabel": "Call to Action", "cta_title": "Plan Your Visit", "cta_link": "/contact/" } ] } } So thats the first part done and working. My next plan is to be able to 1. PULL / convert a databse page into a local text file which lists all page properties, fields, template etc 2. edit the file as a local text file 3 PUSH the text file back into PW so that the original content picks up the changes Just having fun and building something useful. Very likely there are similar solutions or better ways to handle this but this suits my workflow ATM. Cheers P

ProcessPromptManager is a ProcessWire admin module for generating site-aware prompt exports for external AI agents. It allows an administrator to select a template, define which fields an agent should populate, add instructions, and export a zip containing a markdown prompt and JSON field definitions. The module does not handle authentication or integration. It provides a controlled starting point for accepting structured input from external agents. Never include credentials or sensitive data in prompts. Module info: https://github.com/clipmagic/ProcessPromptManager/

Quick bump to 1.2.0: Fixed: Hardcoded Export Paths All /site/assets/context/ paths in prompt templates now use dynamic export_path Works correctly with custom paths like /home/user/context-exports/ Affects: project-context.md, create-template.md, create-api.md Prompts Description Clarity Changed wording to clarify these are templates for manual use "Prompt templates for manual LLM/agent use (not auto-loaded by agents)" Prevents AI agents from mistakenly treating them as project data Added: "Go to Module's Settings" Button Quick access button on dashboard next to "Re-Export" No more hunting through admin menus! Changed Project Summary Preservation project-summary.md no longer overwritten on re-export Preserves your session history and changes Only created on first export Thanks @szabesz and @psy for the excellent feedback!

@gebeer Thanks! Sounds like Claudia would like a PR for the ddev update if available. For the skills stuff, thanks for explaining it all. I'll look forward to having a closer look in your commits but one thing noticed so far is that your version has the option to install the skill files off the PW install root in a .agents dir. But the only place PW an assume is writable is off the /site/assets/. So the .agents off the root would work in some installs and not in others. Thanks for the example rock migrations file. It looks to me like the same format that the core Pages Export/Import module uses, except that the module uses them JSON encoded. While we're calling the ones generated by Claude with the AgentTools module "migrations", they really are just repeatable logic. So the logic can be about creating/updating/deleting some pages/fields/templates or perhaps something else. How does the Rock Migrations format work when you need some logic as part of the migration, such as creating a page, then creating another page that references that page (FieldtypePage)? You could do this with the pages export/import but would have to run the JSON through more than once to do it. Also, how does it handle files? Handling files is something AgentTools does not yet do.

Context Module v1.1.8 Released! Thanks everyone for the great feedback! Here's what's new: New Features SKILL.md Auto-Generation (requested by @szabesz) Automatically generates SKILL.md for AI coding agents (Cline, Junie, etc.) Lists all exported files with descriptions and usage examples Follows Cline/MCP skill format specification Enable/disable in module settings (enabled by default) Project Summary Template (suggested by @psy) Auto-creates prompts/project-summary.md template Helps AI agents maintain context between coding sessions Structured format: project state, decisions, issues, next steps Ask AI to update at end of each session for seamless continuity Setup for AI Agents: Cline (PHPStorm/VSCode): Set export path to .agents/skills/context/ Junie (PHPStorm): Set export path to .junie/skills/docs/ Re-export and SKILL.md + project-summary.md are auto-created Bug Fixes FieldtypeQRCode Compatibility (reported by @psy) Fixed error when exporting field definitions for FieldtypeQRCode Added method_exists() check before calling getModuleInfo() Now works with all fieldtypes using .info.php pattern Documentation Added Best Practices section to README covering: AI coding agents setup (Cline, Junie) Session continuity workflow File upload strategies for optimal token usage Download: GitHub Thanks @szabesz and @psy for the excellent suggestions!

Hi everyone, I needed a solid subscription module for a client project — something that handles multiple lists, double opt-in, and plugs cleanly into order and contact forms via a PHP API. Nothing in the directory quite fit, so I built Subscribe. It's been running in production on a few sites since March, so the edge cases are ironed out. GitHub: https://github.com/mxmsmnv/Subscribe What it does: Multiple subscription lists with many-to-many subscriber relationships Double opt-in with configurable HTML email ({confirm_url}, {unsub_url} placeholders) Honeypot spam protection — no CAPTCHA needed IP-based rate limiting (configurable threshold and time window) One-click unsubscribe with unique token per subscription WireMail provider selector — works with default, SMTP, Brevo, or any WireMail module Admin UI (Setup → Subscribers): Sidebar list switcher with subscriber counts Add/toggle/remove subscribers, create/rename/delete lists Search, status filter, pagination CSV import, JSON/CSV export per list Resend confirmation for pending subscribers PHP API — drop it into any template, order form, or contact form: $sub = $modules->get('Subscribe'); $sub->subscribe('user@example.com', $listId); Hookable event for integrations (Telegram notifications, CRM sync, etc.): $wire->addHookAfter('Subscribe::subscribed', function(HookEvent $event) { // $email, $listId, $subscriptionId }); Ships with an Alpine.js form block ready to drop into any template. Requirements: ProcessWire 3.x, PHP 8.0+ MIT License.

Something I've adopted for my PW sites is putting environment-specific DB credentials and configuration in a separate file, /site/config.local.php: /** * Installer: Database Configuration * */ $config->dbHost = '127.0.0.1'; $config->dbName = 'db'; $config->dbUser = 'default'; $config->dbPass = 'default'; $config->dbPort = '3306'; /** * Installer: HTTP Hosts Whitelist * */ $config->httpHosts = array( 'my-local-domain.test'); And then including that file into /site/config.php: /*** INSTALLER CONFIG ********************************************************************/ // DB Config, Hosts Whitelist include dirname(__FILE__) . '/config.local.php'; I find this makes it easier to push changes when using version control (i.e. git) across different environments, and keep the credentials and other sensitive information excluded from the repo. On some managed hosts like Cloudways, you can pull and push DB changes from staging to/from production applications, as well as branch changes from git. Obviously this doesn't help when you make DB changes locally, though. Otherwise, I will either export/import the entire DB via the Database Backups module, or Pages Import/Export (under Admin > Modules, Core modules) depending on the kind of changes. After using Vercel and Netlify for static-based websites, it does make me wish there was a quicker way to push/pull DB changes, but perhaps that extra bit of friction is good so you don't inadvertently disrupt your production data. Definitely something I can improve in my own workflow! Managing local/remote image assets Occasionally I've added this code snippet to /site/ready.php, that allows for your local installation to pull down the asset from prod, which can save you some time. I'm also generally curious to know more about other folks' deployment strategies – could be a potentially useful thing to collect and make more visible in the PW docs, too.

Update: v1.1.6 is now released with configurable export path! You can now set custom paths in module settings as you requested: Setup → Modules → Context → Configure → Export Path For Junie AI integration: .junie/skills/docs Important for CloudPanel/Nginx users: Since .htaccess doesn't work on Nginx, I recommend using an absolute path outside web root for maximum security: /home/lqrs/context-exports/ The module now detects absolute paths (starting with /) and uses them as-is.

Some updates to the Cursor MCP to Processwire Module. There's a new front-end called MCP Sync. So if the MCP server acted as a bridge between Processwire and Cursor, why do I then need a front-end UI? Surely the point of an MCP server was 50% to bypass the Admin? Well, apart from building it for fun, I thought it was nice to have a more visual front-end for the import and export of pages. From the screenshot you might notice a traditional tree view with some useful columns... Change Status Never exported - probably doesnt need a badge but just means it's the original state Local Changes - I've downloaded the page to a file and edited it In Sync - changes have been imported Conflict - both the remote (PW) and the local file) have changes In the Actions column the three icons are WTF (Wire to file) 🙂 - exporting FTW (File to wire) - importing This was a little tricky because import and export mean different things wether you're operating from Curors MCP or import/export via the Cursor UI. So I settled on WTF and FTW because they are less relative to your environment. Big change Previously, when a page was in WTF mod,e I was storing a YAML file. Apart from Matrix items which were separate YAML files. But as we know, YAML can be prone to misformatting so the Module now understands if a field is a Rich Text field and will export that as a stand-alone HTML file with a match name. It means a few more files on the file system than the previous method, but I like that I get a separate HTML entity. The screenshot of my local file system you can see I have WTF my Diagram and Illustrations page. And not just because the content was out of date and mentioned Macromedia Flash! Back to the GUI, you can see a screenshot of that row now picks up the change requiring a FTW. There's a few other helpful functions such as a changes preview as a safety step prior to committing a FTW. There's also a View YAML icon on each row which is a preview too. Here's the raw details of my WTF of Diagram and Illustrations page site/assets/pw-mcp/services/diagrams-illustration/page.meta.json This is a high-level overview of the exported page and is not meant to be edited. { "_readme": "DO NOT EDIT - This file is auto-generated. Edit page.yaml and field HTML files instead.", "pageId": 1051, "canonicalPath": "/services/diagrams-illustration/", "template": "services-detail", "title": "Professional Diagram Design & Illustration Services", "pulledAt": "2026-02-11T11:27:58+00:00", "lastPushedAt": null, "revisionHash": "sha256:2c264809d740ff009e27a5c664b3dced0e529493e54f39c3b458a718d47defb4", "contentHash": "0fc046d624ae2a6add4f6ffbcd6b80dd", "status": "clean" } /site/assets/pw-mcp/services/diagrams-illustration/page.yaml Note how the body field around line 4 or 5 is an RTE, so it's not included in the raw YAML but saved as a standalone file. fields: title: "Professional Diagram Design & Illustration Services" body_summary: "Need to clarify a product, process or service? Clarify your offering with our diagram design services." body: _file: fields/body.html image: [] service_thumbnail: - filename: icon-service-diagrams.png description: null width: 173 height: 113 seo_tab: null seo_title: "Professional Diagram Design & Illustration Services" seo_keywords: null seo_description: Transform complex ideas into clear, compelling diagrams. We create technical illustrations, infographics, and process diagrams that simplify your message and engage your audience. seo_image: null seo_custom: null seo_canonical: null seo_tab_END: null First_Child_Redirect: 0 sitemap_ignore: 0 site/assets/pw-mcp/services/diagrams-illustration/fields/body.html Just a html page and not worth including That's it for the mo.

Hi @maximus Hit a red warning when trying to export field definitions for FieldtypeQRCode. This fieldtype uses FieldtypeQRCode.info.php instead of getModuleInfo() inside the module. Fix in exportFieldDefinitions line 1928: // 'label' => $field->type->getModuleInfo()['title'] ?? $className, 'label' => method_exists($field->type, 'getModuleInfo') ? $field->type->getModuleInfo()['title'] : $className, HTH

I usually do this and it simplifies things if your local and remote credentials are the same. 1. Turn on errors on your config file to make trouble shooting easier 2. Zip up all your local files and ensure to get your htaccess too 3. Export the local database and import it into the remote plesk server or whatever you’re using 4. Set up remote database credentials 5. unzip remote files From that point onwards, I might have some htaccess issues or I might need to look at site logs etc but most of the time it goes smoothly enough. You’re installing onto a blank site right? If there is an existing site in the webspace which you didn’t create, ensure to rename the index.html page

Hey there, We're using the multi-language field translation export/import module (https://processwire.com/blog/posts/language-field-export-import/) to export the text fields of pages, translate them and import them again. Since the module does not support custom image fields (see https://processwire.com/blog/posts/pw-3.0.142/), we are wondering how we can export these image fields and import them again after translation. Does anyone have experience with this issue and can help us? Thanks in advance! Multi-language field translation export/import

Thanks @maximus for sharing. I am testing the module, and found two issues: 1. After the module has been installed the "Submit" button of its settings page must be clicked or else the actual settings are not the same as seen in the GUI. By default, a lot of "Module Configuration" settings seems to be turned on (their checkboxes are on), like "TOON Format Export", "Content Samples", ect. but they are not on. I had to manually "Submit" the settings so that the module settings are actually the same as seen on the module config page. 2. In Context.module.php $matrixTypes = $matrixField->type->getMatrixTypes($matrixField); foreach($matrixTypes as $mt) { if($mt->name === $name) { But $mt->name is meaningless as $matrixTypes is the following kind of array: array 'matrix_email_block_image' => 1 'matrix_email_block_button' => 3 'matrix_email_block_text' => 4 'matrix_email_block_spacer' => 5 $mt->name is an attempt to access the name property of an integer. And that happens in two locations:

Hey I've been building a few React based apps for the first time and one of them required a blog. I started to explore MDX files with YAML for a fast blog launch. I found it refreshingly simple and I loved the databaseless setup, the flat file system, the versioning etc. As my requirements and content grew, I kept finding myself trying to do things which Processwire already does and does beautifully. Things like.. treeview and nice UI keeping track of changing redirects providing a front end UI for posts and a 1000 other things we all know and live PW for. My question is, is there a way to combine the two? Challenge 1 I'm wondering if I could have a local install of PW acting as the blogging engine and the front-end UI I could then export a page as an MDX file to my React Apps /blog/posts/ folder and my React App can pickup Challenge 2 Another element why I love the flat file MDX approach is I am bulk generating a lot of content and I can use AI to quickly create new documentation and blog pages. If I had 10-100 MDX files, I would like Processwire to be able to import /scan these pages and auto update the tree and auto import various chunks of content into fields. I *dont think* I can use AI to quickly generate multiple pages of content in PW at scale but I have never really explored the UI. So as you guessed, I am not 100% sure of my requirements but keen to hear how others handled similar integrations. Thanks P

If you just want to sync the fields and templates you can also try the native fields/templates export/import. For most fields this works quite well. Thats how I usually do it. Sometimes I also do it the other way around and import all the pages that have changed from production to local with the native page export/import and than export the whole database (using ProcessDatabaseBackups module) from local and import that on the production site. RockMigrations is also great and I have used it for more complex stuff. One thing I did not find in RockMigrations is the option to migrate pages. Can that also be done?

That’s amazing. I note you chose JSON for export. Have you seen the token optimised Toon? Might be a good additional option or even YAML? Looking forward to trying P

WireNPS is a comprehensive module for collecting and analyzing customer feedback via a modern Net Promoter Score (NPS) popup interface. Key Features: Elegant NPS Widget: A non-intrusive, mobile-friendly popup for ratings (0-10) and text feedback. Real-time Analytics: Dashboard featuring NPS score calculation, score distribution charts, and 30-day trend graphs. Multilingual Support: Built-in support for English, German, French, and Chinese with automatic browser/user language detection. Flexible Access: Support for both logged-in users and guests (Public/Private modes). Data Export: CSV export functionality for external analysis. Privacy Control: Configurable IP/User Agent tracking and cookie management. Requirements: ProcessWire 3.0+ PHP 8.2+ Quick Installation: Download or git clone into /site/modules/WireNPS/. Install via the ProcessWire admin. Create an AJAX handler page using the provided template. GitHub: https://github.com/mxmsmnv/WireNPS

Pages Export This module is for specifically exporting ProcessWire 2.x sites for later importing into ProcessWire 3.x. Github: Project Page Modules Directory: https://modules.processwire.com/modules/process-pages-export/ Credits: Ryan Cramer Background As I make my modules ProcessWire 3.x-compatible only, I've had the need to re-create/mirror their ProcessWire 2.x test sites in respective ProcessWire 3.x sites. These ProcessWire 3.x sites (one for each module) were already in place and I didn't feel like re-doing them by exporting/importing site profiles. I also like working with JSON rather than other export formats. So, I decided to write a custom pages export/import script for moving the ProcessWire 2.x sites to their respective ProcessWire 3.x counterpart sites. I'd just finished the export side of things when I came across a post in the forums that reminded me that ProcessWire 3.x already boasts a pages export/import feature, although some of it is still in development. Great! I like its API (PagesExportImport.php) and GUI (ProcessPagesExportImport.module) so no need to re-invent the wheel. I still had the small problem of making sure my JSON export would be compatible with the JSON input that the ProcessWire 3.x import expects. No need to re-invent the wheel, again! I ditched my custom script and instead ported the export functionalities of ProcessWire 3.x Pages Export/Import for use in ProcessWire 2.2 - 2.7, specifically to help migrate older sites to ProcessWire 3.x. Compatibility The module and class have been tested and work in ProcessWire 2.2, 2.3, 2.4, 2,5, 2.6 and 2.7. The module is currently tagged as 'in development' until Pages Import feature of ProcessWire 3.x is released as stable. Nonetheless, I have not encountered any issues so far in either the export or the ProcessWire 3.x import. I think Ryan is waiting until he can support more complex field types before tagging the ProcessWire 3.x Pages Export/Import as production-ready. This is not a ProcessWire 3.x module and will never be. It has no such need . Just in case you forget and try to install it in a ProcessWire 3.x site, the module will throw a WireException(). I will also not be porting the ProcessWire 3.x import functionality for use in ProcessWire 2.x. That will defeat the purpose here; to move sites to ProcessWire 3.x and not the other way round. Supported Fields All non-complex fields such as integer, text, textarea, etc Page fields Repeaters File and Image fields I think these cover most needs. Note: not yet tested with Multilingual fields. Technical To ensure exports will be compatible with ProcessWire 3.x Pages Import, where necessary, the module borrows (and amends as needed) methods from ProcessWire 3.x for use in ProcessWire 2.x. For instance, ProcessWire 3.x Pages Export/Import uses the new(-ish) $file functions found in WireFileTools. Rather than copy and include such files, the module only borrowed and amended needed methods. These are listed below. PagesExport.php From /wire/core/Functions.php: wireInstanceOf(), wireClassName() and wireClassParents() From /wire/core/Fieldtype.php: getImportValueOptions() and getDatabaseSchema() From /wire/core/WireFileTools.php: zip(), chmod() and mkdir() From /wire/core/WireHttp.php: sendFile From /wire/modules/Fieldtype/FieldtypeFile.module: exportValue() and exportDescription() From /wire/modules/Fieldtype/FieldtypeImage.module: exportValue() From /wire/modules/Fieldtype/FieldtypePage.module: exportValue() and exportValuePage() From /wire/modules/Fieldtype/FieldtypeRepeater.module: exportValue() From /wire/core/Fieldtype/WireTempDir.php: create(), createName() and getTempDir() All the export methods from the /wire/core/PagesExportImport.php class ProcessPagesExport.module All the export methods from /wire/modules/process/ProcessPagesExportImport/ProcessPagesExportImport.module Newer methods such as $this->wire() will gracefully degrade to the older wire() function, ensuring smooth and uniform operation in ProcessWire 2.2 - 2.7. Use This module and class is for supersusers only and has only 1 aim; to export ProcessWire 2.x sites ready for importing into ProcessWire 3.x sites. You can either install (like any other module) and use the process module (ProcessPagesExport.module) or skip the install and just include and use the class (PagesExport.php) to export your sites. Both the module (Export GUI) and API require that you are logged in as a supersuser before you can use them. The PagesExport class has a gateway method and option not found in the original class (PagesExportImport). The method export() allows access to the three export methods in the original class, i.e. pagesToArray(), exportJSON() and exportZip(). See example usage below. GUI/Process Module On install, the module will create a new admin page Export Pages. Please note that unlike the original code, this page is created directly under /admin/ and not /admin/pages/. Click on Export Pages to start. Nothing much has changed from the original ProcessPagesExportImport. In older ProcessWire versions where InputfieldSelector was not available, the module will instead present you with a text input to specify a valid (for that version of ProcessWire!) selector for finding pages. The other two methods for adding pages (add pages manually or add by parent) are still available. Custom JS ensures older installs without showIf functionality still get the inputfield dependency treatment. API export($items, $options) PageArray $items: The PageArray to export. Array $options: In addition to the options in the original class that you can pass to pagesToArray(), there are two more options here. mode to specify the export type (array or json or zip) and fieldNamesExclude, to specify fields to exclude from the export. Note that the original class option fieldNames still works. It's for specifying the fields to include in the export. // API USAGE // get and include PagesExport class /* @note: you'll need to include the path differently if you are using the class directly without installing the Process module */ $path = $config->paths->ProcessPagesExport . 'PagesExport.php'; require_once($path); // create new instance of the class $siteExport = new PagesExport(); // find items to export /* a. export whole site! (minus admin and children) careful! in some cases, better to export in batches */ //$items = $pages->get('/')->find('has_parent!=2'); // export a batch of pages $items = $pages->find('template=basic-page|computer'); /* you could also use these methods directly #$data = $siteExport->pagesToArray($items); #$data = $siteExport->exportJSON($items); #$data = $siteExport->exportZIP($items); */ $options = array( // @kongondo addition: export to screen as 'array' or 'json' OR export to zip // zip will be saved in /site/assets/backups/PagesExport/ 'mode' => 'array',// array or json or ZIP // export only these field names, when specified 'fieldNames' => array('images', 'files', 'multi_pages'), // @kongondo addition: exclude fields from export. Here we exclude 'body' field 'fieldNamesExclude' => array('body'), ); // get the export $data = $siteExport->export($items, $options); if(is_array($data)) { echo '<pre> EXPORTED SITE USING pagesToArray '; print_r($data); echo '</pre>'; } // JSON export else echo $data; Screenshots See also the links to Ryan's blog posts above. ProcessWire 2.2 ProcessWire 2.4 ProcessWire 2.5 ProcessWire 2.7 Video Demo (Sorry, long and boring) Demo shows various exports from ProcessWire 2.x and their importing into ProcessWire 3.x. Remember the old Skyscrapers site profile? See how a whole Skyscrapers site gets exported from a ProcessWire 2.7.3 site and imported into a ProcessWire 3.x starting from here.

LyriChord is a Fieldtype, Inputfield and Markup module that lets you input a song's lyrics and optionally chords. You can input these manually or by importing from your clipboard. Inspired by the challenge posed by @oscarale in this thread: The markup module is optional. You can output your song the way you wish. For the HTML I prefer to use tables as they make it easier for things to be aligned properly without having to play around much with the CSS. Planned Features IMPORT XML HTML JSON CSV OCR PDF Other? NOTATION Staff? Guitar Tabs Solfa BOOKS Song books Pagination? EXPORT OTHER Support for syllables Transpose ??? Project + Download TBD soon. I need to cleanup a few things Quick(-ish) Demo

Hey thanks @elabx I guess so! If other people find it useful and can build upon it then that would be great. I've just added support for Matrix items and a related Module, which is essentially a front-end (in Processwire) for managing import and export. The only issue is I'm not very familiar with open-sourcing a Module and all the pull requests etc etc. But I suppose if it's open source then other people can handle that too?