Search the Community

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}

I've created a process module that saves pages under the Home > Admin > MyPages level in the admin. The module has a list of those pages created with links to allow further editing via PW's normal Page Edit. Upon clicking it, the form opens for editing. To stay away from the Admin territory (hidden by default), I'd like to redirect back to the module's home after saving my edits but am not successful so far. I've been trying a bunch of ways I see here in the forum & the docs. Among some that do not appear to trigger (from my ProcessMyApp.module.php) are: 1) Derived from my understanding of API doc init() { parent::init(); //$this->wire()->processPageEdit->setRedirectPath('/myapp/'); $this->wire()->processPageEdit->setRedirectUrl($this->config->urls->admin . '/myapp/'); } 2) Derived from Ryan's /site/modules/RedirectPageEdit.module here init() { parent::init(); $this->wire()->session->addHookBefore('redirect', $this, 'redirectAfterSave'); } 3) Also derived from my understanding of API doc init() { parent::init(); $this->wire()->addHookAfter('ProcessPageEdit::processSaveRedirect' , $this, 'redirectAfterSave'); } The redirectAfterSave: public function redirectAfterSave(HookEvent $event) { $process = $event->object; $page = $process->getPage(); bd($event,'Tracy no see'); if($page->template->name === self::module_template) { $event->arguments = array($this->config->urls->admin . 'myapp/'); } } What could I be overlooking? Tried in Processwire 3.0.243 & 3.0.244

Hey @Robin S - thanks for the new theme - I've committed it already. As for the unsaved changes issue, I can't seem to replicate that here when I add something in the code prefix setting. I don't normally use that option but been playing around and not seeing an issue at the moment and as far as I can tell the code prefix should be removed before loading into localstorage where the comparison is done. Perhaps there are some weird characters or a windows line break or something which isn't being stripped? This is the file that is called via AJAX to get all snippets: https://github.com/adrianbj/TracyDebugger/blob/master/includes/ConsoleSnippets.php if you feel like doing some comparisons, or if you'd like to post the contents of your code prefix field I can also take a look here. A bit off topic, but just out of interest for you - not sure if you've ever looked, but the code that is actually run via Tracy is stored here: /site/assets/cache/TracyDebugger/consoleCode.php

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

Hello @adrian, Thank you for your immediate reply! The added /*NoCompile*/ didn't change anything here unfortunately - so I'm not sure if you would keep it anyway...? But I found the problem – not the first time I've overlooked this – the cache table in the db. I deleted the corresponding fileCompiler rows and the messages are gone. Same goes for the tracy panel hints. I'm glad it was just such a simple issue. Maybe it's because I installed “WireCache: Filesystem” a few months ago and that leads to outdated database cache data? (BTW The owner/role/authorization issue you mention is something I always feel stumped by in shared hosting contexts – and suspect I'm not operating at the optimum in terms of security. That would be a topic for a ProcessWire MeetUp :o).

Could you share the exact code? As far as I understand your screenshots ProcessWire tries to call ->getShowByArtist() but doesn't find it and therefore tries to run Hooks, which is what it does to execute any methods that are attached via hooks and not really added to the class itself. The question is still why it doesn't find the getShowByArtist method when it should be there. In your case I'd search my codebase for "getShowByArtist" and make sure that it only exists at one single location. Then, I'd remove that call and replace it with a bd() call, for example bd($item). Tracy should then dump a "HomePage" object to the debug bar. If it dumps a different object, then it makes sense that it throws an exception that the getShowByArtist method does not exist.

@sz-ligatur - please try changing this line: https://github.com/adrianbj/TableCsvImportExport/blob/b1cf4b9d9c396f7f50e8a33a7b8ba871614a6f50/TableCsvImportExport.module.php#L455 to: require_once __DIR__ . '/parsecsv-for-php/parsecsv.lib.php'/*NoCompile*/; I think that should sort out the issue with this module. Let me know if it works and I'll add to the repo. As for the Tracy panel notices. Not sure about those but it does seem like in general you have some permission/role issues preventing PHP from writing to files in the modules directory.

Just an update that AdminerEvo is officially dead unfortunately so I have migrated Tracy to use https://github.com/pematon/adminer - Peter Knut is the creator of the theme that Tracy's Adminer uses and has created a few other plugins we use so I think we are in good hands, so if you want to show some love, please go star his repo to help get it better recognition and support from other contributors.

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.

