All Activity

I'm using github copilot now since 6 months to do all sort of testing and playing around with various projects. It offers a lot of the different agents, but it's mainly for use with IDE like VS code. I like it a lot and am always surprized at it's capability. Claude is able to help me A LOT updating a very old big online shop to the latest PW (currently local dev only) It has access to powershell to do db stuff and it understood PW very well without much help or special skills. Tho it's great to have it specialize for PW for sure. So I can't use Claude models and some of the others with my github copilot API endpoint with AgentTools, but it allows me to use gpt-4.1 and gpt-4o for free which is cool for simple stuff like engineering and migrations. I'm testing it locally currently. I now also made an account at Antropic to use that as well in case I need it. I have a local docker environment with php, mysql and apache running in a container. Claude had to adapt the pw-at.sh script quite a bit to make it work. I have no clue about this stuff, but it's working now. Thanks very much for the AgentTools module.

Oh I didn't see that. I was gone for 7 years 😄 Thanks for the heads up.

Welcome back Soma, nice to have you here again, after such a long time.

Ryan did a nice blog post about this a few months back - https://processwire.com/blog/posts/api-variable-best-practices/

Sorry for confusion Soma. I meant that post on Tuesday was my first for a long time. Everything has been running fine with my PW sites for years so I haven't been here and that's what I meant. But now I have this problem ..and others. But for now I am concentrating on solving this one I posted above on Tuesday. I'm going back to basics and trying to find out why it works on my localhost but not on the live server. A clean install of the latest PW 3.0.255 blank site profile does work on the live server. During that I saw that the SQL storage engine is innoDB by default (good thing) but my sites were always myISAM but I think you're right - it shouldn't matter when importing a d.b. The wireRenderFile undefined is strange because I can find the function in the core files on the live server so file is not missing. I will continue playing and report back any progress. Thank you Soma for your interest.

https://processwire.com/blog/posts/multi-instance-pw3/ Not 100% sure it really matters tho you should be fine with global wire(). But Multiinstance PW installation could be an issue in some edge cases with modules that save data. Tho can't really tell for sure in detail. Maybe @ryan would have some more insight.

You posted this thuesday? Not sure what you mean been a while. Not sure about the innoDB, but I don't think it matters unless for some index stuff? Surely not related to your problem I guess. Even tho I don't know what problems you mean.

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

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

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

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

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

Maybe some core files are missing on the server? It can happen that uploading a complete upload to a new server misses a file or something.

I made a little update to 1.3.7, bringing it to the current PHP8+ and PW3+ standards. Changes in 1.3.7 (2026-04-22) Updated for ProcessWire 3.x and PHP 8.x compatibility Declared class properties explicitly to fix PHP 8.2 dynamic property deprecation Fixed nullable type hints on render() signature (?array, ?Page) required since PHP 8.0 Replaced global wire() calls with $this->wire() for correct PW3 multi-instance scoping Replaced new PageArray() with $this->wire(new PageArray()) for proper instance binding Replaced object identity comparisons (===) with ID-based comparisons (->id ===) for $is_current and $is_root Replaced loose null comparisons (!= null) with strict (!== null) throughout Fixed misleading single-line if/else in xtemplates block with proper braces Removed unused $v_unformatted variable in parsePlaceholders() Replaced $this->fields / $this->users magic access with $this->wire('fields') / $this->wire('users') Updated getModuleInfo(): added icon, requires (PHP>=8.0, ProcessWire>=3.0.0), updated href to https Bumped version from 1.3.6 to 1.3.7 I only tested it on a site I'm currently working on, and it still works the same. But if you encounter any issues please let me know.

