adrian

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?

I have included those in the dumps above - note that outputFormat is set to "0" on both sites. This is the "Automatic (single item or null when max files set to 1, array of items otherwise)" option. It actually doesn't even help if I set the field to array or single item - the formatted version always returns null.

This is really weird - I have two site which are on the same server and are basically identical. For one site there is no problem, but the other one exhibits this weird bug. This is the version with the problem This is the one that works as expected There are no relevant hooks that I can think of. Can anyone see anything I might be missing or do we think this might be a weird bug?

Hey @gebeer - I just stumbled across this again - do you know if this was ever reported on Github? I am still using that hack here on a couple of sites, but not sure if it's still needed, so just wondering if you had any more recent info on it.

@Robin S - to support the textareas pro field, I think you'll need to add a new block after these: https://github.com/adrianbj/BatchChildEditor/blob/85d81d7e7cb452c0d5ece34583e42c1f2f4aae50/BatchChildEditor.module.php#L1644-L1649 and a updateTextaresField() method to handle the import. This might actually work for other simple multivalue fieldtypes, so perhaps it could be: elseif($f->type instanceof FieldtypeMulti) { Not sure you timing on needing this. If you don't get to it (or decide to take a different approach), I'll try later in the week.

Hey @Robin, I don't have much time, but some quick answers to hopefully get you going: 1) It does support multi value fields, but it does so with a multi-value separator (default is: |) so you would need to concatenate your separate columns into one with a separator. 2) I believe it should support importing for different templates for child pages, but only for one to one column to field relationships. I think where you will have trouble is if you want to match specific columns to specific fields. This leads into your next question. 3) If you have a mismatch of columns to fields, then you will want to use the "Field Pairings" feature. This is available if you make the parent a "configurable page" in the module settings and then define the pairings on the settings tab of that parent page. 4) See answer to 3 ? 5) Currently there is no match by ID - if you are doing an "update", then it's all based on the order of child pages. Maybe this feature could be added though. Hope that helps. Cheers!

https://github.com/processwire/processwire-issues/issues/797