List download plugin with PDF

[troester]

is producing blank PDF files only.

dump($pdfContent,'pdfcontent'); (in download.pdf line 400) is returning


PDF in details view is working.

 

[cheesegrits]

Can you give me the line number that notice is on? Is it 241?

I can't replicate a blank PDF. Do you have ACLs on the form? If so, do you have the "allow local pdf" option enabled in global settings?

The download plugin cheats, and does a file_get_content() on a details view URL, rather than driving a details view by hand inline. Which means that the call that builds the details view is run from the server, with no authentication set.

-- hugh

 

[troester]

Sorry, I can't see the line number in dump, it's cut off
I dumped also the URL in download.php (around line 392). If I use it directly the PDF is created.

Ah, yes, I was logged in when trying this (same browser).

Just tried again: If I'm logged out I get a blank PDF, too.
With "allow local pdf" the download plugin is creating the PDFs.

So the only issue is that it doesn't use the given filenames for the PDFs inside the zip.
Which may be related to the "name" notice?

 

[cheesegrits]

With "allow local pdf" the download plugin is creating the PDFs.

Cool. What that option does is basically sidestep list ACL's (canViewDetails), if the request is coming from "localhost", and the format is pdf. I'm relatively sure it's "secure", in that even though that feature will bypass ACL's, the download plugin checks that the user has access before doing the CURL call back to itself to generate the PDF. One of these days I might re-code the PDF feature in the download plugin to actually drive running the views properly (kind of how we do in the email plugin), but things get really funky when trying to run a details view from inside a list model plugin. Which is why when I wrote this I took the lazy way and just make a CURL call from the server back to itself to capture a details view, and hacked in the workaround for ACLs.

So the only issue is that it doesn't use the given filenames for the PDFs inside the zip.

Yeah, that's kind of unavoidable. The download plugin code that calls file_get_contents() on the details view has no knowledge of the filename that view decided on. Although having said that, I think there's a way of getting the response headers from a file_get_contents() on a URL. Or I could switch out file_get_contents() for an actual CURL call and get the content disposition header from that.

How big a deal is it for you to have the right filenames in the ZIP?

-- hugh