adrian

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.

Give the latest version a go. There was one other place that needed the isLocal check removed.

@bernhard - I'm with @teppo - it works for me - that bd() call you added correctly returns the path set via: $config->tracy = [ 'localRootPath' => '/path/to' ]; so I think there is something else that must be awry at your end. As he asked, are other settings defined that way working as expected?

In that case, can't you simply append to (or replace) $config->tracy in this local config file? If that works for you, I think all I need to do is to remove the isLocal() check that currently prevents this working unless on a live server. Does that sound correct?

Sorry, I must admit I read in a rush this morning and assumed your example was an option, but just noticed you're saying that it's not an option. I have always worked solo (although that is about to change), so I will defer to you both to let me know how you'd like this set up - I am happy to implement whatever you suggest on this.

Maybe we need a way for all of Tracy's setting (via the $config->tracy option) to be user specific? Would it makes sense to have something like: $config->tracy = [ 41 => [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, 'localRootPath' => '/xxxx/path/to/' ], 1276 => [ 'outputMode' => 'development', 'localRootPath' => '/yyyy/path/to/' ] ]; where the top level keys are the user IDs? Although of course that doesn't work if you're not logged in. How do you suggest we handle that? I separate config file outside the root of the site so it's not part of the version control of the repo?

HI @bernhard and @teppo - The local root path was designed as a way to override the path to the remote server so that you could open the file locally even though you clicked from a remote server. I am certainly happy to add user specific paths for these if it helps. Let me know what you think the best approach would be. Can we go with: userid: path pairs on separates lines in a textarea? What about covering @teppo's point about when you're not logged in?

It's not nonsense, but SVGs don't need to have width / height attributes. It's perfectly acceptable for these to be missing, but it can result in some display issues depending on how they are output. I don't think PW should automatically add these (at least without it being optional), but on some sites I do this via a hook because I do want to ensure those attributes are set. If they're not set, I get them from the viewbox and add them - similarly to the way @snck is showing above.

Hi @snck - nice work. I really do think this should be incorporated into the core, although I am a bit confused by the calculation method you have for getting the width / height. I feel like the width and height should be take directly from [2] and [3]. Even if the min_x or min_y aren't set to 0, surely that doesn't change the width of the canvas area that the illustration is on which is what we want the width / height of. Do you agree, or am I missing something? We need to get Ryan's attention on this - maybe a Github issue?

Interesting that it didn't work straight away. If you find similar issues again, please let me know - maybe I've overlooked something?

Ok, please give the latest version a go. It should be much better in that you now get notification of new entries no matter when they happen relative to when you reload the page - they might even happen in another process. Thanks for prompting me to revisit this.

It's a bit hacky - it looks for an entry within the last 5 seconds and color orange if there is one. I figured this was probably OK for manual reloads. It turns the icon red if the last entry (within those 5 seconds) is an error. I'll take a look at improving this - should be quite easy now that I am caching the results in a wirCache because I'll be able to tell if there is a new entry or not. This wasn't really possible until I introduced the caching.