adrian

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!

@rick - did you try Robin's version: https://processwire.com/talk/topic/19913-solved-page-reference-field-unpublished-pages-not-visible-by-non-superuser-rolesusers/?do=findComment&comment=172578 That's what I've been using for a long time now.

@StanLindsey - I've just started experimenting with Digital Ocean's managed DB clusters, having one standby node and one readonly node. Everything works, but the site is quite a bit slower when I use these vs a normal MySQL DB on the droplet where the PW install is hosted. I did go for the lowest end DB cluster they offer, so: 2 GB RAM / 1vCPU Compare this to the main droplet which is: 8 GB Memory / 4 Intel vCPUs (with an innodb_buffer_pool_size = 4G setting) So obviously the managed DB has potentially fewer resources, but I am wondering if it's the DB's lack of resources or if it might be something else - perhaps just the requirement of connecting to another server. I see I am not the only one who has experience this issue: https://laracasts.com/discuss/channels/servers/same-query-in-digital-ocean-managed-mysql-db-more-than-doubly-slow-than-on-droplet but I would love to know your experience and if you might have any tips to share. Thanks!

PW doesn't output anything on the frontend by default, so it's just your code. Perhaps you need to make sure the JS animate function isn't triggered until the DOM is ready.

Did you see my screenshot above - you need to whitelist the svg extension in your image field settings.