adrian

I know it's not really any help, but testing here on my local dev setup on PHP 8.0 and PW v3.0.193 (and I just upgraded to v3.0.197 and tested again) with this DefaultPage.php class file: <?php namespace ProcessWire; class DefaultPage extends Page { public function returnParentId() { return $this->parent()->id; // or return $this->parent->id; } } And when I call it, I get the ID of the parent page:

@Flashmaster82 - I think at this point, you just have to wait for Google to reindex your pages. Have you submitted a sitemap.xml to help with this? In the future, if you are protecting the entire site, you might want to use the ProtectedMode module and use the maintenance mode option so Google knows it's temporary and won't update its index.

Hi everyone, Just announcing a couple of new features that have actually been live for a week or so. 1) Guest dumps This allows any calls to bd() be() etc by guest users (regular visitors, webhook calls etc) to be logged and displayed in the Dumps Recorder panel. This panel will open automatically (on page reload) on another browser tab (where you are logged in). To turn this feature on, click the "Enable Guest Dumps" toggle button on the Panel Selector. The cog icon for this panel will change to orange to let you know it's on. There is no security risk having it enabled, but if you have a well trafficked site and it is left on, the file that stores the recorded dumps could become very large so you won't want to leave this on. This is my favorite new feature in a very long time so be sure to try it out. 2) Automatic includes Any files you place in /templates/TracyDebugger/includes/ will be automatically included. You could have a file with some helper functions or the file could have an include statement to pull in a site-wide functions file. This will give you access to any functions in these files via the Console panel.

Hi @tcnet - firstly, I am sorry if I came across as criticizing the module - it was genuine question - I thought perhaps there was some other advantage I wasn't aware of. For example, sometimes I want to be able to access the "Database Queries", "Timers", and "Autoload" sections that are only available in Tracy when debug mode is on. I was wondering if perhaps this module allowed for that. Regarding the changes in 3.0.163 - I thought the ability to install modules being restricted to debug mode and the new $config->moduleInstall() options were both introduced in that version, but maybe I am wrong. I don't see any reason to remove the module - I was just hoping for some clarification so we all know its benefits. Thanks for the contribution!

I thought the same thing but assumed I must be missing something. @tcnet - can you please explain the advantage of this over the various moduleInstall options?

Weird - I have no idea why that would be happening - maybe it can't be overwritten in Valet for some reason? There might be a better way for me to check if the request is a response from PW page or not, but I am hesitant to change the current logic without understanding things a bit better. Any Valet experts out there who have an idea on what the best way forward is?

What does that original: bd($_SERVER['PHP_SELF'] . ' : ' . $this->wire('config')->urls->root . 'index.php'); return now?

@jploch - thanks for those. I am honestly not sure the best approach to fix this. The problem in question is this: // check if request is to a PW page - otherwise it's maybe an AJAX request to an external script $isPwPage = $_SERVER['PHP_SELF'] == $this->wire('config')->urls->root . 'index.php' ? true : false; But, I can't seem to trigger a situation at the moment where this returns false (even making an ajax request to an external script). I don't think I want to replace PHP_SELF with SCRIPT_NAME because I think that would return an incorrect result if the external script was an index.php file. Possibly you could add: $_SERVER['PHP_SELF'] = '/index.php'; to the frontControllerPath() method. I expect that will fix things, but not sure if there might be some side effects, but it might be the best solution. Let me know it that works for you.

