Search the Community

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.

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.

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

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

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.

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

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

Hüttenzauber - The magic of the Swiss Alps. Eat, celebrate and sleep in the most beautiful places in the mountains. Today, I am presenting to you a very cool and challenging project we tackled and successfully finished last summer. Obviously, Fruitcake is 100% a ProcessWire agency at this point but still, this project especially proves again and again that ProcessWire’s flexibility and unopinionated structure just works for us every time. Gone are the days where we are breaking and bending other CMSs to work the way we need it to work. “Hüttenzauber” is a well-known brand in the Bernese Alps skiing and hiking destinations. Lately, they expanded into other regions of the Swiss Alps and accumulated a variety of locations they are both managing and running from their central offices at the birthplace of the enterprise, Lenk im Simmental. Coding one of our latest projects to date was a cool but also daring challenge. We set out to replace a few dozen single websites for each of the different locations with one big website. The general goal was to streamline all the information and present a concise yet still quite independent experience to the website’s visitors. In addition to the independent experiences, the website features a plethora of central features like a search map, an illustrative blog, cool events and a web shop whose contents however, are again compiled together from blog articles written for or events happening at the different locations. The website was conceptualized, designed and programmed 100% in-house by us. It features tons of content which is completely available in both German and English (with a small JavaScript language detection function). ProcessWire admin: have exactly one source of truth I think we can be proud of the challenge we set out to achieve: Have every information only ever written down once. This is most beneficial for the client since they can for example change the hotel’s address once and it is then displayed at many different locations automatically. The client factually only needs to work with our database we created in the ProcessWire admin area and the website presents that information in a variety of places automatically. One example of that in action is restaurants. There are two types of restaurants: locations which actually are restaurants but also restaurants inside other locations, e.g. hotels. The client can easily a new restaurant inside a hotel (in PW terms that is just add a “restaurant” as a child of a “hotel”) and just set up all of it’s information like descriptions, menus, booking links and images. This entry will automatically display on the search map as part of the hotel, be added to the “book a table” buttons everywhere across the website and also have it’s information and download links be displayed on the hotel’s detail page. And by the way, the client also can (and does!) add hotels inside hotels, e.g. a small resort with independent booking but which factually is part of a bigger hotel complex. They add, press save and “it just works!” 🤯 To achieve this goal, we made extensive use of the beloved “addHookProperty” method to for example output a list of all the “book-a-table” links for any specific page which makes programming the front end of the website a whole lot easier! 🥳 The culmination of all this is a simple and easy tree structure in the admin area like this (this is just part of it): All the information one might add about a restaurant or hotel is entered in each entry’s fields. Every coordinate, address and image is only ever entered once. All of this for example results in the search map and floating booking buttons completely automatically: Not only there, but also in the menus: Content «Page Builder» In addition to all the meta information, all of the pages should allow to have a completely independent experience for a visitor. That is why any restaurant and hotel gets it’s own landing page which acts as a mini landing page. There, the information is broken down: Booking links show only for the location itself (remember, there still might be multiple 😉), events are automatically filtered by location and sub-restaurants are displayed automatically. Yet still, all of the content feels dynamic because we make heavy use of @ryan’s Repeater Matrix module. For some of the blocks, the information is entered directly but for others, the information is grabbed from the events catalog or the blog entries and automatically filtered as appropriate for the page where the block is displayed on. For example, the events block on a hotel page only displays events for that specific location whereas if the events block is used on the homepage, everything is displayed. Here is a few of the blocks the client can use on any page: Webshop with Print@Home vouchers To finish up this showcase, now for the most interesting part for all developers here, the webshop and all it’s interfaces to external services. From the very beginning, we knew, we needed to use something which will offload the cart and checkout parts of the shop completely because we don’t have the capacity to create a full webshop application for this project and there was nothing around we could build upon (this is only partly true, there is @Gadgetto's SnipWire which was a big inspiration). Obviously, nowadays there are alternatives around the corner like @bernhard’s RockCommerce which might just be the on-page solution for cart and checkout ProcessWire needs. Although the shop might seem small and unimpressive when looking at it from the user’s perspective, a lot has to happen in the background. Part of it is that we had to combine two types of products and part of it is the actual technologies we ended up using. The first product type is your standard product which gets shipped to the buyers. These products are easy compared to the second type - a streamlined experience starting in the shop where the user picks a value and a greeting for a print-at-home voucher, pays for it and together with the order confirmation is sent the voucher as a PDF ready to be printed. This lead us on an adventure where we came across asynchronous payment confirmation, custom payment processors for SnipCart and a small translation layer mapping one API to the other. In the end, we built a system of three modules for ProcessWire like this: The heart of the system is our «Snipart Integration» module. Think of it as a baby-SnipWire. It adds webhook handling, a custom payment provider API and JSON product info endpoints for SnipCart to work on the website. Building on the custom payment provider API, we have the «Wallee interface» which acts as a translation layer from the asynchronous API Wallee speaks to the synchronous one SnipCart uses. Further, we have the «Boncard interface» which adds webhook handlers to reach out to the print-at-home provider to generate and fetch the PDFs and finally sending them to the client, using our fourth and last external provider: SendGrid. Since SnipCart already uses SendGrid, this one was easy to decide. Also, there is a very good integration available with WireMailSendGrid. All of the modules have been built with reusability and modularity in mind: all of them have a configuration screen to add API secrets amongst other settings. They can be used as a package or in parts. This is useful if for example, you don’t need Wallee as a payment provider or do not have Boncard’s print-at-home vouchers in your webshop. Also, more custom payment providers are easily added using the main module’s API and webhook handlers. Conclusion There is still much to tell especially about the shop and custom payment providers’ implementations and challenges we faced. If you guys are interested, I can start working on a case study. Let me know! I will leave you with a few links for you to look at and/or get more information: https://huettenzauber.ch/ our main subject https://www.fruitcake.ch/projekte/huettenzauber/ our portfolio entry about the project COMING SOON link to page on ProcessWire Showcase Also, I don't want you to miss out on what's running behind the scenes: ProFields: Combo ProFields: Repeater Matrix Seo Maestro ProcessRedirects Tracy Debugger WireMailSendGrid All of this rocks on ProcessWire v227.

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.

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.

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 🙂

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

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.

The module can not be used, when the directory logs/tracy is not existing. An update of the module is also not triggering the creation of that folder. It would be nice, when the module can do it "by itself" when it is getting called in the admin. I'm working often for transfer between testing and live server with Duplicator where I exclude the (old) logs (also is the backup strategy). What is for all other logs not a problem, except the tracy log folder.

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.

I just noticed today, while trying to inspect headers (sent from our host server to see why a "download" attribute on a file link wasn't renaming a file), that there was a TracyDebugger message embedded within the session string (when logged in as an admin), but after enabling all available error logging in the module (and making sure I was using the latest version), I'm still not seeing any log of the error (I'm hopeful a textual log would provide more detail). I can see it's line 14, but since Tracy has better insight into my file structure, I wasn't sure which file... I don't get this error message on my development server. P.S. - Is it safe to delete tracy-2.x folders in the module folder, and if so, which ones?

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

I am using ProcessWire 3.0.242 on Debian bookworm, with PHP 8.3.14 and NGINX 1.22.1. I have TracyDebugger 4.26.45 enabled. Very recently, php-fpm reports a signal 11 when I have a PHP ParseError (or any other type of error). This causes NGINX to display a "502 Bad Gateway" page. If I disable Tracy Debugger, I see the Fatal Error screen in the browser. Does anyone know how to fix this problem? This was not happening a few weeks ago. Before, I would see the Tracy Debugger bluescreen displaying the error. I have tried the following but still have the problem: increasing the Tracy Debugger "Reserved memory size" disabling opcache increasing the php-fpm memory limit using previous versions of Tracy Debugger Any help would be appreciated. Thanks

When I switch a user and view the page tree, I get the following error. Any idea what is causing it? Not a big deal as it is only a warning, but it repeats hundreds of times. (PHP 8.1, Core 3.0.244 and Tracy 4.26.64). ErrorException: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/wire/core/DatabaseQuery.php:468 Stack trace: #0 [internal function]: Tracy\Bar->Tracy\{closure}(8192, 'trim(): Passing...', '/var/www/html/w...', 468) #1 /var/www/html/wire/core/DatabaseQuery.php(468): trim(NULL, ', ') #2 /var/www/html/wire/core/PageFinder.php(2294): ProcessWire\DatabaseQuery->__call('where', Array) #3 /var/www/html/wire/core/PageFinder.php(1956): ProcessWire\PageFinder->getQueryAllowedTemplates(Object(ProcessWire\DatabaseQuerySelect), Array) #4 /var/www/html/wire/core/Wire.php(419): ProcessWire\PageFinder->___getQuery(Object(ProcessWire\Selectors), Array) #5 /var/www/html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___getQuery', Array) #6 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\PageFinder), 'getQuery', Array) #7 /var/www/html/wire/core/PageFinder.php(803): ProcessWire\Wire->__call('getQuery', Array) #8 /var/www/html/wire/core/Wire.php(419): ProcessWire\PageFinder->___find(Object(ProcessWire\Selectors), Array) #9 /var/www/html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___find', Array) #10 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\PageFinder), 'find', Array) #11 /var/www/html/wire/core/PagesLoader.php(424): ProcessWire\Wire->__call('find', Array) #12 /var/www/html/wire/core/Pages.php(290): ProcessWire\PagesLoader->find('include=unpubli...', Array) #13 /var/www/html/wire/core/Wire.php(419): ProcessWire\Pages->___find('include=unpubli...', Array) #14 /var/www/html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___find', Array) #15 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Pages), 'find', Array) #16 /var/www/html/wire/core/PagesLoader.php(2032): ProcessWire\Wire->__call('find', Array) #17 /var/www/html/wire/core/Pages.php(245): ProcessWire\PagesLoader->count('include=unpubli...', Array) #18 /var/www/html/wire/modules/PagePermissions.module(1083): ProcessWire\Pages->count('include=unpubli...') #19 /var/www/html/wire/core/WireHooks.php(1094): ProcessWire\PagePermissions->moveable(Object(ProcessWire\HookEvent)) #20 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\DefaultPage), 'moveable', Array) #21 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/RequestInfoPanel.php(573): ProcessWire\Wire->__call('moveable', Array) #22 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(143): RequestInfoPanel->getPanel() #23 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(115): Tracy\Bar->renderPanels('-ajax:e7cdf9f77...') #24 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(78): Tracy\Bar->renderPartial('ajax', '-ajax:e7cdf9f77...') #25 /var/www/html/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Debugger/DevelopmentStrategy.php(123): Tracy\Bar->render(Object(Tracy\DeferredContent)) #26 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Debugger/Debugger.php(314): Tracy\DevelopmentStrategy->renderBar() #27 [internal function]: Tracy\Debugger::shutdownHandler() #28 {main}

Here is a quick report regarding one of the newest versions. I tested 4.26.42. In this version, the PHP console doesn't work anymore: The output window only shows "0:". Tested on two different hosting providers with three different PW installations. Downgrading to Tracy Debugger 4.26.26 fixes the problem.

I keep getting this error message on all backend and frontend pages in one of my projects: ErrorException: Undefined array key 1 in /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/TracyLogsPanel.php:71 Stack trace: #0 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/TracyLogsPanel.php(71): Tracy\Bar->Tracy\{closure}(2, '...', '...', 71) #1 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(142): TracyLogsPanel->getTab() #2 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(115): Tracy\Bar->renderPanels('') #3 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(89): Tracy\Bar->renderPartial('...') #4 /var/www/html/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Debugger/DevelopmentStrategy.php(123): Tracy\Bar->render(Object(Tracy\DeferredContent)) #5 /var/www/html/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} I am using the newest PW Version and the newest Tracy Debugger Version, can anybody give me a hint what is happening here?

Hi, Related to this thread I started recently, I wanted to follow up and check on the expected behavior for the Tracy Debugger Console. In my template files, there was a preg_replace operation on the $page->body property. The TD Console showed the result of this template operation after executing "echo $page->body". Is this the normal / expected behavior, as opposed to simply showing the field HTML content from the DB? The DB itself showed the unchanged HTML for the body field. Just wanted to check since it will help me understand how to troubleshoot better next time. Thanks!

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