thank you so much @bernhard for showing the method for building a module. I really appreciated this answer. I ended up modifying the code to for a simplified extension of a Custom Page Class, in case anyone else want's to see how that works. in DefaultPage.php <?php namespace ProcessWire; class DefaultPage extends Page { public function getShowByArtist() { return $this->wire()->pages->get("template!=news-item, artist.name='{$this->name}'"); } } and in the template like so: <a href="{$item->getShowByArtist()->url}"> {$item->title} </a> By the way @bernhard, maybe you could elaborate something I encountered that I can't quite piece together. This function `getShowByArtist()` is getting called on the home template, and on the front-end appears on the homepage, but when I tried adding the above function declaration to HomePage.php custom page class, I would get exceptions that the function is unavailable/not call-able. I am using the Rockfrontend method such that in site/templates/layouts/home.php <?= $rockfrontend->renderIf("sections/home.latte", "template=home") ?> And in home.latte is where I am calling the function inside of the a href (as above). However, it only seems to work when I put the getShowByArtist() function declaration inside of the DefaultPage.php custom page class … even though in Tracy Debugger it shows my template as home and the class as \ProcessWire\HomePage on the page in which this function gets invoked (correctly). Why could that be ? Any ideas ? Again, your help has been much appreciated. I might leave the function inside DefaultPage.php for now.

First thing to check is if your $pages->get() call works at all. For example in the tracy console. You are using $pages->get() which will return a single Page object (or NullPage), so your ->first is wrong, i guess. Next, I think you can't use { } brackets inside { } brackets when you are outputting a string. This will NOT work: {var $item = $pages->get(2)} <a href="{$pages->get("name={$item->name}")->url}"> {$item->title} </a> This will work: {var $item = $pages->get(2)} {var $url = $pages->get("name={$item->name}")->url} <a href="{$url}"> {$item->title} </a> And this is what I'd recommend you to do: Create a Site.module.php in /site/modules/Site <?php namespace ProcessWire; // expose the site module as global site() function function site(): Site { return wire()->modules->get('Site'); } // module code class Site extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'Site', 'version' => '0.0.1', 'summary' => 'Site Module', 'autoload' => true, 'singular' => true, 'icon' => 'bolt', 'requires' => [ 'RockMigrations>=3.34', ], ]; } } Then add the following method: public function getShowByArtist(Page $item) { return wire()->pages->get('template=concert-visuals|broadcast|music-videos, artist.name={$item->name}'); } Which cleans up your template a lot and will help you to write better (DRY) code, as you have one place to store the logic. If you need the same link url in another place of your website you simple call the same method and not copy paste the selector. If the selector changes over time (for example adding another template to the selector) all your links will still work by only updating one place in your code (and not many). <a href="{site()->getShowByArtist($item)->url}"> {$item->title} </a> Or even better use Custom Page Classes and add the getShowByArtist method directly to your $page object.

Well, it took a long time, but the Console tabs are now available in the latest version - turns out there were actually a lot of things left to do which took way longer than I expected. If anyone finds any issues, please let me know. Please note that you will have to do a hard reload to get the tab CSS working - the way the core Tracy package loads CSS I can't seem to figure out how to bust the caching of it.

Hi @adrian, I updated an older site running PHP 7.1 to the latest Tracy Debugger and got this error: Maybe that line needs a check of which Tracy version is in use?

The hooks info that Tracy shows is basically a copy of what is shown in PW's Debug Mode Tools (using getHooks()) and AFAIK it's only hooks that are triggered by AddHookAfter/Before calls. From what I can tell what Bernhard is showing is all hooks that are run as PW is booting up - there are lots of entries missing in that list. Not saying that it's not a useful list, but they are very different things. Unfortunately it seems that Tracy isn't available at the point that runHooks() is called, so I couldn't replace your log file approach with a bd() call so at the moment it will need Ryan's input to make it possible to display this list in Tracy.

Hey @Jan Romero that's true, but it shows it in a totally different way. I wanted to have a list of all methods that I can hook into, in the order of execution! I don't know how tracy sorts the list of added hooks, but it's definitely not execution order. On the other hand tracy debugger adds nice links to the hooks and shows some more information, like for RockFrontend: after RockFrontend::addAlfredStyles() AdminStyleRock::addAlfredStyles() class method 100.0 And that line does not show up in my hooks log: cat hooks.txt | grep RockFrontend ProcessWire\RockFrontend::addLiveReload ProcessWire\RockFrontend::render ProcessWire\RockFrontend::loadLatte ProcessWire\RockFrontend::addLiveReload RockFrontend\StylesArray::renderAssets RockFrontend\ScriptsArray::renderAssets Oh... that actually makes sense, because I have not had an ALFRED call on that page yet, so obviously the hookable method does not get called! 😄 I added it and boom, there it is: cat hooks.txt | grep RockFrontend ProcessWire\RockFrontend::addLiveReload ProcessWire\RockFrontend::render ProcessWire\RockFrontend::loadLatte ProcessWire\RockFrontend::getIcons ProcessWire\RockFrontend::addLiveReload ProcessWire\RockFrontend::addAlfredStyles RockFrontend\StylesArray::renderAssets RockFrontend\StylesArray::renderAssets RockFrontend\ScriptsArray::renderAssets RockFrontend\ScriptsArray::renderAssets Another one. I saved a page from the backend and the grep for "::save" looks like this: cat hooks.txt | grep ::save ProcessWire\Pages::save ProcessWire\Pages::saveReady ProcessWire\Pages::savePageOrFieldReady ProcessWire\Pages::saved ProcessWire\Pages::savedPageOrField I think this is really neat! Maybe @adrian has an idea how we could integrate this into Tracydebugger and maybe get the best of both worlds (tracy current implementation + my hacky one)? I think it would need a modification in the core, but that should not be a big deal for @ryan.

