Since Drupal 7.20 was released, pdf_to_imagefield module doesn't properly render image derivatives.

Update notes:

The security fixes in this release change all image derivative URLs generated by Drupal to append a token as a query string. (As an example, links that previously pointed to a URL like http://example.com/sites/default/files/styles/thumbnail/public/field/ima... will now point to a URL like http://example.com/sites/default/files/styles/thumbnail/public/field/ima....)

I can verify this is the case. "Original image" works as expected, but setting an image style only shows a broken image icon.

CommentFileSizeAuthor
#2 1925192-drupal_720-2.patch863 bytesguillaumev

Comments

rkeppner’s picture

rkeppner commented

Luckily, there is a workaround. However, it essentially rolls back the security fix.

Also from the notes:

Sites which require the ability to generate new image derivatives without a token can set the 'image_allow_insecure_derivatives' variable to TRUE, for example in settings.php:

$conf['image_allow_insecure_derivatives'] = TRUE;

This will cause Drupal to bypass the token check when generating image derivatives, but will also completely remove the security fix introduced in this release and will therefore increase the site's vulnerability to denial-of-service attacks.

guillaumev’s picture

guillaumev commented
Status: Active » Needs review
StatusFileSize
new 1925192-drupal_720-2.patch863 bytes

Please try the following patch. It should fix it without having to use $conf['image_allow_insecure_derivatives'] = TRUE.

dman’s picture

dman commented
Issue summary: View changes
Status: Needs review » Closed (cannot reproduce)

Is this actually still a problem? I've not been replicating it for a while.
The image_allow_insecure_derivatives was a pain all 'round, but wasn't it more about upgrade pain than anything that affects new sites?

As I can no longer reproduce the problem on clean working sites, I'll put it to cannot reproduce.
If there are steps that can be described to see this issue still in action, please re-open.

morbus iff’s picture

morbus iff
they/them
commented
Version: 7.x-3.1 » 7.x-3.2
Status: Closed (cannot reproduce) » Needs work

Reopening, as I'm still seeing this.

Running 3.2 against Drupal 7.26. Whenever PDF to Imagefield creates new images, it saves them into the database as public:///filename.jpg, which then causes image derivatives (thumbnails, etc.) to fail. A similar (recent) report is at https://drupal.org/node/1822050. The cause lies in pdf_to_image_generate_page(). Funnily, the attached patch (which has been mainlined) is causing the issue (likely because it was against 7.20, and then fixed in Drupal 7.22 so that it wouldn't happen, according to https://drupal.org/drupal-7.20-release-notes - search for "extra slash").

If I change:

  $image_uri = $image_dir_uri . '/' . $params['pdf']['file']->fid . "-" . $page_number . '.jpg';

to:

  $image_uri = $image_dir_uri . $params['pdf']['file']->fid . "-" . $page_number . '.jpg';

Everything is magical. For debugging purposes:

  • My $params['image']['instance']['settings']['file_directory'] was empty.
  • My $image_dir_uri was public://.
dman’s picture

dman commented
Status: Needs work » Fixed

Thanks for the diagnosis and explanation! Understanding the exact problem really helps.

As you've noted, it matters if the $params['image']['instance']['settings']['file_directory'] is empty or not - simply dropping the '/' would then cause misbehavior if there WAS a file_directory set. So everything is not magical yet. And I recommend the use of a file directory most of the time. Which is likely why I could not replicate.
So yes, this patch is indeed cool.

Tested this with both the image field set to have a subdir, and without a subdir - derivatives appear OK.
Putting this in now.
As there have been a few other significant fixes since 7.x-3.2, I'll do a version roll also.
Thanks!

Status: Fixed » Closed (fixed)

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