Search the Community

I'm not getting it done as quickly as I'd like. Most of the modules were written in February and March, when I had free time. Regarding the topic, yes and no. I want to standardize everything so that it looks native. Everywhere and always. And also the UI and UX should be convenient. So that when you open the Tracy dashboard at 3 AM, it doesn't look like a bright light, nothing more. @Ivan Gretsky

@maximus Seeing the speed with which you produce new cool modules just maybe you could come up with a custom theme css pretty quickly: - https://forum.nette.org/cs/31690-dark-mode-pro-tracy-css (translate from Czech) - https://github.com/nette/tracy/blob/ab7b1d19c0de130bed6de5b30c9ad7884131b465/src/Tracy/Debugger.php#L107-L111 It is already possible to change the debugger output to dark natively like this Debugger::$dumpTheme = 'dark'; (https://tracy.nette.org/en/dumper), but that is already by default, as I understand.

I have read this a couple of times. But as I am not as fluent in AI dev I couldn't quite grasp the whole workflow idea. So let me explain as I understood it and make my points. I think most devs develop in either IDE like VS Code with an AI extension, Zed and such or in CLI with Claude Code, OpenCode etc. They want their agents to be able to test certain url and see if there are any errors or warnings. I guess it is already possible by telling agents where the Tracy logs are and how to read them. AI has or could easily gain access to those anyway. An MCP could be intermediary here but does it help with anything? Another way would be to use the newly introduces CLI modules that could query an URL and return it along with debug info from Tracy. Just maybe AI agents can now debug in the browser, but that seems like a too complicated scenario. Am I misunderstanding something?

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.

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.

Well, it's been about a year in the making, but v5 is finally available. I have upgraded a lot of sites to it now without issues, but I would still caution you to be ready to revert (or delete module) files if the namespace changes cause any issues - there were a lot early on. The two new banner features are: the console panel can now run very long running scripts (there is a one hour limit just so that broken scripts don't run forever) which is great for massive batch modifications or the like. The dumps recorder panel (either manually loaded or via Enable Guest Dumps) now live polls for new dumps so you don't need to continually load the page to see the entries as they are logged. Have fun! Breaking Changes - Minimum requirements bumped to ProcessWire 3 and PHP 7.1 - Removed legacy Tracy 2.5.x core branch and FireLogger support - Panel DOM IDs now include `ProcessWire-` prefix — update any custom CSS/JS targeting panel IDs Namespace Support - Full `namespace ProcessWire` support across all panels and POST processing files - Autoloader bridge for seamless non-namespaced to namespaced module migration - Third-party panels bridged automatically via `class_alias()` Security - Comprehensive security hardening: XSS sanitization, CSRF protection on all panels, directory traversal fixes, CSP nonces on all inline scripts, cookie SameSite enforcement, and input sanitization New Features - Console — long-running scripts automatically switch to background polling, surviving gateway timeouts; session locks released so you can continue browsing while scripts run; storage migrated to IndexedDB - PW Version Switcher — extracted into its own class with automatic version reverting on failure - Dumps Recorder live polling — live-polls for new dumps from other users and guest sessions - File Editor BlueScreen integration — exception page links open in the built-in file editor - Various smaller additions across Diagnostics, API Explorer, Request Info, and PW Info panels Bug Fixes - PHP 8.x compatibility fixes for `htmlspecialchars()`, `trim()`, and `isset` null handling - Fixed Console panel snippet and polling issues, including cache-busting for CDN/proxy environments - Fixed File Editor not opening files linked from BlueScreen exception pages - Fixed Adminer URL/namespace issues and thumbnail viewer path handling - Fixed Debug Mode panel to use modern API methods instead of deprecated ones - Fixed API Explorer "What's New" section and reflection errors for hooked methods - Fixed "unsaved changes" false positive when saving pages in PW admin - Windows path and line ending fixes Performance - Session lock contention reduced - Various loop and query optimizations

