Using the latest dev version for D7: pdf_to_imagefield 7.x-2.x-dev (March 6, 2012)

When setting the PDF field to use the Drupal Private filesystem, and adding a PDF, the path to the PDF is rendered without "private", but does include an extra "/" in the path. I set the field back to use the Public file system, and the PDF is rendered just fine into an image.

Awesome module btw, thanks for putting in the time.

CommentFileSizeAuthor
#8 pdf_to_imagefield-1471286-8.patch593 bytesqueenvictoria

Comments

dman’s picture

dman commented

Thanks for the report, that's not the sort of thing I'd have remembered to check.
file paths changed a LOT in D7 :-/

wOOge’s picture

wOOge commented

Np — yeah I'm just reading up on it now to see if I can help at all — and it's pretty deep stuff. I see in the module code where the path is built, but I can't figure out how to get Drupal to output the correct "private" path.

On line 389 in pdf_to_image.module there is:
$path = $base_url . '/' . variable_get('file_public_path') . substr($items[0]['uri'], 8);

And if I do this:
$path = $base_url . '/' . variable_get('file_' . file_default_scheme() . '_path') . substr($items[0]['uri'], 8);

I get something close, the path output is correctly, but it's the real physical path, not the protected Drupal path... if that makes any sense.

dman’s picture

dman commented

Well $path = $base_url . '/' . variable_get('file_public_path') . substr($items[0]['uri'], 8); is just fecking horrible.
It's fighting against the right way of doing things desperately - and losing.

Need to embrace the file wrappers and use them as intended.
There are some API calls that will resolve the path for you - NOT through string chopping.

The one that was needed in that hack-job above is probably

drupal_realpath($items[0]['uri'])
dman’s picture

dman commented

Reading up, it seems that (although it works best) even drupal_realpath is deprecated and one of the other
Drupal 7 File API functions should be used instead as needed.

In short - all modules need to stop thinking about filesystem files and paths and pass the file URI around internally as much as possible - even including the point at which you need to read & write.
As we are actually creating commandline instructions that run on the server, then we do have to unpack the file wrapper before then.
I can't see docs that indicate what the recommended replacement for drupal_realpath would be.

wOOge’s picture

wOOge commented

You're definitely right — just not sure how to get drupal to output a path that can be accessed like: "/system/files/file.txt"
Even though the real path is: "/www/var/drupal/sites/default/files/private/file.txt"

dman’s picture

dman commented

Is there a problem with using the absolute path? If doing it by hand, we normally wouldn't bother, but if the system is doing the thinking and prefers full filepaths - let it? The commandline will do what it's supposed to.

wOOge’s picture

wOOge commented

I see what you're saying, but Drupal is controlling access to the file since it's set to private.

This get's me the Drupal controlled path to the file, but I still get a permission denied when I access it for some reason:
file_create_url($items[0]['uri']);

queenvictoria’s picture

queenvictoria commented
Issue summary: View changes
StatusFileSize
new pdf_to_imagefield-1471286-8.patch593 bytes

@wOOge's fix in #7 works for me. Patch attached.

dman’s picture

dman commented
Version: 7.x-2.x-dev » 7.x-3.x-dev
Status: Active » Fixed

Testing:
* latest dev version 7.x-3.x from git, without the above patch.
* Created a content type "Private PDFs"
* Configured the Private file system path
* added an image field, private storage, limited to one image
* Added a file field that holds PDFs, use the PDF to Image widget, private file storage, and pointed at the image field.

* created a new node, uploaded a PDF ... processed ... It worked.

So I'm not seeing the problem.
Still, the code is cleaner, so it's nice to go in.

PUSHED into 7.x-3.x
Thanks Mr Snow!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.