Neat. FWIW Tracy also shows hooks that were triggered during the request (in the debug panel). If you, like me, usually define your hook methods as closures, it’ll just say “{closure}”, but it does link to the source, so that’s nice! On the other hand it seems to show all hooks that were defined and doesn’t say whether they actually ran.

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

Also, had some issues with the Processwire multi-instance sites using the latest versions and ProcessWire 3.0.123 'Compile Error: Cannot declare class FieldtypeRepeater, because the name is already in use (line 30 of...'. The error message was on the sub-domain that also had more complexity with fields and modules. Our code was bootstrapped on the sub-domain and included Processwire namespace too. As new install of the latest version worked, but actual sites with additional fields and modules did not? Further investigation and debugging highlighted that on a new install the 'Repeater' module is not installed and therefor does not cause an error? However, on the working sites renaming the folder 'FieldtypeRepeater' located in the 'wire' folder (/wire/modules/Fieldtype/FieldtypeRepeater) caused Tracy Debugger to error instead. Removing this module in addition to renaming folder ' 'FieldtypeRepeater' allowed everything to work as expected. You have to login before renaming the core module 'FieldtypeRepeater' and ignore the admin messages whilst you access the multi-instance data and create pages on the sub-domain. Not a very elegant work around, but if you only need to read and write the data temporarily at least it is possible now. Hopefully, this may help someone else work out how to fix it properly?

Also, had some issues with the Processwire multi-instance sites using the latest versions and ProcessWire 3.0.123 'Compile Error: Cannot declare class FieldtypeRepeater, because the name is already in use (line 30 of...'. The error message was on the sub-domain that also had more complexity with fields and modules. Our code was bootstrapped on the sub-domain and included Processwire namespace too. As new install of the latest version worked, but actual sites with additional fields and modules did not? Further investigation and debugging highlighted that on a new install the 'Repeater' module is not installed and therefor does not cause an error? However, on the working sites renaming the folder 'FieldtypeRepeater' located in the 'wire' folder (/wire/modules/Fieldtype/FieldtypeRepeater) caused Tracy Debugger to error instead. Removing this module in addition to renaming folder ' 'FieldtypeRepeater' allowed everything to work as expected. You have to login before renaming the core module 'FieldtypeRepeater' and ignore the admin messages whilst you access the multi-instance data and create pages on the sub-domain. Not a very elegant work around, but if you only need to read and write the data temporarily at least it is possible now. Hopefully, this may help someone else work out how to fix it properly?

You can maybe start by looking into where the problem occurs. You can for example use Tracy's bd() function to output the page name before and after every saveReady and saved hook. This will at least let you see in which part of the code you have to go dig for more. Do you have any hooks already in use for Page::saveReady and Page::saved? On which PW version are you?

Thank you very much for the fix. I can confirm that Tracy s now working without the modification. I think, for larger corporate sites redirects that route from root to a specific language/market URI are not that unusual. So it is great that you made things work for those use cases.

We were experiencing a similar issues because the POST request now goes to / root instead of the current page loaded like before with ./ In our case the console result frame would load the homepage of the frontend instead of the actual results. I solved it for our case (a hook to PageView::execute on /) by returning if it is a tracy request $wire->addHookBefore("ProcessPageView::execute", function (HookEvent $event) { // do not redirect if tracy request if(isset($_POST['tracyConsole']) && $_POST['tracyConsole'] == 1) return; // alternative // if (isset($_SERVER['HTTP_X_TRACY_AJAX']) && $_SERVER['HTTP_X_TRACY_AJAX']) return; if ($_SERVER['REQUEST_URI'] === '/') { ... session()->redirect("{$lang}{$marketName}"); } We need that redirect to determine language and market based on a request to GeoApify API. I think that others might potentially run into this as well. So if the change of xmlhttp.open("POST", "./", true); to root / is not strictly necessary for Tracy to work, it might be better to revert that? @adrian

Interesting - does the console panel work when you using it from the PW admin, rather than the frontend of the site? If you can't figure out the issue, perhaps a trial and error approach of going through the Tracy versions to see where the issue starts occurring might be the quickest in the end. Choose a version in the middle between the current, ie 4.26.34 and if that works, split the difference between it and .42 but if it doesn't, go for .30 - you get the idea and hopefully it won't take long to figure out which one breaks things.

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.

Very interesting. The folder only contained only old logs: Logging the bd($entry) revealed an error from 2023 that was actually no longer part of the reay.php anymore. I manually deleted all tracy logs files inside the site/assets/logs/tracy folder and also deleted the cache folder under /assets. After that this error disappeared.