adrian

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?

Sorry @bluellyr - my apologies - I didn't initially realize what you meant by "template context". Using Tracy to debug the PW core is hit and miss. It loads before all site modules, but for the core and core modules it often isn't available depending on exactly what you are trying to debug. Unfortunately there isn't anything I can do about this. Typically for this, using $log->save('testing', json_encode($page)); or something like that is your best bet.

Hi @bluellyr - in general you should use the shortcut methods: bd(), d(), l(), fl(), etc but if for some reason you don't want to, try: \TD::barDump('test'); The reason you need the backslash is because your template files have the ProcessWire namespace so you need to get to the global namespace to access the TD class.

I am not the right person to really comment on this given that the only abilities I have in a second language is a smattering of travel Spanish, but this does seem pretty cool and makes you sound a lot less silly ? DeepL Google So, a DeepL module sounds like a pretty cool idea to me.

Well I discovered the reason for the temp status issue in this case. I recently made a change to my Custom Upload Names module to add the temp status after renaming the file - this is because a PW rename() call removes the temp status so I wanted it added back in case the page was never saved. The problem is that PW doesn't use the temp status when you have the field's "override existing files" option checked. So, I have updated my module to not add the temp status when the field uses the overwrite setting and now we're all good. The thing is though that I've seen this issue before I added this feature to that module and I've also seen it on sites where I don't use the module at all. I feel like something should still be reported, but at the moment I am not sure how to reproduce the problem without the module being the cause. Perhaps as @Robin S pointed out, temp files should be deleted on page edit, in case they weren't deleted on page save. Do you guys think that is worth a bug report / suggestion? Maybe another component to it is to ask Ryan why temporary files are included when getting unformatted - maybe that makes sense for internal needs, but I think it's confusing for the API to contain these images. Any thoughts?

Ok, so I've done some tracing to see what is going on and it's because the files are being tagged as temporary. This is the key line: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Fieldtype/FieldtypeFile.module#L411 that is causing it to return null. When a file is added, it is initially set to temp: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Pagefiles.php#L347 so I guess for some reason the file upload process didn't complete properly so the temp status (timestamp) wasn't updated. Thing is that the files are fully uploaded and there is nothing wrong with them. I just manually changed the created dates in the database, via Adminer of course ?, and now everything works as expected. @Robin S - you seem to be the expert in issue reporting these days - any thoughts on the best way to handle this to explain best to Ryan?

@matjazp - no hooks on url, but I think it's before that anyway, because even $page->document_url returns null which is very weird. @Robin S - I tried renaming but no luck. I have seen this on several sites over the years and typically don't have time / energy to post about it. I am surprised it's not reported by others more often, but I guess give that @Autofahrn has experienced it and not reported also indicates that maybe it's not that uncommon. I guess also, the maxFiles setting of 1 is not used as often as 0.

Thanks for the report - looks like the new Tracy core is forcing strict rules in JS which is affecting some sloppiness in my code. I have fixed this one, but I think we'll need to lookout for issues like this.

Agreed, and this is even weirder - look what happens when I call d($page->document_pdf->url); before the others - even the getUnformatted version is now broken.

Thanks for the confirmation @Autofahrn - I have had to set to return Array on other sites as well for no discernible reason. In this case, they are both multi-language sites, although in the case of the site that's not working, there is actually only one installed language - I wonder if that might be related?