I noticed you can only process pdf fields that store one value. If you want to store images for each pdf in a field which allows multiple values into an image field which allows multiple values and have a corresponding image for each pdf, then you might want to check out the following patch proposal.
| Comment | File | Size | Author |
|---|---|---|---|
| pdf_to_image.module-20131211.patch | 8.46 KB | uberhacker |
Comments
Comment #1
dman commentedI do endorse switching from
$pdf_file = file_load($items[$field_lang][0]['fid']);
to the more flexible
foreach ($items[$field_lang] as $i => $item) {
That's just a worthwhile improvement.
I'm not totally sure about the value of the use-case you propose here.
Having multiple PDFs and multiple preview images of them in parallal field lists is starting to get hairy. If someone started thinking they needed that architecture, I would much sooner point them towards using either representative nodes each dedicated to one doc and referred to with entityreference, or an array of field_collections each of which represented one file, document name and image preview.
My feel is that overloading what we've got to encourage multiple-to-multiple pdfs-to-images inside one node is more likely to get messy than not. The logic for rebuilding, replacing, deleting or rearranging the elements becomes worse than it already is.
Still, the assumption of $items[0] is lazy code, and I'd be happy to eliminate that with the more robust foreach loop...
Comment #2
uberhacker commentedHey dman, thanks for the feedback. Actually, this patch adds flexibility without changing the functionality. It will still work if you have a field that accepts only one value. My patch simply doesn't assume there is only one value and lets you limit the number of images generated from each pdf.
Comment #3
hitchshockWe stopped supporting the D7 version, so the ticket will be closed, but thanks to everyone who was working on the ticket!