adrian

Hi everyone, Got a new feature for you today (at the request of @eydun). First some background - some of you might not even be aware that Tracy saves .html files of it's bluescreen stacktrace when an exception is thrown. The cool part about this is that these happen when Tracy is in production mode on a live site, so if you get a notification (via email or slack) that an exception was thrown, you can navigate to /site/assets/logs/tracy and load these html files in your browser and inspect the code (including values passed to functions etc). This can make debugging much easier because you don't need to try to replicate the error again. The new feature today makes viewing these much easier with a dedicated panel listing all available exception files. Simply click on one to have it display as it would if the exception was thrown while you were interacting with the site. The icon turns red when there are new exception files since your last visit and it shows which ones are new. The clear button will remove the bluescreen so you can return to your site without needing to reload the page. The Validator panel also had a revamp. It now uses https://validator.w3.org/nu/ because https://html5.validator.nu/ was no longer working and I have updated the CSS to support their new output DOM. For those of you who don't know, the key value to the Validator panel is for local dev sites where you don't have a publicly accessible URL to use - this sends the HTML of the page directly. Also included are some PHP 8.2 deprecation fixes.

Hi @teppo - sorry for the delayed response. #1 - from what I can tell, the instances of "There is no difference between these revisions." are only an issue when saving via the API (in this case a frontend form). Not sure if it matters (seems unlikely), but it is an AJAX saved form and fields are saved with "setAndSave()" - maybe that is a factor? #2 - is this case, it's an admin save.

Hi @teppo - firstly, just another mention of how important this module is to me - it's always one of the very first installed on every site, so thank you :) Now to some issues / suggestions if I may. 1) We often find lots of revisions listed for a field that simply return "There is no difference between these revisions". I don't really understand why a revision is stored if there were no changes made. It seems like unnecessary DB bloat, but more importantly, it makes it very hard to find the revisions where changes actually are made. Do you think this behaviour could be changed so that no revision is stored? 2) We often see changes to page reference fields (checkboxes in this case, but I expect it probably doesn't matter the inputfield type) where changes are recorded, but in reality, they weren't actually changed - why would they be recorded as being removed and then added again? 3) When you have a page template where the width of fields is a small percentage (25%, 33%, etc), the interface for viewing the revision history is quite awkward, with lots of horizontal and vertical scrolling required. I was wondering whether you think it might be a better experience to load the revisions in a PW panel (pw-panel - https://processwire.com/blog/posts/pw-3.0.15/) Thanks so much for considering and let me know if there is any way I can help with any aspect of this.

@sodesign - thanks for posting about this. Just to let everyone else know, there is another thread about the same issue affecting the Profields VerifiedURL field and Ryan is engaged, so hopefully this will be sorted sooner than later. I have a workaround for now if anyone needs it urgently.

Thanks @MarkE - that's basically what I had to do. The difference however is that when hooking on saveReady for a just cloned page, the id is 0 even though it is a valid page and not a null page.

Just a follow up to note that my issue with that "WireDataDB sourceID must be greater than 0" error was due to a hook on Pages::saveReady that was setting $page->meta even when the ID of a recently cloned page was still 0. Not something anyone else is likely to come across, but just in case, now you know to be aware of it :)

Hi @bernhard - not really (and I am not sure it's actually related to page classes). I just came across that error for the first time and found Mark's comment about it here and thought I'd see if there was an already determined cause / solution.

@MarkE - did you ever solve the "WireDataDB sourceID must be greater than 0" error? I have been getting it on one install when cloning a page.

Let me know if you need those changed. https://github.com/search?q=repo%3Aadrianbj%2FTracyDebugger expireNever&type=code

Thanks for chiming in @Robin S - I was out when I replied above. Good point about reporting vs causing. Also, in case it helps, I do on rare occasions see lock errors in PW even without SessionHandlerDB. PS - That issue you pointed to is unfortunately not fully solved - I am still hoping Ryan might provide a better solution for that string issue.

Interesting - I wonder if you have the file compiler turned off in your config file - perhaps the "moduleCompile" setting?

@Roych - are you using the original (https://github.com/marcostoll/processwire-fieldtype-assisted-url), or my fork: https://github.com/adrianbj/processwire-fieldtype-assisted-url ?

@gebeer - are you running PHP8? If so, it might make a difference if you update to the latest Tracy - back in March there was an update to the Tracy core (which is PHP 8 only, although I maintain older versions within the package for those on older PHP versions so upgrading won't hurt). The other thing to make sure is that the "Use Native PHP Session" setting is unchecked. If those don't help, I am not sure what to do at this point - I can't count the amount of time I have spent workaround issues with SessionHandlerDB and Tracy.

Ah, thank you - I did a quick scan for function_exists checks around all occurrences of posix_getpwuid but missed that one because of the check for posix_geteuid - my eyes didn't see the difference. Fixed in the latest version. PS - yes, feel free to add new threads for bug reports - would definitely be preferable.

Hey @bernhard - the calls to that are already wrapped in a function_exists() so I am surprised that isn't enough - this is the first report I've had of an undefined function error. https://github.com/adrianbj/TracyDebugger/blob/0d88866516be43156c945b45c6cd77c664d79204/panels/DiagnosticsPanel.php#L1201 Can you figure out why that check is failing for you?

Thanks @bernhard - fixed in the latest version.

Hi @Jonathan Lahijani - thanks for the write-up. You mention "myself only", so perhaps that's the reason for your approach - so other superusers don't have Tracy running in DEV mode? Is that the key functionality of this approach that you needed? Otherwise, I think you might be confused about Tracy's DEVELOPMENT vs PRODUCTION modes. DEV mode is what enables the debug bar, while production mode runs Tracy in the background, logging and notifying errors (via email and / or Slack). It's not about whether your install is DEV or PROD. I just set to PROD mode and use the "Force superusers into DEVELOPMENT mode" option so that DEV mode is enabled for me (and other superusers) regardless of whether we are on the dev or prod servers.

Looks like we've been down this path before:

Hi @olafgleba - are you happy enough with that solution for now? Can you see a way to edit the module so it's not needed?

Hi @jploch - sorry for the late response - I was on vacation. Can you please point me to the line on the Github repo. I feel like it might actually be: https://github.com/adrianbj/TracyDebugger/blob/6f62b8e2c03e1520615ea654e79f4e44b61f9f20/TracyDebugger.module.php#L2847 but that isn't the line number from your error. Also can you please do a dump of parse_url($_SERVER['REQUEST_URI']); so I can see what is returned?

Thanks @bernhard - should be fixed in the latest version.

I think you likely upgraded from a very old version of Tracy at the same time you upgraded to PHP 8. When you saved Tracy's config settings, that adjusted the value of $this->data['styleAdminType'] thereby fixing the error.

@gornycreative - I haven't used it in quite some time, but I think it should still work.

@MarkE - I really do think migration to use imap_open as per my above post would be a better option given the status of the flourish library.

@matjazp - I am getting a little off-topic here, but I found some weird issues with UIKIT 3.16 - I should probably report them, but I was getting several FOUCs on the frontend of my site when I upgraded to it - things like menu dropdowns and modal popup that was meant to be initially hidden, so I stuck with 3.15. Did you experience any issues?