Interesting - Valet seems to mess with PHP_SELF. Could you please find out what bd($_SERVER['SCRIPT_NAME']); returns. It looks like there might be another option around setting: 'usePathInfo' => true in general.php (https://github.com/laravel/valet/issues/340) - is that something you are familiar with? I think general.php is a file in the Valet system, but not really sure.

Hi @jploch - it looks like the issue is a problem with what $_SERVER['PHP_SELF'] is returning. Could you please add the following code to line #53 of the RequestInfoPanel.php file and let me know what is returned? bd($_SERVER['PHP_SELF'] . ' : ' . $this->wire('config')->urls->root . 'index.php');

@jploch - it should be fixed in the latest version.

I've added that fix to the latest version - hopefully it works for your issue as well.

Hi @jploch - I actually have a feeling this isn't Valet related. It looks like a bug in the RequestInfo panel. Any chance you have turned off some of the sections within it, likely the Template Settings section? It's an easy fix, but just wanted to confirm that you do have this disabled. It's probably that one second from the top that is causing the problem. You might have upgraded from a really old version of Tracy when that section didn't exist.

@Macrura and @Ivan Gretsky - I haven't seen the exact issue you are seeing, but I did have a site that pulls in data from another PW instance that wasn't showing the debug bar. I fixed it by adding: if(class_exists('\Tracy\Debugger') && Debugger::isEnabled()) return; as the first line in the module's init() method. I'd love if you could test that please and see if it helps your issues. Thanks, Adrian

A couple of potential things - I think getByIDs would be more performant. And also, if you have JSON in the meta, then using JSON_VALUE might be helpful.

@Macrura - If this is something you can reproduce easily, would you mind seeing if adding: if(!Debugger::isEnabled()) at the start of this line (https://github.com/adrianbj/TracyDebugger/blob/24dcacfc864447a41676b0f12eeb901512c0d2eb/TracyDebugger.module.php#L1393) helps? If that doesn't work, then perhaps adding: if(Debugger::isEnabled()) return; at the top of the init() and ready() methods might work? Thanks a lot for testing these. See revised version below!

Just a get param and an onchange triggered reload - it's only to filter to a specific organization so no need for anything fancier for now.

Perfect - thank you. Just in case anyone is interested, the panel above the tabs is a dropdown select for filtering the results of the data shown in all the other tabs / panels, so this works really nicely now.

Hi @d'Hinnisdaël - I am really loving the new tab option, but I am looking for a way to add a panel above the tabs so that it is available no matter which tab the user is on. If I add the panel directly to $panels, it always appears at the bottom of the page below the tabs. Any ideas how I can make this work? Thanks so much!

Have you looked at: https://processwire.com/talk/topic/26070-error-exception-unable-to-obtain-lock-for-session/ ? I didn't actually know about this Tracy issue. I think perhaps it's a combo between it and the SessionHandlerDB module. Tracy does now use a different approach to sessions (by default), but I'd still try disabling the SessionHandlerDB module.

Hi @Robin S - just stumbled upon this randomly - are you still using the modified version of the module with the hook? Do you need any further refinements? Do you want to submit a PR to get those changes incorporated?

This looks awesome - thanks @bernhard and @ryan

@flydev ?? - obviously not at all important, but - note the incorrect tooltip text.

So, some good news - I upped the DB clusters to 4 GB RAM / 2vCPU machines and now the performance is on par with the local DB. The downside is that this is quite expensive but I am thinking it will be worth it for the: Daily point-in-time backups. Full cluster backups are taken daily and write-ahead-logs are maintained to allow you to restore to any point-in-time within the previous seven days. High availability with automated failover. In the event of a failure, managed databases with a standby node will automatically switch data handling to the standby node to prevent unplanned downtime. Obviously not needed for most sites, but I think when you have frontend users regularly modifying info in the database, having the ability to restore to any point-in-time is quite reassuring.

Thanks @elabx and @Craig - I hadn't seen that particular post, but I had seen others complaining of performance issues. I have been in contact with DO via a support ticket and so far they haven't been very helpful - first response basically said that it's expected because their managed DBs run on low spec'ed servers. The next response wanted me to provide examples of queries that were slow. The reality is that all queries are significantly slower and they are even worse when connecting to one of their readonly nodes. At the moment I am considering ScaleGrid, or maybe manually setting up replication something like this: https://www.digitalocean.com/community/tutorials/how-to-set-up-replication-in-mysql - although that doesn't provide all the features of the managed DB setup. I'd love to hear from anyone else who has a good solution for having instant DB replication, fallover/standby nodes and readonly nodes that are at least as fast as a local DB - thanks!