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?

Hi all, I won't always post here when I update Tracy, but I will when I think the update is an important bug fix that you really should update to. There was a bug in the new 2.8 branch of core Tracy package that was sometimes causing recursion and really slow load times and sometimes memory exceeding errors. This has been fixed and is available in 4.21.41 of Tracy released today.

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.

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.

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?

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.

@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.

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

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 🙂

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

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.

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!

Hey @adrian, I came across a minor problem which prevents the Tracy console showing in the debug bar when bootstrapping PW in a standalone PHP script. The error shown is: ErrorException: foreach() argument must be of type array|object, null given in D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\panels\ConsolePanel.php:172 Stack trace: #0 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\panels\ConsolePanel.php(172): Tracy\Bar->Tracy\{closure}(2, 'foreach() argum...', 'D:\\laragon\\www\\...', 172) #1 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Bar\Bar.php(143): ConsolePanel->getPanel() #2 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Bar\Bar.php(115): Tracy\Bar->renderPanels('') #3 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Bar\Bar.php(89): Tracy\Bar->renderPartial('main') #4 D:\laragon\www\[sitename]\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Debugger\DevelopmentStrategy.php(123): Tracy\Bar->render(Object(Tracy\DeferredContent)) #5 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Debugger\Debugger.php(314): Tracy\DevelopmentStrategy->renderBar() #6 [internal function]: Tracy\Debugger::shutdownHandler() #7 {main} And this is what the debug bar looks like: I think it should be a simple fix - it looks like the line 172 is traversing $p->fields, but $p is a NullPage at this point. Kind regards, Ian.

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):

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

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, @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

Hello @adrian, today I setup a fresh PW install with ProcessWire 3.0.245 and of course Tracy Debugger 4.26.60. Now I don't like to have always the full Tracy bar expanded when I do simple stuff, so I hide the Tracy bar with the "Hide Tracy" button in the right corner. Today when I use the "Hide Tracy" button the Tracy bar gets collapsed as expected, but when I reload the page it is completely hidden. It seems that the #tracy-show-button has "display: none" as styling. It seems to be a console error in this line: document.getElementById("tracy-show-button").style.display = "block"; Uncaught TypeError: Cannot read properties of null (reading 'style') at hideDebugBar ((Index):204:240) Can somebody reproduce this? Regards, Andreas

Hey @adrian I'm using HTMX on my current project, specifically hx-boost which turns every regular link on the page into an ajax-powered link. It makes the request and then swaps out the content without a new page load. This is mostly great but sometimes introduces issues, for example the tracy debug bar needs to be out of the swapped area to stay on the page. I managed to do that and thought it was working well. The debug bar stays on the page and for each link that I click I get another AJAX entry in the debug bar, which is great 🙂 Today I realised that when I click the browser's back button I get this error and the debug bar disappears: tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:34 Uncaught TypeError: Cannot read properties of null (reading 'Tracy') at new Panel (tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:34:31) at tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:453:30 at NodeList.forEach (<anonymous>) at Debug.loadAjax (tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:451:48) at tool/?_tracy_bar=content-ajax.db1c54dcde_4&XDEBUG_SESSION_STOP=1&v=0.5514348022883848:1:13 Do you think this is something that can be accounted in Tracy Debugger? It's not critical, but a bit annoying. So if there is a simple solution for it I'd be thankful 🙂

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).

Hi @adrian, I'm unsure what's going on here but for a while now on a specific host (it's a cPanel server) I've been experiencing severe slowdowns when Tracy is enabled and it seems to be related to the reading of the Processwire logs Info. It's a bit like the old problem from 2022 when reasonable numbers of logs / large log files were slowing the page loading down when the debug bar was enabled. The odd thing is, I don't have the same problem on my local dev environment, or indeed on a different host, so I'm not sure where to look to troubleshoot. The environment in question is: PW 3.0.200-3.0.229 (various sites with different PW versions) PHP 8.1.32 MySQL Server: 10.6.22-MariaDB Sometimes, depending on the site and the number of log files, it can take up to 45 seconds to load, even though I've disabled the Processwire Logs panel: Whereas the same site (with the same log files) on my dev environment (and similar sites hosted elsewhere) are fine, even with the PW logs panel enabled: So I'm thinking it's some setting on the server - perhaps something like Imunify360 - could this be scanning the log files every time they're loaded and that's what's slowing it down? If I disable Tracy entirely, the same pages load happily in milliseconds, so it's some combination of Tracy and this specific server environment. I tried to disable the Processwire logs (as per the first screenshot above) but that only seems to work for a minute or so, and then the long loading time reappears. Hoping you can point me in some direction to narrow this down.. 🙏 Thanks, Ian.

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.