Similar to bug 70083 (see bug 70083 comment 5).

Rob Kam, can you share the PDF?

Created attachment 16767
Polyester_capacitor.pdf

Attached:

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
Another pdf that fails to render.

Attached:

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.

Hello,

I have the same problem with the thumbnail creation of pdf-files caused by the 0x0-bug since mediawiki 1.23

I read the thread and tried the solution.
My disable_function in php.ini was and is still empty.

And I get the followings error in my error.log from apache when I upload a pdf:
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.
Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.

in english
--> The filename, directory name or volume label syntax is incorrect.

When I run "php rebuildImages.php" I get the same messages on cmd output.

FLX90: that seems like a misconfigured file path.

I thought that too, but I've no errors in my debug.log
I also have no error when I type the wfShellExec-Commands on cmd.
pdfinfo, pdftotext, convert,... those programs are all assigned in the PATH-Variable from windows.
So global reachable...

UploadBase::createFromRequest: class name: UploadFromFile
FSFile::getProps: Getting file info for C:\xampp\tmp\phpDD33.tmp
MimeMagic::__construct: loading mime types from C:\xampp\htdocs\mediawiki/includes/mime.types
MimeMagic::__construct: loading mime info from C:\xampp\htdocs\mediawiki/includes/mime.info
MimeMagic::doGuessMimeType: analyzing head and tail of C:\xampp\tmp\phpDD33.tmp for magic numbers.
MimeMagic::doGuessMimeType: magic header in C:\xampp\tmp\phpDD33.tmp recognized as application/pdf
MimeMagic::guessMimeType: guessed mime type of C:\xampp\tmp\phpDD33.tmp: application/pdf
MimeMagic::improveTypeFromExtension: improved mime type for .pdf: application/pdf
wfShellExec: "pdfinfo" -enc UTF-8  -l 9999999  -meta "C:\xampp\tmp\phpDD33.tmp"
PdfImage::retrieveMetaData: "pdftotext" "C:\xampp\tmp\phpDD33.tmp" - 
wfShellExec: "pdftotext" "C:\xampp\tmp\phpDD33.tmp" - 
wfShellExec: "pdfinfo" -enc UTF-8  -l 9999999  -meta "C:\xampp\tmp\phpDD33.tmp"
PdfImage::retrieveMetaData: "pdftotext" "C:\xampp\tmp\phpDD33.tmp" - 
wfShellExec: "pdftotext" "C:\xampp\tmp\phpDD33.tmp" - 
FSFile::getProps: C:\xampp\tmp\phpDD33.tmp loaded, 1007917 bytes, application/pdf.

The error message is apparently for paths with spaces or non-standard characters in them; maybe that helps narrowing it down. It might not be related to PDF uploading at all.

At any rate, if you don't see the "does not allow inline display" message in your debug log, yours is a different bug or configuration issue, and could be better discussed in a separate ticket.

Unfortunately I've also this message in my debug.log:

Linker::makeImageLink: Datei:Nochsonsohntest.pdf does not allow inline display