Bug #24453


showpic.php causes a fatal error if parameters GET variable is not an array

Added by Helmut Hummel over 13 years ago. Updated almost 12 years ago.

Could have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


After upgrading to TYPO3 version 4.3.9, the URL to the showpic functionality changed (see #24140). Since search engines still may have this old URLs in the index, the call to this URL will lead to a fatal PHP error, since the parameters GET variable is not used there.

Check if the parameters are transmitted and an array.

For trunk it would be a further improvement to replace the die() calls with an exception. For this to work properly the error handler must be initialized. The advantage in doing so is a nicer error message and a 500 http header beeing sent forcing the search engines to (hopefully) not index this URL

For 4.4 I also removed the unnecessary use of the encryption key, which was also introduced in #24140 This will of course also change the hash of the showpic functionality, but using the encryption key there is misleading, so I would change it nevertheless.

(issue imported from #M16891)


16891_4-3.diff (1.26 KB) 16891_4-3.diff Administrator Admin, 2011-01-02 16:15
16891_4-4.diff (1.92 KB) 16891_4-4.diff Administrator Admin, 2011-01-02 16:15
16891_trunk.diff (2.69 KB) 16891_trunk.diff Administrator Admin, 2011-01-02 16:15

Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #24140: Cross-Site Scripting in showpic functionalityClosedMarcus Krause2010-11-19

Related to TYPO3 Core - Bug #26893: BE Log is flooded with "Parameter Error: No file or no parameters given." from showpic.phpClosedChris topher2011-05-18

Related to TYPO3 Core - Bug #39052: Send sane HTTP response in showpic on errorClosed2012-07-18

Actions #1

Updated by Oliver Hader over 13 years ago

But then this issue affects TYPO3 4.3.10, correct?

Actions #2

Updated by Helmut Hummel over 13 years ago


Actions #3

Updated by Stefano Kowalke over 13 years ago

I got also an error with showpic is involved:
Core: Error handler (FE): PHP Warning: implode() [<a href='function.implode'>function.implode</a>]: Argument must be an array in /home/.../typo3_src-4.4.6/typo3/sysext/cms/tslib/showpic.php line 152

Its just a warning I found in "Admin Tools->Log" in 4.4.6

Actions #4

Updated by Philipp Idler over 13 years ago

This warning overfloods my error log too -> 4.4.6

Hope there will be a workaround soon

Actions #5

Updated by Joerg Kummer over 13 years ago

Same Warnings in "Admin Tools->Log" since v4.4.5/6
Only for FE.
All is working fine (Scaling, effects, etc. both in FE & BE). Can't really reproduce it self.
A search in access-log resumes, that only web-robots produce this error, while GET with missing params like '&parameters[n]'. Seems that bot's get links by JS openPic with oldWay style-parameters (&width=..&height=..&bodyTag=), wich doesnt worx, since showpic.php need commited md5-parameters for styling.

Actions #6

Updated by Steffen Ritter over 13 years ago

committed v2

trunk, in rev. 10531
TYPO3_4-5 in rev. 10530
TYPO3_4-4 in rev. 10532

Actions #7

Updated by Felix Nagel about 13 years ago

This still floods my sys log in TYPO3 4.5.3. Any suggestions?

Actions #8

Updated by Felix Nagel over 12 years ago

I was able to get rid of this problem by adding this to my htaccess:

RewriteCond %{QUERY_STRING} eID=tx_cms_showpic
RewriteRule ^ %{REQUEST_URI}? [R=301]

Actions #9

Updated by Dietmar von Schuetz over 12 years ago

The RewriteCond in htaccess lead to disabling the clickenlarge-Feature for pictures in the text, which I need.
The problem still persists in Typo3 4.5.8.

Therefore I had another try with robots.txt:

User-agent: * 
Disallow: /typo3/ 
Disallow: /showpic.php

There are some people working on this problem and sharing experiences in a German forum:

Actions #10

Updated by Sybille Peters over 12 years ago

I think it would be better if this error returned a 404 HTTP status code, as described here: http://www.typo3-nü (page in German, see "Fehler und cms_showpic")

Returning 500 will cause the search engines to assume, that it is a temporary server error.

404 is more clear: the page for this URL was not found / does not exist.

Adding showpic.php to robots.txt will cause the pages to no longer being crawled, but will not necessarily remove it from the index (documentation is a little unclear here, search engines may behave differently).

Actions #11

Updated by Albrecht Köhnlein almost 12 years ago

In my opinion, a Oops, a 404 HTTP status code would be much better than 500. Because it's not a server error, but the URL is malformed and will never return a valid result. So it's a 404.

Actions #12

Updated by Helmut Hummel almost 12 years ago

  • Category deleted (Communication)
  • Target version deleted (-1)

Albrecht Koehnlein wrote:

In my opinion, a Oops, a 404 HTTP status code would be much better than 500. Because it's not a server error, but the URL is malformed and will never return a valid result. So it's a 404.

A solution to that has been merged in all branches until 4.5


Also available in: Atom PDF