If anyone is interested in being able to set script-src-attr to "none" on the frontend of their sites, the namespaced branch of Tracy now uses eventListeners everywhere - no more inline handlers.

Think I got it working, but not sure which of these steps were needed. Posting in case others find it helpful. I uncommented RewriteBase / in .htaccess I truncated the cache in the database with Phpadmin6 (I'd avoid this one if the others work first!) Using Tracy Debugger > Clear sessions, cookies & module refresh. A normal browser cache clear didn't work for me.

Thank you @maximus I checked both issues and they are indeed resolved. I wonder if you use Tracy Debugger for the admin? It is easy to spot warnings if it always runs, which is the case for me almost all the time. Sometimes, I disable it when I need unmodified HTML in the browser, but after that I reenable it. BTW, could you make the /site/assets/context path configurable? I recently tested PHPStorm with Junie by adding to its .junie directory what @interrobang shared with us: https://processwire.com/talk/topic/29439-cursor-might-be-my-vscode-replacement/#findComment-251674 Specifically: https://github.com/phlppschrr/processwire-knowledge-base/tree/master I adjusted the root SKILL.md (removed references to Python scripts and such) and Junie can pick up all skills perfectly. If I could set the module to generate files to /.junie/skills/docs, the Junie agent would start using them too. That would be real magic :)

Hello @adrian that's great, I had an older version (from 2022) on my machine, so I installed it on my local ProcessWire which I use for my French translations (so it's not necessarily representative of all situations, as it's always up to date with the latest version, ProcessWire 3.0.256 © 2026). then I commented out the module folder and replaced it with the namespaced version folder. After a short normal update time, the only thing visible was a small alert ModulesInfo: Upgrading module (TracyDebugger: 4.23.40 => 4.28.0) the site is still up and running, no errors, and Tracy seems to be working fine. tried on a php 7.4.9 and 8.1.31 hope this may be somehow useful have a nice day

Hi everyone, Well, I finally have a version of Tracy which is ProcessWire namespaced. This has not been easy, although the last issue (which was breaking sites on upgrade from an old non-namespaced version) finally seems to be resolved thanks to some AI help. Unfortunately because this version took so long I lost patience with maintaining separate branches so it also includes a move to IndexedDB instead of LocalStorage for Console data (since I added the multiple tabs if you dumped a lot of content across several tabs it was possible to hit the 5MB LocalStorage limit). It also includes a lot of other random fixes and security improvements (although I think mostly hypothetical given the access restrictions to it). I have also dropped support for PHP < 7.1 (inline with PW). If anyone would be willing to test the upgrade from https://github.com/adrianbj/TracyDebugger/archive/refs/heads/namespaced.zip I'd really appreciate it. Please only test on a dev site and if you do run into any issues, the best way to recover is to delete TracyDebugger folder from /site/modules folder and go back to the admin and reinstall, but hopefully this is no longer a problem. Thanks, Adrian

Generates a .phpstorm.meta.php file for ProcessWire autocompletion in PhpStorm. Features Autocomplete wire container keys for wire('...') and Wire::wire('...') Autocomplete module names for Modules::get() and Modules::install() Autocomplete field names for Fields::get() Autocomplete template names for Templates::get() Autocomplete unique page names for Pages::get() Autocomplete hookable methods for Wire::addHook*() Autocomplete page status constants/strings for Page::status(), addStatus(), removeStatus(), hasStatus() Autocomplete field flags for Field::addFlag(), removeFlag(), hasFlag() Autocomplete template cache-expire constants for Template::cacheExpire() Autocomplete Inputfield collapsed constants for Inputfield::collapsed() Autocomplete sort flags for WireArray::sort()/sortFlags()/unique() and PageArray::sort()/sortFlags()/unique() Optional: Field type autocompletion per Page class (when enabled in module config) Usage Default path: site/assets/.phpstorm.meta.php (configurable in module settings). The file regenerates automatically when fields, templates, or modules change (debounced). You can manually regenerate from the module settings screen. Optional: enable "Generate page-class field metadata" in module settings for field type hints per Page class. This is intentionally basic. For richer field stubs, use AutoTemplateStubs. Examples Modules $tracy = $modules->get('TracyDebugger'); // Autocomplete + correct class type for navigation and code insight Wire Container $page = wire('page'); $pages = $this->wire('pages'); $cache = wire('cache'); // Autocomplete for keys like page/pages/cache/etc. Fields $body = $fields->get('body'); // Autocomplete field names, fewer typos Templates $tpl = $templates->get('basic-page'); // Autocomplete template names Pages $home = $pages->get('/'); // Maps to the page class when page classes are enabled Page Status $page->status(Page::statusHidden); $page->addStatus('draft'); $page->removeStatus(Page::statusUnpublished); $page->hasStatus('locked'); Field Flags $field->addFlag(Field::flagAutojoin); $field->removeFlag(Field::flagAccess); $field->hasFlag(Field::flagGlobal); Template Cache Expire $template->cacheExpire(Template::cacheExpireParents); Inputfield Collapsed $inputfield->collapsed(Inputfield::collapsedYesAjax); Sort Flags $items->sort('title', SORT_NATURAL | SORT_FLAG_CASE); $items->sortFlags(SORT_NATURAL); $items->unique(SORT_STRING); Page-Class Field Metadata (Optional) $home = $pages->get('/'); // $home is HomePage (page class) // Field types are inferred from the template fieldgroup // e.g. $home->hero_image -> Pageimage or Pageimages depending on field settings Hooks $wire->addHookAfter('Pages::save', function($event) { // Autocomplete hookable methods while typing the hook string }); Notes Hook scanning reads ProcessWire core, modules, and admin templates to build the hook list. If page classes are enabled, page names map to their page class; otherwise they map to Page. Improvement suggestions and PRs are welcome. https://github.com/phlppschrr/ProcessWirePhpStormMeta

That's weird. I simplified it down to the bare minimum as per the example, and still not working. I wonder if it's some strange third party module interaction? I don't a lot of modules beyond the core loaded, just these: I've tried disabling all autoload modules (other than core) via Tracy debugger, and the problem persists.

<?php namespace ProcessWire; if($config->ajax) { bd('AJAX request detected'); echo "Replaced page content"; exit(); } ?> <script> function loadlist(segment='') { var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById("main").innerHTML = this.responseText; } }; xhttp.open("GET", "<?=$page->url?>"+segment, true); xhttp.setRequestHeader("X-Requested-With", "XMLHttpRequest"); xhttp.send(); } </script> <div id="content"> <div id="main">Basic page content</div> <p><button onclick="loadlist('')">Load List</button></p> </div> Note the replacement of the text in "main" and that Tracy detects the AJAX request.