PromptWire 1.7.0 is out with 4 new MCP tools, bringing the total to 40. Latest tools are listed below. I haven't 100% fully tested a site sync yet, so always back up your existing site, database and files. pw_site_compare compares your local and remote sites across pages, schema, and template/module files. Pages are matched by URL path rather than database ID, so it works reliably across environments with different auto-increment sequences. You can exclude templates (e.g. user, role, licence pages) to focus the diff on what you actually intend to deploy. pw_site_sync (my favourite) orchestrates a full deployment in one operation: compare, back up the target, enable maintenance mode, push schema, push pages with their file/image assets, push template and module files, disable maintenance. It runs in dry-run mode by default so you see the full plan before anything is touched. Scope can be narrowed to just pages, schema, or files. pw_maintenance toggles maintenance mode on local, remote, or both sites. A styled 503 page is served to visitors with appropriate Retry-After and noindex headers. Superusers and the PromptWire API bypass it, so you can verify changes and keep the agent working during a deployment. pw_backup creates database dumps (using ProcessWire's WireDatabaseBackup) and zip archives of site/templates and site/modules. You can list, restore, or delete backups from either environment. The backup directory is auto-protected with .htaccess so SQL dumps are never web-accessible. HTTPS enforcement. The API endpoint rejects plain HTTP with a 403 before the API key is checked. PROMPTWIRE_ALLOW_HTTP in config-promptwire.php bypasses this for local dev only. Autoload change. The module is now autoloaded to intercept front-end requests during maintenance mode. The cost is a single file_exists() check per page load. Documentation updated across all pages at peterknight.digital/docs/promptwire/v1/

Hey @Soma this message was intentionally put on all my open source modules by me back then when Russia invaded Ukraine and tried to make people believe it is just a three day special operation and not a war. I've had this on all my modules and this is one of the few where it is still visible. But yeah... unfortunately it is still true 😞

this message from repo https://github.com/BernhardBaumrock/TemplatePreviewImages

There's a weird message on that module page? Anybody noticed? https://processwire.com/modules/template-preview-images/

Thank you for this module. 🙂 TinyMCE support would be great.

Sorry, haven't tried them yet.

Hi @PWaddict - just wondering how things are working out for? Did you also try the new v2?

PromptWire 1.6.0 is out with 7 new MCP tools for database inspection, log reading, and cache management. The total is now 36 tools. Latest are: DATABASE TOOLS pw_db_schema Inspect database tables. Without arguments it lists all tables with engines, row counts, and sizes. Pass a table name for detailed columns, types, keys, and indexes. Example output: table: pages columns: id int(10) unsigned PRI auto_increment parent_id int(11) unsigned MUL templates_id int(11) unsigned MUL name varchar(128) MUL status int(10) unsigned MUL modified timestamp MUL created timestamp MUL indexes: PRIMARY, name_parent_id (unique), parent_id, templates_id, status pw_db_query — Execute read-only SELECT queries. Only SELECT, SHOW, and DESCRIBE are allowed; mutations are blocked. A LIMIT is auto-injected if you don't include one. Example output: SELECT id, name, templates_id, status FROM pages ORDER BY id DESC LIMIT 5 id | name | templates_id | status 1703 | v1-15-4 | 72 | 1 1702 | test-05-brief-... | 59 | 1025 1701 | nyhavn-lufthavn | 59 | 1025 pw_db_explain — Run EXPLAIN on a SELECT query for performance analysis. Useful for diagnosing slow queries and confirming index usage. pw_db_counts — Quick overview of data volume. Shows row counts for core ProcessWire tables (pages, fields, templates, modules, caches) and the 20 largest field data tables. Example output: Core tables: pages: 605 | fields: 76 | templates: 53 | modules: 126 Top field tables: field_title: 599 | field_pkd_mediahub_mime: 254 | field_pkd_mediahub_image: 168 LOG TOOLS pw_logs — List available log files, or read and filter entries from a specific log. Filter by level (error, warning, info) and text pattern. Example output errors 138.5 KB 2026-04-20 exceptions 101.9 KB 2026-04-21 media-hub 38.4 KB 2026-04-21 modules 30.9 KB 2026-04-21 session 22.0 KB 2026-04-21 pw_last_error — Retrieve the most recent error from the error and exception logs. No parameters needed. Example output: 2026-04-21 15:47:56 [exceptions] SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_images.width' CACHE TOOL pw_clear_cache — Clear ProcessWire caches by target: all, modules, templates, compiled, or wire-cache. Useful after deploying changes or when things feel stale. Example output: target: modules cleared: [modules] success: true All 7 tools work via both local CLI and remote HTTP API, so they're available whether you're working against a local dev site or a remote production server.

