adrian

Pagination buttons issue - note the missing left border on #2

I think the recent updates are really making a big improvement. One thing I like is the return of the page list action buttons, but I am confused why they use the defined "main-color", but the rest of the buttons in the admin use "text-color" but change to "main-color" on hover. Can the page list action buttons match the same behavior as the other buttons please? PS - this alignment bug is still there: Add New button dropdown still needs internal scroll feature please.

Hey @bernhard - I am not sure if this works for all your needs, but you should be able to add to the array of path replacements whenever/wherever you want. For example: \Tracy\Debugger::$editorMapping['/assets/cache/Latte/latte-includes-foo.php'] = '/templates/latte/includes/foo.latte'; I feel like you could probably build out all the replacements you need by looping over the files in /assets/cache/Latte/ and replacing the path and filename as needed with some pretty simple logic. I feel like this should allow you to handle both scenarios in your recent PRs without changes to Tracy. Sound OK, or am I missing something?

@bernhard - thanks for the explanation of the Tracy being in the body issue - makes sense. As for the localStorage issue, maybe htmx is filling up localStorage then? Can you investigate what's in there to see why it's full?

Maybe not useful for everyone, but I find I am often searching for content via Adminer and when the results are from a repeater item page, I need to figure out which is its "forPage". I have just added a new forPage row to the PageInfo section of the RequestInfo panel that lets you view or edit directly from here making things much easier.

Just a heads up for everyone to be careful with this upgrade. I had a poor piece of code that worked before but broke with these markup region changes. In my _main.php I had: <div id="main"> and in my templates I was doing: <main pw-replace id="main"> So before, the id="main" was enough to match - now it no longer matches. Obviously a mistake on my part - I have now replaced "<div" with "<main" in _main.php and everything works again.

@bernhard - I think the first issue might be something that should be fixed in the core Tracy project, but then I also don't know what you've had to do to "move the debug bar out of the swapped area" I don't think the second issue is related to htmx - sounds like maybe you have a lot of d() content stored - perhaps multiple console tabs? LocalStorage is usually limited to 5MB. I really need to move everything over to IndexedDB, but not sure when I'll be able to get to that.

Hey @bernhard - does everything work as needed if you replace all instances of $config->paths->root on these lines (https://github.com/adrianbj/TracyDebugger/blob/40cfe39239ea1fb2d6ee50920ebc9f3f86b21048/TracyDebugger.module.php#L1058-L1071) with your project root? Or are other changes needed?

Hey @bernhard - good catch. New version supports searching whatever is in the label.

Hey @bernhard - I revised the last commit so now you can use tags. The default is now set to: {name} ({email}) Hope that helps you and others.

Hey @bernhard - I didn't come to the forum to see your updated suggested about the email in brackets and already added the custom label field option, so hope that's ok.

Yeah, might be worth a strikethru of the "logs" and add "info" so it isn't too confusing when reading through, but also points to the exact issue in the title.

Thanks @iank - curious if you have Ghostscript installed - I do and don't have any issues, but some of the reading I am just done suggests it can contribute. The other thing that comes up is a missing or misconfigured font paths (e.g., /etc/fonts/fonts.conf) I did also read that IM6 is slower at this than IM7, but I am also running 6 without issues, so who knows :) Otherwise, I am really not sure at this point. I'd love to hear if anyone else has the same issue. It's possible to use an exec call to IM's convert but I didn't take that route because on some servers exec can be disabled. Maybe the best option for you is to just disable the Versions List unless we hear others having the same problems.

Thanks @iank - could you let me know what version of PHP and imagemagick and imagick you are running? Could you also figure out if it's queryformats() or getVersion() that is the main culprit. Thanks.

I don't actually cache anything for this panel - never seen any performance issues before, but perhaps PHP's OpCache is? Perhaps you would be willing to debug which component is the issue? These are the lines that populate the various versions. You could start by commenting out the MySQL ones, then the server settings, then apache modules, etc. https://github.com/adrianbj/TracyDebugger/blob/5e5d483a7f4d30c4e3f52c40921897a4603b6151/panels/ProcesswireInfoPanel.php#L205-L292

@iank - just committed a new version with a revamped panel selector - now uses a table and fixes those wrapping / alignment issues. Hopefully this will prevent future confusion as to what panel is having issues.

Thanks for figuring that out. At least the logs rabbit hole made me notice an issue with its caching which is great :) Now for the reason for the Info panel - can you please go through Tracy's settings for the panel and figure out which of its sections are causing the slowdown - I can only think it's the Versions List and something on the server taking a long time to return something within that. I can replicate the misalignment issue when the ms is really long like that, so I'll take a look at fixing that.

Thanks for all those details - helps to narrow things down a bit - it's certainly not an issue with the size or number of log files. I still don't know why you're having the slow loading or why the ms/kb is showing when the panel isn't loaded - I'd be curious if there is a difference if the panel is disabled permamently from Tracy's settings. One thing I did just find and fix was the caching - it wasn't actually working as intended. I still don't think it will help with your slow loading, but worth checking to see if it also has any impact on the ms/kb populating when the panel is disabled - it shouldn't but who knows 😖

Hi @iank - that first screenshot is confusing me because if the PW Logs panel is disabled, it shouldn't load at all and you shouldn't see any ms/kb values. I am not really sure what you mean by "only seems to work for a minute or so, and then the long loading time reappears" - if you're using the "sticky" option to disable it, then it should remain disabled until cookies are cleared, but even if that happens, the checkbox next to it would be checked. I can't see a way for the ms/km to be there with the checkbox unchecked (after sticky has been clicked). As for the actual slowdown - you mention that the log files on dev are the same - are they the same size as well? How large are the log files - can you check through and let me know the largest one. Are you loading just the default last 100 lines? It's also worth noting that Tracy caches the lines from the log files so it should only ever read them if their modified timestamp has changed since the last load. Let me know those things and we'll go from there.

Just a note that I set Tracy to 100000 so you'll want to make sure your highest one is still lower than that if you want to be able to use Tracy within other modules.

Having Tracy run on production servers in production mode can be a very useful tool - logging exceptions with Tracy's full stack trace saved and notification of errors via email and slack.

Thanks @Tiberium I can reproduce if I try to load Tracy's settings page when it's not enabled and the logs file doesn't exist, but this is not something that will ever happen with a regular usage which I suppose is why no-one has ever reported it. Anyway, new version should sort things out for you.

Hi @Tiberium - Tracy definitely tries to create the directory: https://github.com/adrianbj/TracyDebugger/blob/98d9d3b8c3eb141f25d75ec1a4ec62d12ad42527/TracyDebugger.module.php#L995 everytime it is loaded, so there must be some permission issue.

Yeah, actually that is a better approach - I was actually just falling asleep and realized that there is the possibility of an RTE with something like empty <p> </p> tags so you definitely want to strip those before checking !$text

Sorry, now I am seeing: Deprecated: strip_tags(): Passing null to parameter #1 ($string) of type string is deprecated I guess it needs to be after: if(!$text) return;