I enabled a site module extending a core module: class ProcessPageEditImageSelect_Pickpage extends ProcessPageEditImageSelect implements Module, ConfigurableModule { public static function getModuleinfo() { return [ 'title' => 'Page Edit Image pickfrompage', 'summary' => 'Extends core module: Enables specifying a default page to pick images from if the page being edited has no image fields.', 'autoload' => true, 'permission' => 'page-edit', ]; } public function __construct() { parent::__construct(); } public function init() { parent::init(); bd($this->data); } public function ___execute() {} public function getModuleConfigInputfields(array $data) { $inputfields = $this->wire(new InputfieldWrapper()); $modules = $this->wire()->modules; /** @var InputfieldPageListSelect $f */ $f = $modules->get('InputfieldPageListSelect'); $f->attr('name', 'defaultPage'); $f->attr('value', @$data['defaultPage']); $f->label = $this->_('Default page for images if no image fields'); $f->value = @$data['defaultPage']; $inputfields->add($f); /** @var InputfieldPageListSelect $f */ $f = $modules->get('InputfieldTextarea'); $f->attr('name', 'templateDefaultPage'); $f->attr('value', @$data['templateDefaultPage']); $f->label = $this->_('Default page by template for images if no image fields'); $f->notes = "1 pair of selectors `{template}:{page}` per line, e.g.,: `1:/home/`, or `home:1`, or `contact:template=home`"; $f->value = @$data['templateDefaultPage']; $inputfields->add($f); return $inputfields; } } where the execute method is the one here and the init method returns the core module's data but my execute method has no effect. What's wrong with how I'm doing it? Thank you On pages where it doesn't apply, there's an error notice from the init method of the core module: Modules: Failed to init module: ProcessPageEditImageSelect_Pickpage - No page specified but nothing shows (Tracy debugging) if not autoloaded, and ___execute has no effect either way.

