Last modified: 2014-11-20 10:57:11 UTC
Doing preview on [[File:lorem.pdf]] to see if it's displayed as a jpg. Only creates a link to File:lorem.pdf. It isn't displayed there either. Clicking on the generic pdf icon views the pdf. Regular images display, resized to thumbnails etc. $wgMaxShellMemory is 512000. The Pre-requisite packages (gs, convert, pdfinfo and pdftotext) have been specified with full paths in Localsettings.php, or commented out. The original pdf, is about 52k and has no added security. The pdf is in the images folder with the same file permissions and ownership as any of the image files there. I've run both refreshImageMetadata.php -f and rebuildImages.php -f. In debug log is the line "Linker::makeImageLink: File:Polyester_capacitor.pdf does not allow inline display"
Similar to bug 70083 (see bug 70083 comment 5). Rob Kam, can you share the PDF?
Created attachment 16767 [details] Polyester_capacitor.pdf
I've had a look at 70083. showJobs.php gives 0. runjobs.php --type createPdfThumbnailsJob ran okay. gs convert pdfinfo pdftotext all run okay from the command line, although I've not tried any interactively with the pdf.
Sorry ... I think I've found there is a problem with the config - perhaps because of the way the shell is restricted aka jailshell. A newly uploaded png also doesn't get thumbnailed. In php.ini there is: disable_functions = "dl, exec, shell_exec, system, passthru, popen, pclose, proc_nice, proc_get_status, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid"
Image thumbnailing is fixed now but still getting "Linker::makeImageLink: File:Lorem.pdf does not allow inline display".
You normally get "does not allow inline display" if the media handler cannot figure out the size of the image, which probably means that calling pdfinfo fails. Try to enable debug logging ([[mw:Manual:How_to_debug]]) and look for any error reports in the log files (the relevant line should be prefixed with [exec]).
The problem is with the pdf, it's working fine with other pdfs.
Can you test the pdf with the pdfinfo version you have on the server and see if it correctly extracts something like "Page size"?
Created attachment 16771 [details] Another pdf that fails to render.
pdfinfo HRM_OSC_SUB_flowchart.pdf Fontconfig error: Cannot load default config file Title: HRM_OSC_SUB_flowchart.eps Author: Rob Hordijk Creator: CorelDRAW Producer: Acrobat Distiller 5.0.5 (Windows) CreationDate: Mon Jul 7 12:01:54 2014 ModDate: Mon Jul 7 12:01:54 2014 Tagged: no Pages: 1 Encrypted: no Page size: 624 x 356 pts File size: 15450 bytes Optimized: yes PDF version: 1.3
I've done both refreshImageMetadata.php -f and rebuildImages.php -f but the pdf still doesn't display.
*** Bug 72349 has been marked as a duplicate of this bug. ***
Have you tried re-uploading the same file as a new version of the existing one? I've dug up the exact command that PdfHandler runs and it's the following: pdfinfo -enc UTF-8 -l 9999999 -meta Polyester_capacitor.pdf Please run that exact command and post its output for all files that fail. Also, make sure that $wgPdfHandlerDpi is set to a value greater than 0 (I believe the default is 150).
LocalSettings.php now has the line $wgPdfHandlerDpi = '150'; Strangely if I go to the file page and do Upload a new version of this file - using the original file for the upload, it then works, displaying thumbnails etc. However on the file page there is still no thumbnail for the first upload in the file history. #pdfinfo -enc UTF-8 -l 9999999 -meta Polyester_capacitor.pdf Fontconfig error: Cannot load default config file Title: Subject: Keywords: Author: Creator: Producer: Foxit Reader PDF Printer Version 7.0.1.831 CreationDate: Tue Oct 14 17:11:56 2014 ModDate: Tue Oct 14 16:12:07 2014 Tagged: no Pages: 1 Encrypted: no Page 1 size: 803.155 x 346.817 pts File size: 53427 bytes Optimized: no PDF version: 1.7 Metadata: <?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:pdf="http://ns.adobe.com/pdf/1.3/" <dc:creator> <rdf:Seq> <rdf:li></rdf:li> </rdf:Seq> </dc:creator> <dc:title> <rdf:Alt> <rdf:li xml:lang="x-default"></rdf:li> </rdf:Alt> </dc:title> <dc:description> <rdf:Alt> <rdf:li xml:lang="x-default"></rdf:li> </rdf:Alt> </dc:description> <dc:subject> <rdf:Bag> <rdf:li></rdf:li> </rdf:Bag> </dc:subject> <xmp:CreatorTool></xmp:CreatorTool> <pdf:Producer>Foxit Reader PDF Printer Version 7.0.1.831</pdf:Producer> <pdf:Keywords></pdf:Keywords> <xmp:CreateDate>2014-10-14T17:11:56+01:00</xmp:CreateDate> <xmp:ModifyDate>2014-10-14T15:12:07+01:00</xmp:ModifyDate> </rdf:Description> </rdf:RDF> </x:xmpmeta> <?xpacket end="w"?>
I think that the only way to fix the first version is to manually edit the database entry for the file's metadata. Since it was uploaded before you had the shell stuff configured correctly, it probably recorded "0" as the width/height of the page. And now all scripts that you attempt to run on it don't do what they're supposed to because they abort, based on the fact that they don't have any page size information for that file. Alternatively if you don't want to manually tweak the DB, you can probably delete the entire page and reupload the same file in its place. Then you won't have the old broken version anymore.
Thanks for your help. With $wgPdfHandlerDpi = '150'; it's now working fine. I'll delete the old files and re-upload them afresh.
I tried the same (adding $wgPdfHandlerDpi = '150'; to LocalSettings.php, reupload a file). But when delete a file and reupload in Wiki I get a php error [19-Nov-2014 12:53:14 UTC] PHP Warning: COPY /B /Y "C:\WINDOWS \TEMP\localcopy_25bb7e96359f-1.tmp" "d:\MediawikiTestwiki_Images \f\f0\0003_1110_Technische_Dokumentation.pdf" C:\WINDOWS\TEMP\localcopy_25bb7e96359f-1.tmp Zugriff verweigert 0 Datei(en) kopiert. in C:\Inetpub\Www_root\Testwiki\includes\filebackend\FSFileBackend.php on line 282 In my wikis debug txt file there are several hits to that windows path. Here is one sequence while reupload: wfShellExec: "C:\Program Files\xpdf\bin64\pdfinfo.exe" -enc UTF-8 -l 9999999 -meta "C:\WINDOWS\TEMP/localcopy_25bb7e96359f-1.tmp" PdfImage::retrieveMetaData: "C:\Program Files\xpdf\bin64\pdftotext.exe" "C:\WINDOWS\TEMP/localcopy_25bb7e96359f-1.tmp" - wfShellExec: "C:\Program Files\xpdf\bin64\pdftotext.exe" "C:\WINDOWS\TEMP/localcopy_25bb7e96359f-1.tmp" - wfShellExec: "C:\Program Files\xpdf\bin64\pdfinfo.exe" -enc UTF-8 -l 9999999 -meta "C:\WINDOWS\TEMP/localcopy_25bb7e96359f-1.tmp" PdfImage::retrieveMetaData: "C:\Program Files\xpdf\bin64\pdftotext.exe" "C:\WINDOWS\TEMP/localcopy_25bb7e96359f-1.tmp" - wfShellExec: "C:\Program Files\xpdf\bin64\pdftotext.exe" "C:\WINDOWS\TEMP/localcopy_25bb7e96359f-1.tmp" - FSFile::getProps: C:\WINDOWS\TEMP/localcopy_25bb7e96359f-1.tmp loaded, 57638 bytes, application/pdf. UploadBase::verifyExtension: mime type application/pdf matches extension pdf, passing file I cant't remember having some path configured to windows/temp. The file reupload itself worked but there is still no pdf-thumbnail.
Carchaias, sounds like a permission problem. The directory is presumably your system default directory for temporary files. (See [[mw:Manual:$wgTmpDirectory]] for configuring that.) You should verify whether the file exists, is readable, and the copy command works when issued manually.
I'm not convinced this is fixed. $wgPdfHandlerDpi has 150 as its default value (and that default has been added seven years ago), setting that again should have no effect, unless there is some deeper bug preventing the default from being set. Rob Kam, can you grep for anything setting $wgPdfHandlerDpi to a non-default value in your code or configuration files?
LocalSettings.php: require_once "$IP/extensions/PdfHandler/PdfHandler.php"; $wgPdfPostProcessor = $wgImageMagickConvertCommand; // defined via ImageMagick $wgPdfHandlerDpi = '150'; PdfHandler.image.php:65: global $wgPdfHandlerDpi; PdfHandler.image.php:86: $width = intval( trim( $size[0] ) / 72 * $wgPdfHandlerDpi ); PdfHandler.image.php:88: $height = intval( trim( $height[0] ) / 72 * $wgPdfHandlerDpi ); PdfHandler.php:47: $wgPdfHandlerDpi = 150; PdfHandler_body.php:136: global $wgPdfProcessor, $wgPdfPostProcessor, $wgPdfHandlerDpi; PdfHandler_body.php:193: "-r{$wgPdfHandlerDpi}", Nothing in php.ini
And if you remove that line from LocalSettings.php, PDF uploads break again? Also, could you test what happens if you set it as a number and not as a string (that is, $wgPdfHandlerDpi = 150; )?
I think it's not $wgPdfHandlerDpi = '150'; - I've removed that from LocalSettings,php and uploaded a pdf. It's dimensions are then given as 0 × 0 (533 KB), re-uploading the same file gets the same result, but ... ... removing proc_get_status from the disable_functions line in php.ini and it works. With proc_get_status allowed, PdfHandler works for a fresh pdf on its first upload. There was some warning about proc_get_status yesterday so I'd removed that from the disable_functions, which then made it seem that specifying 150 had made it work.
That makes sense, wfShellExec() uses proc_get_status(). Thanks for getting to the bottom of that! If you think a clearer warning would have been useful, I can open a new bug for that. Maybe wfShellExecDisabled() should check for proc_get_status being disabled.
I tested some more. This php error from Comment #17 doesnot come from pdf-handler. It is a problem with all reuploads of deletetd files , also jpg and so on. So take that out.
@Tisza Gergő I've also had a few other problems caused by the disable_functions in php.ini. I've added a note on the extension page to watch out for this.