Hey everyone! I'd like to share Start - a module that replaces the default ProcessWire admin home screen with a configurable personal dashboard. The problem it solves As your ProcessWire install grows, the Setup menu gets long - on smaller screens it overflows and you end up scrolling just to reach the tools you use every day. Start is the fix: think of it as the Windows Start button for your PW admin. Pin exactly what you need - modules, pages, whatever - and get to it in one click from the home screen. The result Features Two view modes - list and icon grid, preference saved per-browser Visual drag-and-drop editor at /setup/start/edit/ - reorder groups and links without page reloads Font Awesome 6 icons - 1887 icons with a searchable popup picker PagePicker - browse the full page tree directly from the URL field Example button - auto-populates with your installed Process modules and their FA icons Widget on the default admin home page Access control via start-dashboard permission Fully translated editor UI — 20 languages including RTL support for Hebrew and Arabic Supported languages English, Russian, German, French, Spanish, Polish, Ukrainian, Italian, Dutch, Portuguese, Chinese, Japanese, Turkish, Czech, Finnish, Korean, Hindi, Hebrew, Arabic, Hungarian. Installation Install like any other module — upload or place in /site/modules/, then install via Modules → Refresh. A Start item will appear under Setup in the admin menu. Make Start your admin home screen (optional) By default Start lives under Setup. To make it open whenever you click the admin logo or navigate to /admin/: Go to Pages in the admin menu Find the Admin page and click Edit In the Process field, select Start from the dropdown Save Links GitHub: https://github.com/mxmsmnv/Start

Hi. I've recently moved a long standing site to a new server and now I get wireRenderFile is undefined on home page. So I checked on my localhost server and it is running fine on there. I'm using Markup Regions and the home page is just like all my pages using : <div id="ajax-content" pw-replace> <?=wireRenderFile('_ajax-home.php', array('id' => $page->id))?> </div> I did a clean install of 3.0.255 and it runs ok. Replaced site files and imported my d.b as usual but gives red error screen - The error I'm getting : Hmm… Fatal Error: Uncaught Error: Call to undefined function wireRenderFile() in site/templates/home.php:3 #0 wire/core/TemplateFile.php (328): require() #1 wire/core/Wire.php (413): TemplateFile->___render() #2 wire/core/WireHooks.php (1018): Wire->_callMethod('___render', Array) #3 wire/core/Wire.php (484): WireHooks->runHooks(Object(TemplateFile), 'render', Array) #4 wire/modules/PageRender.module (547): Wire->__call('render', Array) #5 wire/core/Page.php (3152): PageRender->render(Object(HomePage), Array) #6 wire/core/Wire.php (416): Page->___renderPage(Array) #7 wire/core/WireHooks.php (1018): Wire->_callMethod('___renderPage', Array) #8 wire/core/Wire.php (484): WireHooks->runHooks(Object(HomePage), 'renderPage', Array) #9 wire/core/Page.php (3097): Wire->__call('renderPage', Array) #10 wire/core/Wire.php (413): Page->___render() #11 wire/core/WireHooks.php (1018): Wire->_callMethod('___render', Array) #12 wire/core/Wire.php (484): WireHooks->runHooks(Object(HomePage), 'render', Array) #13 wire/modules/Process/ProcessPageView.module (193): Wire->__call('render', Array) #14 wire/modules/Process/ProcessPageView.module (114): ProcessPageView->renderPage(Object(HomePage), Object(PagesRequest)) #15 wire/core/Wire.php (416): ProcessPageView->___execute(true) #16 wire/core/WireHooks.php (1018): Wire->_callMethod('___execute', Array) #17 wire/core/Wire.php (484): WireHooks->runHooks(Object(ProcessPageView), 'execute', Array) #18 index.php (55): Wire->__call('execute', Array) #19 {main} thrown (line 3 of site/templates/home.php) I can login to admin on back end ok. Any attempt to view a page from admin gives the error above as they all use basic-page template with the same markup region. Like I said it all works fine on my localhost on 3.0.229 Any ideas? Thanks .

Hi @poljpocket and thanks for your response. I did make the backup with the same module as you suggest. The is JSON content at the end of the file as follows: # --- /WireDatabaseBackup {"numTables":140,"numCreateTables":140,"numInserts":19412,"numSeconds":1}