[TYPO3-dev] Solution for bug 12341 (graphics magic fails when using safe_mode) introduced new bug

Florian Schaeffer florian.schaeffer at mercoline.de
Mon Jan 18 12:48:25 CET 2010


Hello all,

today I upgraded from 4.3.0 to 4.3.1 and cleared all caches as usual. 
Short after that some coworkers reported missing thumbnail pictures when 
creating a filelist of PDF files in the frontend.

I first thought of that mentioned bug #12341 but as we're not using 
safe_mode I thought of something different. After debugging the whole 
process I then looked into the changesets of revision 6722 where this 
bug was fixed.

In line 2664 the old command was:
$cmd = t3lib_div::imageMagickCommand('convert', $params.' 
'.$this->wrapFileName($input).' '.$this->wrapFileName($output));

This has been replaced by
2665 $frame = $frame ? '['.intval($frame).']' : '';
2666 $cmd = t3lib_div::imageMagickCommand('convert', $params.' 
'.$this->wrapFileName($input).$frame.' '.$this->wrapFileName($output));

So in line 2665 $frame can be reset completely. This leads to an 
infinitly computing gm process as the [0] is missing for PDF files (at 
least on our server). When using the generated gm command on the shell 
for every page of the PDF file a thumbnail is created tempxxxxx.jpg.0 
xxxx.jpg.1 and so on but the given filename without any page-number is 
never generated and thus not shown...

I replaced line 2665 by
$frame = $this->noFramePrepended?'':'['.intval($frame).']';

This is the same $frame-rule as for the imageMagiskIdentify-function.

Now all my PDF files are parsed again and the previews are shown.
If somebody configures his installation to use noFramePrepended will 
this lead to an error when using gm ?

Can anybody confirm and point me to the correct solution?

Greets
Florian Schaeffer




More information about the TYPO3-dev mailing list