Jump to content

Files field returning null unless I use getUnformatted


adrian
 Share

Recommended Posts

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 

image.png.b62feb1d2dd961059c8ce89cd4968c01.png

 

This is the one that works as expected

image.png.67c7e4638009939f311b84191b20742b.png

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?
 

 

Link to comment
Share on other sites

Just now, LostKobrakai said:

Can you look at the settings of the field especially the one stateing if the field is single value or multi value?

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.

Link to comment
Share on other sites

Seems I'm not alone encountering strange issues with File fieldtype configured for single items. I'm not sure if my symptoms relate to this one, but they are similar weird (work on one site/situation, fail on others).

On one multi-language site I've added a single file to the language template which holds a SVG of the flag. The SVGs retrieve correctly for one language, but exactly one SVG can't be retrieved if the user is running from another language (I can try to replicate if required). Did the same on another site (using the same code) where it works ok.

This does not relate to the language setting itself, I also saw a similar behavior with the same field used on different pages (can't remember exactly).

As my personal workaround I've switched those fields to always return an array, even if they only hold a single item.

Happens across any PW 3 version I've encountered so far.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

2 minutes ago, LostKobrakai said:

It's strange that even the field by itself returns null here. It should normally be at least something.

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.

image.png.80e8b5167910b273eff5a138f824898a.png

Link to comment
Share on other sites

Very strange, I've never experienced such a thing before.

A couple of ideas...

1. Any chance there is a name clash for "document_pdf" on $page - something setting a custom property named "document_pdf" on the $page object?

2. Does changing the field name to something different fix it? Then maybe change it back to the original name and check again. 

  • Like 1
Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

3 minutes ago, adrian said:

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.

As discussed above, I'm thinking that it is somehow related to multi-language features. I don't work on multi-language sites which might explain why I've never seen it across dozens of sites.

5 minutes ago, adrian said:

I guess also, the maxFiles setting of 1 is not used as often as 0.

I use this option on every site, but never with the "Automatic" option - I prefer to always set the formatted value manually to align with the max files.

Link to comment
Share on other sites

1 minute ago, adrian said:

@Autofahrn has experienced it and not reported also indicates that maybe it's not that uncommon...

Since I'm a software guy myself, I prefer reporting only if I am able to provide steps to replicate the issue. Since I couldn't find any rules for this one yet, so decided to stay quiet. Maybe not the best choice...

Regarding the multi-language feature I probably can check If I had this on one of my single-language sites (easy, just check for single file fields set to return an array).

  • Like 2
Link to comment
Share on other sites

15 minutes ago, adrian said:

I have seen this on several sites over the years and typically don't have time / energy to post about it.

I know how this feels. I'm sure there is some core issue with the admin login that semi-regularly gives me CSRF errors when I attempt to log in but I haven't been able to isolate the conditions to reproduce it - my gut feeling is that it's something to do with an expired cookie. I'm always in a hurry when it happens so I just back button and resubmit the form.

To get to the bottom of your issue I expect it could be traced by dumping within the chain of methods that get the data from the database and ultimately deliver the formatted value. But who has time for that when you're on a deadline?

  • Like 2
Link to comment
Share on other sites

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?

 

  • Like 3
Link to comment
Share on other sites

39 minutes ago, adrian said:

Aha, great that you have found the source of the issue.

In terms of a bug report, I don't expect anything can be done to guarantee to always successfully remove the temp status in all circumstances - I guess there can always be upload glitches of one sort or another. But what would be helpful is to make sure that files with temp status are removed when a page is (re)loaded in Page Edit, so you are not scratching your head wondering why you can see an image in the field that isn't accessible from the API.

The thing is, I thought this already happened, which is why if you upload an image then refresh without saving the image is removed from the field. So I suppose it could be a matter of working out why an image with temp status is remaining in the field and is not removed.

  • Like 3
Link to comment
Share on other sites

Ok, so this differs from my symptoms. I've rechecked some of my sites and saw my various workarounds and also have a single language site with single file field explicitly set to array return.

On other sites I've used a different workaround, which also fixes my language flag issue. Setting output formatting on before accessing the image, otherwise the field returns PageImages array instead of PageImage, so my loop now looks like:

		$languages = wire('languages');
		foreach($languages as $l)
			{
			$l->of(true);	// ensure $l->svg_image returns a PageImage
			$imgUrl = $l->svg_image->url;

Output formatting is obviously off for some reason for the default (first) language if current session is not on default language. Just realized that on my other site (where I use SVG flags on the language template) I've also switched the field return to Array. So maybe this is more deterministic than I thought and indeed probably related to multi language sites.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

1 hour ago, adrian said:

Do you guys think that is worth a bug report / suggestion?

Without steps to reproduce I doubt Ryan could/would do anything about it. Might be best to wait until you notice it again in a situation where Custom Upload Names is not involved and raise an issue then.

1 hour ago, adrian said:

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?

I do think it's odd that the formatted/unformatted value should be different with regard to temp files - I'll open an issue for this. Edit: issue is here.

  • Like 1
Link to comment
Share on other sites

3 minutes ago, adrian said:

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.

What do we think? Awesome, of course! However, another panel? Can't you add it to an existing panel instead, maybe Request Info?

Link to comment
Share on other sites

2 minutes ago, szabesz said:

What do we think? Awesome, of course! However, another panel? Can't you add it to an existing panel instead, maybe Request Info?

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.

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...