upload.module does not display previews for when private files are enabled.

We had the identical problem with a 4.6.5 installation. When talking with the developers, the answer was "Do not change the private file setting after things have already been set up. You should do it right upon installation". Unfortunately, I don't know how we solved the problem (it just sort of 'went away', and it wasn't a cache problem).

So I guess I'm saying 'this is not a new issue'.

Preview does not work when private downloads are used. The upload module does some special rigging to preview public files, but not private ones. During preview they are not in the files table in the database, so they cannot be found. This may be fixable, but in my opinion is not 'critical' enough to delay 4.7 release.

As for the saved, nodes. I am unable to reproduce the problem. It works for me.

I vote to downgrade this to less than critical priority.

i just tried reproducing this, and failed. i followed the suggested steps on a fresh install from CVS head, and everything appears to be working with file uploads/attachments, even when using a non-standard directoy for the "file system path" directory. i'm hereby downgrading this to "normal". stefan, can you try again and see if you can reproduce the problem? if so, please post more details on a) exactly what you did to reproduce it and b) exactly what the faulty behavior you're seeing is. at this point, i don't see any bug at all. sorry.

-derek

Updating the title to reflect the actual issue. I will play with this when I get a few cycles next. It should be working for both private and non-private files. Could anyone who has their tmp folder in a non-public directory let me know the state of their file previews?

The problem can be fixed by a special hook_download in upload.module. The file.inc functions store some info about files in $_SESSION, because they need it to preperly handle previews. Or at least they did at one point...

Here's a function from a module I wrote for one of my sites. Sorry it's not a real patch, I don't have time myself, but with just a little tweaking someone could make it work with upload.module. It enables the downloading of files that the current user has uploaded, but have not yet been moved from temporary to permanent storage (that is, previews).

  // this code or something like it needs to be merged in upload_file_download()

  // let the user see any files he/she is previewing
  if ($file = $_SESSION['file_uploads'][$filepath]) {
	$name = mime_header_encode($file->filename);
	$type = mime_header_encode($file->filemime);
	// Serve images and text inline for the browser to display rather than download.
	$disposition = ereg('^(text/|image/)', $file->filemime) ? 'inline' : 'attachment';
	return array('Content-Type: '. $type .'; name='. $name,
				 'Content-Length: '. $file->filesize,
				 'Content-Disposition: '. $disposition .'; filename='. $name);
	
  }

upload_download is a callback written sepcifically to handle previewing of files, when file access is 'public'. It does not need to change. upload_file_download is called when file access is 'private'.

upload_file_download needs code like what I posted, merged into one of it's if...else clauses. The code needs to find the file in $_SESSION['file_previews'], like upload_download does, but it needs to return the info hook_upload_download returns.
It should behave like upload_file_download currently behaves, but find the file info in $_SESSION if it fails to find it in the database.

@yogadex
Actually the upload_download should handle both public and private previews.
The path is stored in the menu for all previews, set to the callback upload_download, whether
they're public or private.

upload_file_download is expressly for serving private files after they have been stored.
I'm going to try to get to this today. I still need to set up a private files site.

@dopry,

I think you'll find that if private files is set, the file path will look something like "system/files?file=suchandsuch". In this case, upload_download will not be called. But upload_file_download will.

I'll be interested to hear if I am wrong, however.

@yogadex
Yeah you are right. :)... Sort of...
file_download will be called, which will call upload_file_download for authentication. Thats only because of that stinking file= nonsense...

I should have the patch later this evening.

Ok well here goes. Let killes rain hell on me, but there is some feature creep in this fix. This patch makes clean url's work for private files... (and for the crafty might make it easier to migrate from public to private and back to public files again.... think .htaccess, -f, system/files/image.png..., domainroot/files, domainroot/public_html/system/files)

Its a little comment heavy... they can be cleaned up if the patch is acceptable.

Oh yeah, update status...

i gave this a good exercising and it works as advertised. RTBC ... i'm not sure why those were not clean urls to begin with. i think this is an acceptable bug fix during a beta.

applied. Didn't see any features creeping.

Could the comments in this patch be cleaned up? They are IMO not clear enough (and don't conform to the code guidelines either). I doubt you would still know what you meant in 6 months.

Yes, but I love trying to guess how sleep deprived I was when I wrote the comment. Its like a game :)....
Here is an update with terse comments.

There has to be some way to make the status changes more intelligent. Or remind me that I may want to update the status when I attach a new file. It'd save us some ids.

applied

Please take a look at this issue. This patch will break a lot of existing content on sites with private files enabled.