adrian

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.

@Gideon So - I've fixed that error in the latest version of my fork of the module: https://github.com/adrianbj/processwire-fieldtype-assisted-url BTW, the reason is that prior to this version, you needed a Ckeditor field on the same template - now you don't.

Have you guys tried combining findRaw() with url hooks - https://processwire.com/blog/posts/pw-3.0.173/ ? I find it a really easy way to take care of this stuff.

Is this the issue? https://github.com/processwire/processwire-issues/issues/1511 - if so, it is fixed now.

The first one of those was basically due to index issues in my DB - running optimize on all tables fixed it, although I still found some significant improvements to speed that could be implemented. The second one is very weird - certainly seems like findMany seems some attention.

Not sure, but it seems like it might be further away: https://caniuse.com/jpegxl I feel like it's the mid 2000's again and I am waiting on browser support for SVG!

I had a similar experience with WebP - most often not significantly smaller, and often larger, so I kinda gave up and am waiting on AVIF to be supported widely enough to start using: https://caniuse.com/avif

That's because my repo is a fork of the original and not in the modules directory - you need to install from Github. Does that help? Actually, I see that is what you installed. Not sure why it's reporting 2.0.0 still. I guess the key thing is it now working without a separate CkEditor field? Also, can you see the updated file (with those changes I committed) in the folder under site/modules ?

Does a modules > refresh help?

IMPORTANT!!!!! Hi everyone. I've made a few changes in the latest version that are worth mentioning, with the first one being a possible (although unlikely) security fix. 1) A couple of the panels (User Switcher and PageRecorder) store info in the module's config settings JSON, but when using these, it would also save any of the settings set via $config->tracy. In general this is probably just annoying, but in the case of the $config->tracy['forceIsLocal'] setting (introduced in Nov, 2021), this override could also be saved to the module's main config settings. Hopefully if you have used this setting, you have only used it locally with things like Docker where the normal isLocal() method fails, but please check your sites if you have ever enabled this somewhere live. In particular I know that @teppo and @netcarver (and I think @Robin S) have been using this feature, but pretty sure still only on local machines. 2) Even though that forceIsLocal setting is potentially dangerous, I decided to add it to the config settings (with a warning) as well so it's more transparent. Note that the debug bar displays a yellow warning icon on the left side if this setting is enabled. 3) I also added a table that lists out any $config->tracy overrides in an effort to make it more obvious what overrides in place. 4) I've revamped the Log panels further with better logic to control when the yellow / red colors are applied to the icon. I have improved the sort logic within each specific log file and I have added the yellow / red highlighting to the lines that are new since you last loaded them. I have also increased the default number of lines from 10 to 100 - this makes these panels much more useful and because of other recent changes it is now performant enough to do this. Note that upgrading from an old version of Tracy won't increase this, so you might want to do that yourselves in the settings. Thanks everything and sorry for the override settings getting save to the default one issue!

Well, they already have this option: Debugger::$strictMode = true; // display all errors Debugger::$strictMode = E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED; // all errors except deprecated notices but that only controls what happens in strict mode. I don't know if you want to have something similar for non-strict mode and ignore deprecations completely, or if you do really want to have the error panel tab change color, or separate panels. I think I would suggest the color change because I think it's pretty important to continue to get regular warnings about deprecations, because before you know, you've upgraded PHP and now that function is no longer available and you have real errors, but having an extra panel is just unneeded space.

I'm honestly not sure how I feel about this, but that's another story :) The feature that you're asking for probably belongs in the Tracy core, so it might be best to request it over here: https://github.com/nette/tracy/issues That said, I have hacked together something (fairly quickly, but definitely not 5 minutes). Try the attached - currently only works for direct loading of frontend pages - ie it doesn't work in the admin or via AJAX. The errors panel gets recolored if the only errors in it are deprecations. Sorry, I don't have anymore time to spend on this at the moment, especially given that I think it belongs in the Tracy core. TracyDebugger.module.php

@2hoch11 - please try the latest commit - it should work now even if there is no CkEditor field on the template.

I just tested and it's working fine here. Can you take a look at the browser dev console to see if there are any JS errors?

@2hoch11 - is this what you're looking for? https://github.com/adrianbj/processwire-fieldtype-assisted-url

Hi @d'Hinnisdaël - I wonder if you'd be willing to support loading a tab directly from the hash in the URL please? Thanks for considering.