adrian

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

Ok, so I assume you have clicked the "Refresh" button at the top right of the upgrades module?

You may need to log out and back in again. Not certain if that is still the current behavior but for quite some time it didn't pick up new PW versions without doing that. Also, what version of the upgrades module are you using? The new one requires a manual refresh, but I am sure you've seen that.

PS - that said, I don't see any issues here on Safari, but I am using the latest PW dev version so maybe something has been fixed in the last 6 months, so I would try an upgrade first.

You can use SVGs without that module - I don't recall exactly, but if you uninstall it, you'll get a warning that tells you the alternative option. There a few discussions online about Safari having issues with fetch (and sometimes XMLHttpRequest) with https. CORS might be coming into play, but it's hard to tell for sure. Google: safari "failed to resource: cannot parse response" AND safari fetch https (even though I don't think this is actually fetch, there are still some posts that seem relevant). In reality I steer all clients away from Safari because I still find lots of random issues with it here and there.

Take a look at this: https://github.com/processwire/processwire-issues/issues/674 I think it should help you fix the problem.

Ah - sorry, I missed the point about it being Safari specific - are you seeing JS errors in the dev console?

@Claus - do the same SVGs consistently fail and others consistently work, or is it random with a file working sometimes and not others? If the former, can you post one that fails so we can test it?

Thanks @flydev ?? - I've been using 1.4.16 for quite some time (with some sqldump command changes) and it's been working great. I just updated to 1.4.17 and all looks great running on pHP 8.0.

Depending on how many locations you have findRaw() might be a useful alternative to find()

Hi @Ivan Gretsky - thanks for your monthly donation to Tracy - it's always appreciated.