JFTR: I did wipe the installation and re-installed with dev version 252 (instead of 253). With 252 there were no issues installing the latest Tracy directly from the Module Repo. So this topic can be considered 'closed', as it's definitely not a Tracy issue but a dev core issue.

Thanks wbmnfktr, I did move the files manually and installed Tracy, resulting in a different 500 error upon trying to configure it. I suspect this to be a dev core issue rather than module issue. This is a new installation, so I can easily wipe this and start new. Edit: I also installed an old version of Tracy - or tried. Same error. And that version definitely used to work.

For modules that are not premium/pro modules, I'd love to see if their inclusion in core would be of benefit to the greater community. Many of, for instance, Robin S.'s modules aim to make the interface experience better for the end-user. Even if the code may not be 100% compliant to what the core expects, the very idea of the module may prove useful in improving the total user experience without the need to discover it elsewhere. Some extremely popular modules (ex: Tracy Debugger) may not be directly suited to being added to the core, so thought should be taken over its usefulness to all, not just specific circumstances or groups of people. Alternatively, is there a preferred way to request addition to core via the Feature Requests Github repository?

@Jonathan Lahijani - not sure if this is what you are looking for, but all Tracy's settings can be overridden in config.php like: $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, ]; Not sure if those are the exact options you want, but hopefully that approach works for you.

@biberI am not the one you need to convince. It‘s your data and you can do with your database whatever you like. I was just puzzled by what you want to achieve or whats your problem is or if there is any at all. All still not very clear to me to be honest. What caught my attention was that I got the impression that you wanted to alter the text representation in the database, as the database values don‘t show up UTF8 chars but store German Umlauts in an encoded representation. Thats where my advice came from, not to alter or manipulate DB charset/collation manually, if text shows up correct in the frontend. Doing so will most likely corrupt your database and you need to go deep inside the rabbit hole to get charset/collation and data right. Of course you can modify, copy, rename or delete fields with PHPMyAdmin or from the Adminer module from the backend. Adminer is part of the Tracy Debugger module for example. However, for me it‘s just not clear, what you try to do and why it‘s necessary to do. If it‘s just for experiment, than I would just go with phpMyAdmin or Adminer and change some content and see what happens. By the way. I write most of my websites with plain HTML5, CSS3 and vanilla Javascript/Typescript and or PHP 8. Just for projects with multiple users or changing content, I prefer Processwire CMS/CMF which saves me a lot of work. However in those cases I rely on the PW core and API and only modify/dig deeper into the core or database if there is a real need for me to do so.

Got it working, thank you very much! 🙂 If anybody else if having trouble, here is how to do it: First, add this to your ddev config: web_environment: - TRACY_LOCALROOTPATH=$DDEV_APPROOT/ This will add the path of the project root as getenv('TRACY_LOCALROOTPATH') in the web container so that you don't have a hardcoded path in your config. Next add these mappings in init.php: \Tracy\Debugger::$editorMapping['/var/www/html/public/'] = getenv('TRACY_LOCALROOTPATH') . 'public/'; \Tracy\Debugger::$editorMapping['/var/www/html/src/'] = getenv('TRACY_LOCALROOTPATH') . 'src/';

