adrian

@kongondo and everyone else ? I have just added caching for both the Tracy and PW logs panels so now they only read a log file if it has changed since it was last cached. This should make a dramatic difference to most page loads. Do note that if you have a large log file and a new entry is added, then the load time will still be slow for that first page load when the entry is logged, so you still may want to delete log files (or use the PW log prune function) if you notice a slow load. Hope that helps everyone.

Hey @Robin S - this looks great! I just noticed that the contents of your $default_replacements array is much more comprehensive than the list of character replacements in the InputfieldPageName settings in the core. Not sure whether Ryan would be willing to change those, but it seems to me that your list should be used there. Then perhaps you could pull that list in for your module and users of your module would benefit from any manual additions they have made to those settings, rather than using the character_replacements_str config setting in this module - it seems to me that users may need to add their custom replacements to both places at the moment.

Hey @bernhard - just an FYI regarding your PR which I think it a great idea by the way, but I don't think Ryan wants "all" to actually be all sanitizers: https://github.com/processwire/processwire-issues/issues/85

Hey @bernhard - glad you figured it out. The one thing I would like to know more about is that errant padding at the bottom of the tab labels/links. Could you please figure out what css rule on your site is adding that padding so I can adjust Tracy's CSS so there is no conflict? Thanks.

Just did some debugging and figured out it's a bug in VSCode in a recent update. Stay on v1.31.1 and you'll be fine. Github Issue: https://github.com/Microsoft/vscode/issues/70177 And if you've already updated and things are broken, you can get 1.31 here: https://code.visualstudio.com/updates/v1_31

Can you please clarify that it was deleting all Tracy logs, and not just disabling the Tracy logs panel that fixed the loading speed? In other words, is the loading speed ok with the Tracy logs panel open now that the logs have been deleted?

They are also useful if you are debugging the PW core and bd() calls won't work. This way you can make a $log->save() call and it will appear in the PW logs panel in the Tracy bar - easier than hunting it down in the PW admin.

Thanks for narrowing it down. I can't understand why the Tracy logs would be so slow, but I'll take a look and see if I can figure something out. As for "not needing" them - I would suggest reconsidering - sometimes they will capture errors that Tracy will miss for reasons related to the timing of when Tracy is loaded (I think), so seeing a red icon for one/both of these can highlight the reason for an error you might otherwise be confused about.

But which one is the culprit? I'd really like to figure out which one is causing the problem in case I can fix it ?

Hey @kongondo - I would start by disabling all custom panels via the panel selector. Typically it's the RequestInfo panel that can be the slowdown, so if you identify it as such, then check out its individual section settings and disable everything and re-enable to see which one is the problem. If it's the log panels, then I would suggest clicking "Delete All Logs" for both the Tracy and PW logs. I have seen these slowdown things before when there are lots of large log files. Let us know what you find. BTW, are you using PHP 7.1+ , or older?

Hey @tpr - let me think about this and I'll follow up on your PM with your other idea. @bernhard - probably best to request that as a core feature. On the issue of linking to your code editor, I've just noticed that VSCode links are no longer working for me - not sure if it's a VSCode update that broke something or what. Are they still working for you?

Actually, looking at this, it works as expected for me:

Yep!

The issue is that hooking the path affects the relative url, not the full http url. You can do a redirect to that $page->products_categories_external rather than an $event->return. You could do this from your path hook or maybe it might even be better to do it from Page::render

Changing the path will result in a changed url so I guess I am missing the point somehow. Here is the classic thread on this topic: https://processwire.com/talk/topic/1799-routes-and-rewriting-urls/

Are you talking about the new feature in the Page Files panel? The catch with putting them at the top is that if you have multiple image fields on the page (including within repeaters etc), then you have to scroll down anyway so not sure it helps. Or maybe I am not understanding exactly what you mean?

Maybe, but we have orange for orphans, and red for missing. I think the only option would be the new yellow "note" color that netcarver added when he revamped the Diagnostics panel, but given that temp files don't need a delete button (like the orphaned and missing files have) which is color coded, there won't be a key on the panel to indicate what the yellow color means. One thing to note is that the Temp column only appears if there are files with temp status. If the PW core is doing it's job properly and there are no 3rd party modules breaking the temp functionality, then there shouldn't be any temporary files, except in the AJAX version of this panel after you've just uploaded a file, so I think it's probably ok as is.

It's not a new panel ? That Page Files panel shows all files on a page and highlights orphaned and missing files. The Temp status column is the only thing that's new.

What do you guys think about this in Tracy's Page Files panel? At least this gives us a quick way to check to see if there are any temp files on the page.

Yeah, it was a combination of the older version and the disabled modals. in newer versions of Tracy, that error wouldn't appear, although the debug bar still wouldn't have appeared with the dump because it was disabled, but the error threw me and made me think the cause of the problem was different. Anyway, glad it's working for you now.

@bluellyr - could please let me know what version of Tracy you are running? Those errors should not have appeared on recent versions even with the modals disabled.

@Robin S - actually, I think you might be correct in this case. That was my initial thought, but some recent changes I made to Tracy should have actually prevented that error, so it threw me off. So I think it might be a combination of an older version of Tracy and the disabled in modal option. I agree that the defaults should be for Tracy to be on in all those modals/panels/iframes - I have made this change in the latest version.

The changes Ryan made were to ensure that Tracy is always the first "site" module loaded. This means you can always debug other site modules. Getting Tracy to load earlier is problematic. init.php won't help - it already loads on init. I would like to be able to load Tracy earlier, but I don't see Ryan being keen on doing what is required to make that happen. You have got me thinking though about figuring out how we might be able to at least get bd() working earlier - this wouldn't include all of Tracy's other error capturing / reporting abilities, but I think it would still be helpful. I'll have a think about it.

@szabesz - that is the temp status we are talking about. Given that @Robin S has started an issue on this, I will let him follow up.

@Roberts R - that WYSIWYG card links to: https://processwire.com/about/what/#comprehensive and it works fine for me. Can you explain a little more about what doesn't work?