Closed (won't fix)
Project:
PDF to ImageField
Version:
7.x-2.x-dev
Component:
Code
Priority:
Critical
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
25 Jan 2012 at 13:32 UTC
Updated:
10 Sep 2013 at 15:53 UTC
I have fully rewrite current 6.x version (yes, really 99% of the code rewrote)
so this is not a port to Drupal 7 but new module :)
btw, some new features are available in my module (such as option to hide target image field, pdf view formatter).
Also I have changed logic for count pages in pdf files for perfomance reasons.
Everyone can find and download working module in my sandbox:
http://drupal.org/sandbox/InternetDevels.com/1415404
Also I prepare example site:
http://demos.internetdevels.com/pdf-to-image/
Comments
Comment #1
dman commentedWow great. good work.
I'm happy to merge this in and add you as a D7 maintainer here. I'll look at sorting out the git branch and deprecate my partial earlier attempt.
Basically, it looks like this is a great step forward. Code is really well put together.
On testing, I'm getting a number of "Call-time pass-by-reference has been deprecated in drupal_load() (line 1105 of /Library/WebServer/Documents/drupal7/includes/bootstrap.inc)." warnings - because I run with PHP strict on. so we can clean that up.
I'm not fully thrilled with the change from the way we used to re-use file_field by just extending the core file type with a new renderer to this method of creating an entirely new field type. There's a few arguments against it.
The basic one is that the most common use-case will be that someone has been building a site, had a load of files (probably mixed Doc and PDF) attached to pages and sorted everything out like their views and displays - and THEN wants to add the thumbnail feature by adding this module. With this rewrite, that would be impossible. Converting between field *types* as a whole lot more impossible than just changing a renderer or an upload behavior.
We shouldn't have to declare our own pdf_to_image_field_schema() if we can piggy-back on the core one that does the same thing. Also, there is any number of as-yet-unknown other modules that may do things with fieldfields that would not be able to operate on our new type, but if our type was a "subclass" or special case of filefield, that will be managed for us and be future proof. So that's a pretty big deal for the future. We should be compatible with every other assumption folk make about files, not build our own alternative.
Small testing issue: as filefield is not listed as a dependency (but this version DOES try to re-use some of its features) then a basic (bare, not default) install threw me an error
... which is easy to work around by enabling filefield now ... but exposes the interdependence that still exists.
Hm, it also depends on core image.module.
No surprises there, but I'm seeing it because I'm testing from a clean site.
And, with those dependencies sorted out ... hm. not working for me yet.
I Do really like the idea of adding 'PDF view' as an embedded option. The UI options for that renderer are good two. Very clever.
Doesn't actually work for me, but I like what it's trying to do.
I found the "Hide target image field" on by default a little disconcerting. No preview, no ability to replace it with your own version. But after inspecting the code I found I could toggle it off ... no that's pretty helpful. I'd probably prefer it visible (as expected) at first, with the option to turn it off.
Just describing how a first time user could get stumped here.
So far I've been unable to get it to actually do the convert. The batch doesn't seem to fire. May be a settings thing.
... minor debugging tells me that pdf_to_image_count_pages() was returning 0 on my sample docs.
so there are some niggles.
... Yeah, on my vanilla install, the imagemagick 'Path to the "convert" binary' needed configuring. But this module was silently failing instead of saying "hey, imagemagick don't work". The old version used to self-test itself and raise warnings I think. As installing dependencies is a really big thing for this module, I'd like to help folk with that as much as possible by alerting them to problems.
Well YAY!
After those first half-dozen small (sorta solvable) issues, It's working for me in D7.
!!
I'll look at getting the git branch sorted.
Comment #2
dman commentedExpert git advice needed : how can I merge a sandbox project into an already-existing full project (as a new branch)?
Previous d7 port issue (for cross-reference)
Comment #3
dman commentedInternetDevels.Com, I've added you as a maintainer to the project.
I think it should work - let me know if you get the correct "version control" information at
http://drupal.org/project/pdf_to_imagefield/git-instructions
You should see your username in the "Setting up this repository" command sample, eg
not just
if it's ready for you. I think.
Comment #4
dman commentedI think I got the git merge sorted out.
The advantage is that the git history (from your repo) is getting correctly attributed (yay) which would not have happened if I'd done it the easy way.
New 7.x-2.x branch is http://drupal.org/node/1417190
Comment #5
cossimo commentedSubscribe
Comment #6
moss.dev commentedHi dman,
I have been trying to get this D7 version working after seeing at the end of your post "After those first half-dozen small (sorta solvable) issues, It's working for me in D7".
I tired running through all the usual bugs and have been looking in to the module, at one point it was firing the convert (progress bar popped up on a new page) but ImageMagick was not creating images. Got that sorted but now it's stopped trying to convert again.
So I read back through your post again and I see "So far I've been unable to get it to actually do the convert" above the line saying you had managed to get it working.
Can you please let me know if you did get this working and if so what I might need to look out for, once I work out where the problem is I will try and fix it once and for all but I am really struggling just to see at what point it fails to fire.
Thank for any advice.
Jon
Comment #7
moss.dev commentedComment #8
dman commentedFrankly, I'm personally having trouble with the new contributed rewrite,
Yes, I was able to get it working without changes, but the 7.x-2.x-dev branch I brought in is *not* IMO the greatest way froward.
The way it creates a new TYPE of file upload rather than enhancing existing ones is not sustainable or helpful for *existing* sites.
I've been trying to work both upgrades into a solution that gives us the best of both worlds, but it required some gymnastics within D7 file manipulation.
Short story for you - yeah the 7.x-2.x-dev can be made to work without changes today, but I think it's a dead end in D7 file management.
I've got a pdf_to_image 3.x merge in the wings to bring the different options together ... I'll try to push/release that sometime.
Comment #9
dman commented