Hey @Pete - I maintain four different Tracy core versions which are all included and used based on the version of PHP available. I have also made a real effort to ensure PHP 7 compatibility (maybe even 5 - not sure). A Tracy upgrade is basically instantaneous on all my servers/installs so I've never thought of the compiling process as an issue. Adding a namespace is probably more of a big deal with so many panels and reliance on the Tracy core itself - maybe just a matter of lots of backspaces to start loading things from the global namespace. The one other module I namespaced was AdminActions and it was a real challenge but that was mostly due to trying to support installed custom user actions whether they were namespaced or not. Still, it put me off namespacing others. I'll try to find some time to see what's involved sometime soon.

It's only after a TracyDebugger upgrade it struggles, so it downloads the zip via the ProcessWire Upgrade module but because there are a lot of files in TracyDebugger the FileCompiler takes a while to scan and times out or runs out of memory (I forget which but timeout seems more likely). Only happens during upgrade but times out because of the network chatter (for want of a better phrase) with the EFS mount. And then it doesn't complete the upgrade basically so you have to do it via CLI. The reason for EFS in a clustered setup is that nodes (servers) in an auto-scaling group come and go as you refresh things or as the instances increase/decrease automatically in number due to traffic demands, so having the sites on local EBS on one node doesn't work at all as they'd need to maintain their own copies of all files in sync for the sites on that cluster. So in this setup you put the sites on EFS (essentially a very fast network drive) so all nodes in the cluster have apache run sites from there and it's definitely more than fast enough for normal operations, just slow for things like FileCompiler when there are a lot of files to check when compiling a module. It checks them all whether they individually have a namespace or not as it has to decide which ones need compiling so TracyDebugger with this many files makes it try and do "too much" (a relative term, I know) in this setup. I like the idea with the backwards compatibility, but is there not stuff in newer versions of Tracy that isn't compatible with PW 2.x now anyway? I don't remember if PW 2.x even supported PHP 8 - probably not much beyond that anyway - so there may be some benefit to a version that only works with 3.x at some point. Just that usually adding the namespace to modules is relatively painless (though I've had some occasions where it was a little less straightforward I'll admit 😄) and then it's one less bit of overhead when keeping modules up to date. A selfish request to be sure, but maybe I'm not the only one? 😅

Hi Adrian, My search-foo is weak today so this may have been discussed to death but I couldn't find anything specific. Is there a reason why TracyDebugger module isn't in the ProcessWire namespace? The reason I ask is it compiles otherwise when file compiler is on - which for me is most of the time as there are modules I use that are not in a namespace (I am now religiously disabling template compilation though - just a few years late to the party on that one 😄). On an AWS setup where the site files are on an EFS mount Tracy is the one module that can take ages as it's a little slower to do this on a network drive. I've even had the updater module in ProcessWire fail to update Tracy and often just do it via CLI and it seems to be entirely down to PW having to compile the module. I realise AWS setups like this may still be a bit niche in this day and age but now, having mastered AWS pretty thoroughly (auto-scaling groups - my last bit I really needed to learn - are amazing!), I wouldn't go back. Feel free to point me to where this has already been discussed - as I say my searches returned bits and pieces around namespaces but not this exact thing. (Also I've been away from these forums for too long so if anyone else likes to geek out about AWS setups maybe we can have a chat somewhere on the forums or maybe there's already one I'm missing. I miss 2012-14(ish) where I was on here every day).

Random errors are the worst! 😉 If you have TracyDebugger installed already you might also want to look into the folder /site/assets/logs/tracy You might find some tracy bluescreen html files there which you could copy to your computer and open in a browser and see something like this: You can click on each item of the trace and you'll see where the problem occurred (top arrow) and also which arguments have been sent to the method (bottom arrow). Good luck 🤞