Search the Community

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

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.

I have just released version 2 of RockMigrations: GitHub: https://github.com/baumrock/RockMigrations Modules Directory: https://processwire.com/modules/rock-migrations/ Please star the module on GitHub if you like it ? Are you unsure if RockMigrations is the right tool for you? @Jonathan Lahijani in a very nice PM ? Read the full post here Read the full post here Read the full post here QuickStart The example code uses bd() calls for dumping data. You need TracyDebugger installed! Put this in your site/migrate.php /** @var RockMigrations $rm */ $rm = $modules->get("RockMigrations"); bd('Create field + template via RM'); $rm->createField('demo', 'text', [ 'label' => 'My demo field', 'tags' => 'RMDemo', ]); $rm->createTemplate('demo', [ 'fields' => [ 'title', 'demo', ], 'tags' => 'RMDemo', ]); Reload your site and you will see the new field and template in the backend and you'll see the message in the tracy debug bar.

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 🙂

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.

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

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.

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?

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.

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

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

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!

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

I need help please, I'm having a difficult time debugging with Rockfrontend, there seems to be some sort of error and it isn't parsing the "content div" So it outputs the default home page content div instead. Since there is no visible error to work with, It makes the bug difficult to find. Also, although I've got Tracy Debugger installed, it isn't visible. I can't seem to see what I'm missing. I'd apprecaite any input and advise please. Thank you so much.

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

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

Thanks @adrian! Just an FYI... My server has php tokenizer installed and accessible. Debian 12, php 8.3, mysql 15.1, and apache 2.4 installed Nov '24. I completely uninstalled Tracy, deleted all Tracy related files from the server, and removed all references to Tracy in the DB. I installed Tracy from Modules > New. The Tracy Bar is not displayed at the bottom right of the screen. I went back into Tracy settings and selected the Force superusers into DEVELOPMENT mode. <-- I read somewhere on here about that setting. I submitted that change. The Tracy bar now shows at the bottom right but still displays the previous two errors. I unchecked the Force superuser checkbox and submitted that change. The Tracy bar disappears.

Hey @adrian Today @netcarver requested to make RockFrontend's livereload work on tracy error pages - which is something that has been annoying for myself for a long time: https://github.com/baumrock/RockFrontend/issues/25 The problem is I've really tried hard to do so, but I can't find a way to modify the markup of the rendered page ? LiveReload in RockFrontend works simply by having this markup on the page: <script> var LiveReloadUrl = '{$this->wire->config->urls->root}'; var LiveReloadSecret = '$secret'; console.log('Loading LiveReload'); </script> <script src='$src'></script> Any ideas how we can get this working? I even tried using Debugger::$customBodyStr = "TEST"; and similar, but that doesn't seem to do anything at all, though I see you are using it in your module? I'm totally lost here and hope you have a simple solution to finally get rid of these annoying manual reloads on error pages ? Thx in advance! PS: This is actually the same request as this one just with different wording: https://processwire.com/talk/topic/29555-why-is-it-so-complicated-to-add-custom-panels/ I mentioned in that post that I got it working, but I can't find the working version any more of I just thought it was working but it actually didn't... PPS: I'm talking about these pages:

@diogo - I mentioned this elsewhere, but that fixed header is proving problematic with Tracy because the effective z-index of the main nav is different to the dropdowns. The way things used to work I could set Tracy's panels to 100 and they would appear over the main nav, but the dropdowns would appear over the Tracy panels (which is the behavior we want). Do you know how that can be done with the new fixed nav? It seems I have to drop Tracy panels to less than 50 (maybe something higher but that works) for the dropdowns to appear over the Tracy panels, but I need 200 (maybe less, but 100 isn't enough) for the panels to be above the top nav. If they go below it's hard to grab their title and move them.

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

I've noticed this a couple of times. I load a page and it crashes, Tracy gives me a big red page with helpful info on it. I then fix the problem, and reload the page - but the error won't go away. For example the screenshot below shows and error saying "Call to undefined function ProcessWore\pappub_inlay_request()", and then highlights a line in my code that (now because it's been fixed) doesn't show the code from the error message! One part of the page is lying to me, and it doesn't go away until some timeout. I'm guessing a cache timeout? But I've tried adding a ?something=123 var and that didn't fix anything either: still received the old error that no longer correlates to the actual code; Tracy seems to be intercepting my actual code to show me the old error! Anyone else had this?

Hey @adrian tracy debugger creates links like this: vscode://file/%2FUsers%2Fbernhard%2Fbaumrock%2Fbaumrock.com%2Fsite%2Fready.php:8 With the latest vscode these links don't work any more. Turns out that the issue is the file// instead of file/ I've changed that in RockFrontend and RockMigrations and all fine again. See https://github.com/microsoft/vscode/issues/197319 Not sure why I get those %2F instead of / ? Would be great if you could push a fix for this. I tried to find it myself but seems I didn't find the right spot. Thx in advance! PS: Just did an update to the latest version and got this error: Error: Undefined constant Tracy\Debugger::Version in /var/www/html/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/assets/bar.phtml:15 Stack trace: #0 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(119): require() #1 /var/www/html/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Helpers.php(364): Tracy\Bar->Tracy\{closure}() #2 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(120): Tracy\Helpers::capture(Object(Closure)) #3 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(89): Tracy\Bar->renderPartial('main') #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(309): Tracy\DevelopmentStrategy->renderBar() #6 [internal function]: Tracy\Debugger::shutdownHandler() #7 {main} (stored in /var/www/html/site/assets/logs/tracy/exception--2023-11-05--11-52--6565da4fb6.html) PPS: Weird - now everything seems to work with the old links as well! Don't know what's going on, but I think changing to the official vscode://file/... format would be a good idea nonetheless ?