Search the Community

I'm getting the following error, breaking the JSON output of a template (named json.php) i've built to answer a getJSON() JS call and output JSON to feed a popup: Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 83906560 bytes) in /server_path_to_my_root_folder/site/modules/TracyDebugger/includes/TD.php on line 115 As I'm using tracy heavily in templates delivering HTML and JSON as well for a long time now, I'm suspicious this occurs since a recent update to version 5.0.37 and stays throwing errors with version 5.0.38. While looking around, I found this error message in tracy's exceptions tab: Warning: file_get_contents(/server_path_to_my_root_folder/site/modules/TracyDebugger/tracy-2.11.x/src/Tracy/BlueScreen/../assets/reset.css): Failed to open stream: No such file or directory in /server_path_to_my_root_folder/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.11.x/src/Tracy/BlueScreen/BlueScreen.php on line 182 the exhaust error breaks the JSON structure and the popup is waiting for the template's return forever. When I delete all bd() calls from json.php everything works fine and the return of it comes back fast (I don't work locally, but already on a production-identical webspace). As soon as I'm inserting a single minimal bd() call, the template out is broken by tracy with the error message above. When using tracy on "normal" page templates with HTML output i don't see any errors. Any ideas where to turn some screws to get rid of this error?

I've been doing some testing with Agent Tools. My setup is MAMP Pro (PHP 8.3.30), using OpenAI (GPT-5). While I can see responses in the Conversation History, every request initially results in an Error 500. Only after reloading the page, I can return to Engineer tab and then see the response in the Conversation History. I can't figure out why this is happening as there are no errors logged at all, neither in the PHP / Apache logs. The only error I saw logged was this from the installation: files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools filePutContents: Unable to write: [redacted]/site/assets/at/jobs/failed/.htaccess files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools mkdir: Unable to mkdir [redacted]/site/assets/at/jobs/failed/ files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools filePutContents: Unable to write: [redacted]/site/assets/at/jobs/done/.htaccess files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools mkdir: Unable to mkdir [redacted]/site/assets/at/jobs/done/ files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools filePutContents: Unable to write: [redacted]/site/assets/at/jobs/running/.htaccess files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools mkdir: Unable to mkdir [redacted]/site/assets/at/jobs/running/ files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools filePutContents: Unable to write: [redacted]/site/assets/at/jobs/pending/.htaccess files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools mkdir: Unable to mkdir [redacted]/site/assets/at/jobs/pending/ ...but these folders have in fact been created: PW Debug mode is on, and so is Tracy. Any suggestions as to how to get beyond this point?

Thanks @adrian, working great now. Yes, love this feature here, and in the Tracy Console too. Thanks for adding it!

There is a panel on tracy to see all the database queries executed, maybe something there?

I have quite a quite large template having 57 fields. Now the saving of a page with that template takes over a minute on the production server. The server is a shared webhotel server with PHP 8.2. On my own vps server the saving takes under 3 seconds. Tracy shows in the timers for the last save stage, the redirect to ?id=222&s=1&c=0, 1,2 seconds time. But the Execution time for this in System info is 1400 ms. Where can I see what causes the one minute delay? I can't find the point in Tracy panels to debug more.

Thanks for the fast response. Unfortunatelly the sync screw up the TracyDebugger (Error: Failed opening required 'C:\inetpub\wwwroot\site\modules\TracyDebugger/tracy-2.12.x/src/tracy.php') and I had to restore it form the GH repo. In the logs: 2026-05-13 09:28:15 admin http://localhost/processwire/setup/gitsync/sync/ [manual] Sync "TracyDebugger" branch "master": 1121 remote, 987 local, 980 to update, 980 to delete (134 preserved via .gitignore/.gitattributes) 2026-05-13 09:28:23 admin http://localhost/processwire/setup/gitsync/sync/ Using ZIP archive for 980 file update(s) (>50 threshold) ... 980 files updated ... 2026-05-13 09:28:27 admin http://localhost/processwire/setup/gitsync/sync/ [manual] Synced "TracyDebugger" to branch "master" (commit 068bbd9) – 980 updated, 980 deleted Not sure what happened, but when the site failed with the exception, the TracyDebugger folder only had 6 files on the root. Other folders, like assets, panels, includes were all missing. It's odd since the log shows: 2026-05-10 18:25:51 admin http://localhost/processwire/setup/gitsync/sync/ Updated: panels/AdminToolsPanel.php (8396 bytes) ... 2026-05-10 18:25:47 admin http://localhost/processwire/setup/gitsync/sync/ Updated: includes/post_processors/AdminToolsPost.php (4138 bytes) Will try to debug later, I'm at work now 🙂

Hi, @maximus, since we do not use OpenAI products (company policy) I haven´t tried Codex at all. But nevertheless, that workflow works — GitSync reacts to any git push, regardless of whether the commit comes from a human, CI, or an agent like Codex Cloud. @matjazp: Thanks for the detailed log — that pinpointed the problem clearly. Three fixes are now in main: PHP execution timeout lifted during sync (set_time_limit(0)). The 500 you hit was almost certainly PHP killing the script at 30–60 s, not GitHub timing out. Large diffs now use the ZIP archive endpoint. When more than 50 files need updating, GitSync fetches a single ZIP of the branch via /zipball/{ref} and copies from the extracted archive instead of hitting /git/blobs/{sha} once per file. Your 1115-file diff turns from ~1115 sequential HTTPS requests into 1 download plus local copies. GitSync now respects two sources at once: .gitignore (which spares Tracy's runtime files like logs/, dumps/, bluescreen/) and .gitattributes export-ignore (which keeps maintainer-excluded files like docs/ and .gitattributes itself off the live install). Both apply bidirectionally — files matching either are never added by the sync and never deleted from local. End result for TracyDebugger: install + first sync = "up to date" with zero unnecessary churn. Please switch to the GitSync branch refactor-install-from-Github in GitSync and give it another try — the log line for the sync should now show N to update, M to delete (P preserved via .gitignore/.gitattributes) – both N and M considerably lower than your original 1115/4430, and you'll also see Using ZIP archive for N file update(s) whenever the update count is above the 50-file threshold. We will merge the branch into main after some internal testing, so feedback is welcome 😉 Cheers, Mike

Hi, @matjazp thanks for the report! We fixed it by removing the 3 calls. Just upgrade the module to 0.2.1 They solve different problems. ProcessWireUpgrade is for stable releases, GitSync is for branch-based development workflows. ProcessWireUpgrade pulls from the official modules.processwire.com directory and compares semantic version numbers. It can upgrade the ProcessWire core itself (master or dev branch) and existing installed modules, but it cannot install new modules that aren't already present, doesn't support private repositories, doesn't support arbitrary branches per module, and uses a pull model (no webhook / no auto-sync on push). Each upgrade is a full download. GitSync pulls from any GitHub repository — public or private (using a fine-grained Personal Access Token for the latter). It works at the branch and commit level rather than the release level, lets you switch any linked module to any branch, and detects changes by comparing git blob SHAs file-by-file, so only modified files are downloaded. It can install brand-new modules from a GitHub URL (even ones not listed in the official directory), supports private repos, and offers GitHub webhook integration for automatic sync on every push. It does not upgrade the ProcessWire core. When to use ProcessWireUpgrade: Production servers that should only move to officially released versions Upgrading the ProcessWire core itself Mostly relying on modules from the official directory When to use GitSync: Test/staging servers that should track a development branch (e.g. develop, feature-x) live Deploying your own modules from private repositories without FTP Installing GitHub-hosted modules that aren't (yet) in the official directory Auto-deploy on every git push via webhook They can be combined: use ProcessWireUpgrade for the core, and GitSync for modules that you develop yourself or that aren´t in the PW directory. To narrow this down — could you share: Which action failed? Install from GitHub, Link Module, or Sync/Upgrade of an already-linked TracyDebugger? The error or behavior you saw — blank page, timeout, rate-limit message, partial sync, etc. The last lines of the gitsync log under Setup > Logs > gitsync. Whether you have a GitHub Personal Access Token configured (without one you're capped at 60 API requests/hour). The file count alone (~1,250) shouldn't be a problem for a normal upgrade — only changed files are downloaded. But it would be a problem for a fresh Install from GitHub, where every file is fetched in its own API call. The log will tell us which case you hit. We just tested and ran into zero problems: We installed Tracy via the Modules page added it to GitSync via the dropdown synced master branch One known gotcha worth checking: TracyDebugger writes runtime files (logs, bluescreens, dumps) into its own module directory. GitSync deletes local files that don't exist in the remote repo, so a large toDelete list with permission-protected files could also cause the upgrade to fail mid-way. Cheers, Mike

Hi @RuiVP - The listing of adminer-4.8.1-mysql.php indicates that you were running a version of Tracy that was at least two years old. The was an old unmaintained version of Adminer. We now use AdminNeo which is actively maintained. Side note: Adminer is also being maintained again after a very long hiatus, but I prefer the AdminNeo fork (the author and the product). That said, some shared hosts will always falsely flag tools that can manipulate the DB. They don't take into consideration that the tool is gated and only available to authorized users. I leave Tracy installed on all sites - in production mode it logs errors and full bluescreen traces as HTML files you can view. It can also email (or notify via Slack) of these errors so you get instant notification of issues.

Hello. Apparently I have a problem with Tracy adminer. Presently using last PW version + PHP 8.5 in my development instalation. At the time of the problem, I don't know what TracyDebugger version I was using. PHP was 8.0 or lower. The problem: I received an email from the server support, telling something like (translated) "Please be advised that the account ‘rumors.pt’ has been found to be overloading the system. You must urgently check and rectify the website’s security." The site is down (I suppose it is suspended for security reasons). Before asking the server admin to reopen it, I would like to know if other similar cases were reported, and, if that's the case, to have your opinion. Here goes the server's imunify360 log from the server: Malicious Reason Status Actions /home/c0010270/.trash/site.1/modules/.TracyDebugger/panels/Adminer/adminer-4.8.1-mysql.php SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 Content removed Scan type: background Cleaned 12 days ago Original (infected) file will be removed in 2 days /home/c0010270/.trash/site.2/modules/.TracyDebugger/panels/Adminer/adminer-4.8.1-mysql.php SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 Content removed /home/c0010270/.trash/site.3/modules/.TracyDebugger/panels/Adminer/adminer-4.8.1-mysql.php SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 Content removed /home/c0010270/.trash/site.4/modules/.TracyDebugger/panels/Adminer/adminer-4.8.1-mysql.php SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 Content removed /home/c0010270/.trash/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/Adminer/adminer-4.8.1-mysql.php SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 Content removed /home/c0010270/.trash/site/modules/.TracyDebugger/panels/Adminer/adminer-4.8.1-mysql.php SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 Content removed /home/c0010270/.trash/site/modules/TracyDebugger/panels/Adminer/adminer-4.8.1-mysql.php SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 Content removed /home/c0010270/rumor.rumors.pt/site/modules/.TracyDebugger/panels/Adminer/adminer-4.8.1-mysql.php SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 Content removed Remarks: 1) A (new) similar (copied) development version of the site seems to work ok in my computer. 2) In fact this is the second time a PW site maintained by me goes down, apparently caused by external "interferences". I suppose I have to review the security issues and the rules of access to files and folders (presently 755/644). 3) Probably there is no point in keeping Tracy in a public site. What is the common procedure? Wishing you a fine weekend, Rui VP

Ok glad Tracy is fixed, but I would strongly advise against using PHP 8.0 - no security updates isn't worth it. Just report the issues to those module authors and deal with the deprecation warnings until they are fixed (or fix them yourself locally in the meantime).

Quick test with PHP versions: PHP8.0.30 -- test <?php echo "<p>que chatice</p>" ?> -- result: "Exception: Cannot access non-public property Tracy\FileSession::$file on line: 95 in C:\wamp64\www\cadpp.org\site\modules\TracyDebugger\includes\CodeProcessor.php" PHP8.5.6 -- seems to work ok in general and with Tracy, but some modules seem to need adaptation to the new PHP version: Errors resulting from deprecated instructions in some modules: Deprecated: mb_convert_encoding(): Handling HTML entities via mbstring is deprecated; use htmlspecialchars, htmlentities, or mb_encode_numericentity/mb_decode_numericentity instead in ...\TextformatterFluidImages\TextformatterFluidImages.module:52 Deprecated: Use of "self" in callables is deprecated in ...\TextformatterSoundmanager\TextformatterSoundmanager.module:582 Deprecated: mb_convert_encoding(): Handling HTML entities via mbstring is deprecated; use htmlspecialchars, htmlentities, or mb_encode_numericentity/mb_decode_numericentity instead in ...\TextformatterFluidImages\TextformatterFluidImages.module:52 Once again, thank you for your titanic effort to adapt Trac to PW!

8.2 is also past its end of life and isn't getting bug fixes anymore. Just go to at least 8.4, if not 8.5. Did the very latest version of Tracy still have issues with 8.0? I fixed the last one you reported - did you see more errors?

Solved! (apparently...) I downloaded PHP 8.1.34 and 8.2.30 for Wampserver. 8.2.30 raises some problems and errors on PW and/or some modules. With 8.1.34 Tracy stops complaining and shows no errors. I need more time to check out effects on other modules. Thank you, Adrian

Sorry @RuiVP - looks like there was an issue with getNonce() helper in the version of the Tracy core you were using. Please update to the latest version which should fix things for you.

Hello. I used to work with TracyDebugger in my development site (Windows 10 home + Wampserver + PHP 8.0.30). When I tried to update the module, I got error "Call to undefined method Tracy\Helpers::getNonce()" I also get in Tracy's report: From there on, I couldn't access anymore any site page. The only solution to keep working was to delete Tracy's folder in module folder. This means I can't even clear database data from this module. Can you figure out what is going on? Thanks in advance, but please take into consideration that I'm not a programmer.

The Tracy core now supports some new AI agent tools: https://github.com/nette/tracy/releases/tag/v2.12.0 I have included this new version, but also extended it so there is now a new bluescreen panel with the Agent Markdown version for easy copying into your AI deity of choice. I also added a copy MD to clipboard button for those exception files generated by guest users (in production mode):

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.