Manual talk:ImportImages.php

Parse error: syntax error, unexpected T_STRING in
When I try to do the command, the shell returns the error: "Parse error: syntax error, unexpected T_STRING in [mysite]/maintenance/importImages.php on line 36". I looked at the php file, and line 36 is "if( !$user instanceof User )". My PHP knowledge is scanty, so I don't know what's going on or how to fix it. Also, I don't understand the rest of the examples on this page. Can I just do the command under invocation ("php maintenance/importImages.php /path/ filetype"), or are all the other things commands I also need to do? And if I do, which things do I need to replace with my own information? Faithx5 16:00, 11 April 2008 (UTC)
 * Never mind. I was able to use Extension:SpecialUploadLocal to do what I need to do. Faithx5 16:17, 11 April 2008 (UTC)
 * I had the same error, until I realised I only had the php4 command line interface installed (but the webserver was running php5). I upgraded to php5-cli and it worked fine. 210.11.75.201 00:09, 20 May 2010 (UTC)

My wiki can't find the images uploaded
This script works in that it inserts the images into the right folder structure (under images/x/y etc), but there still seems to be something wrong. My wiki can't find the images uploaded and instead asks me if I would like to upload the image. I can browse to the image and when I try to reupload it says the files already exists! I looked at the other image scripts (e.g., cleanupImages.php) but nothing seems to reinsert the image filesnames into the appropriate tables. Help!
 * Run

php rebuildImages.php --missing


 * It seems that this error appears only in the 1.16.0 version. 140.94.82.30 13:53, 7 October 2010 (UTC)

I have the same problem. The files are in your folders, appear on "recent changes" and "rebuildImages --missing" not solve the problem. Tested in 1.16.0, 1.16.5 and 1.17.0 with the same result. --95.19.200.80 08:54, 25 November 2011 (UTC)

I had the same problem in 1.19, but fixed it by rebooting apache ;) Hope this helps! --69.246.185.35 18:16, 7 June 2013 (UTC)


 * Well, that shouldn't happen. Maybe it's a cache problem: When you see the page that included the image, it was displaying it as it were before you uploaded the image. Rebooting the http server shouldn't be necessary. Sometimes it requires you to Purge the page, but it shouldn't be necessary at all, unless the cached version of the page is being served directly by your browser instead of the server, in which case a CTRL+F5/CTRL+R should solve that. --Ciencia Al Poder (talk) 10:16, 9 June 2013 (UTC)

Long File Names
There appears to be a bug (feature?) where long file names get compressed down by truncating the name by removing letters from the middle of the name. So the name of the new file on the wiki is different from the original file. Is there a hard limit coded in the extension somewhere? Or is it perhaps a limit in PHP? --Tlosk 20:25, 17 October 2010 (UTC) For example: File:Greater Celdon Shadow Armor (Blue Shadow Dye) Live.jpg becomes: File:Greater Celdon Shadow ArmBlue Shadow Dye) Live.jpg

failed
t@f66677:~/public_html/dead.com/public/w/maintenance$ php importImages.php /home/t/public_html/m gif bmp PNG JPG GIF BMP Import Images

Importing dead2 mods royal plaza z04_cr1_05_big missing (3).png...failed. Importing dead2 mods royal plaza ITC files missing.png...failed. Importing dead2 mods royal plaza exit sign z04_cr1_19_big missing.png...failed. Importing dead2 mods royal plaza z04_cr1_05_big missing (4).png...failed. Importing dead2 mods royal plaza z04_cr1 all 10 missing.png...failed. Importing dead2 mods royal plaza exit sign z04_cr1_19_big present.png... failed. Importing dead2 mods royal plaza z04_cr1_05_big missing (2).png...failed. Importing dead2 mods royal plaza ITC files missing (4).png...failed. Importing dead2 mods royal plaza z04_cr1 all 10 missing (2).png...failed. Importing dead2 mods royal plaza z04_cr1 all 10 missing (3).png...failed. Importing dead2 mods royal plaza ITC files missing (3).png...failed. Importing dead2 mods royal plaza z04_cr1_05_big missing.png...failed. Found: 13 Failed: 13 t@f66677:~/public_html/dead.com/public/w/maintenance$

Hmmm... it worked yesterday. Adamtheclown 02:55, 21 December 2010 (UTC)


 * Same here. Is there any solution? A "verbose"-switch would be very useful. --85.181.38.134 12:14, 9 January 2011 (UTC)

I encounterd this problem on Ubuntu,just add "sudo" when executing.

"Upload failed error" - not necessary to chmod?
I had no images/temp file to chmod, and my images/thumbs and images/archive files didn't even belong to me, for some reason. Out of desperation, I simply went on to the next step: changing my LocalSettings.php file as prescribed. Then everything worked like a charm. Hm. 218.44.38.86 15:40, 29 December 2010 (UTC)

Incompatible with Extension:Advanced Meta
This module is incompatible with Extension:Advanced Meta. The error I get is.

Using the Overwrite option
Example: php importimages.php --skip --comment="" D:\imagedir php importimages.php --overwrite --comment="" D:\imagedir
 * Running the script (MS Server 2003) the first time with:
 * This imports 60 tiff files and assign them to  
 * The user discovers that the initial category given in the comment option is false.
 * The user does not want to manually change all the categories in the tiff files so he uses the script again with the overwrite option and the correct  :
 * After this the 60 tiff files are overwritten but the new category is not assigned to the file but only shown in the comment field.

Result is that you need to manually assign the correct category to the tiff files. Bug?

Jongfeli 13:19, 17 November 2011 (UTC)


 * That's not a bug, since on a normal upload from the web interface the file description page is never overwritten. Try Manual:edit.php instead. --Ciencia Al Poder (talk) 13:00, 1 September 2012 (UTC)

-- comment-ext
This feature might be buggy. See here. Taken from the manual page. --&#91;&#91;kgh&#93;&#93; 21:37, 30 January 2012 (UTC)


 * That "bug" was closed by the reporter since it was a local issue with another extension. --Ciencia Al Poder (talk) 13:01, 1 September 2012 (UTC)

Get all file extensions in a directory
For the  parameter, you may want to get a comma-delimited list of all the file extensions in the directory. Here's a script,, that will do that: Leucosticte (talk) 02:03, 15 October 2012 (UTC)

Letter Ä Ö Ü ß don't work
Hey, I have a problem. I import 1144 images, but my wiki has 1317 pictures. All pictures with ä ö ü or ß in the filename could not import. What can i do ? 89.13.118.114 13:53, 21 March 2013 (UTC)


 * Which system? If you mediawiki is installed under Linux it may be a mismatch between the original file encoding and the file encoding of the linux system (e.g. linux set to UTF-8, but filenames under ANSI, or reverse. Try reviewing the file name encoding with other tools (console, file browser) first. I can confirm that mediawiki imports accented characters, japanese, chinese etc. filenames if properly unicode encoded. --G.Hagedorn (talk) 19:46, 21 March 2013 (UTC)

Bug and documentation problems with summary and comment
An undocumented option "--summary" is used to initialize the variable $summary. It should be documented.

When --comment-ext is used, and --summary is not used, the variable $summary is set to the text for the first file uploaded (for example, the text for "1.png" comes from "1.txt"), and then continues to have the same value for all subsequent files uploaded (for example, the text for "2.png" also comes from "1.txt"). This appears to be a bug since the text for the first file may be inappropriate for the other files. The code in question is:

$commentText = SpecialUpload::getInitialPageText( $commentText, $license ); if ( !$summary ) { $summary = $commentText; }

The bug might be solved by initializing a new variable $summaryIsCommentText = false before the loop, then changing the above code to:

$commentText = SpecialUpload::getInitialPageText( $commentText, $license ); if ( !$summary || $summaryIsCommentText ) { $summary = $commentText; $summaryIsCommentText = true; }

However, the names of the variables and options ideally should be changed. The documentation and source code comments mention (1) "comment", (2) "upload comment", and (3) "upload summary comment". The documentation should explain if these are all the same thing, or two or three different things, and how they are related to the "--summary", "--comment", and other options.

If I'm not mistaken, there are actually two text items associated with each image file uploaded. The first text item is the text of the page named, for example, "File:foo.png", which is displayed beneath the image when you click on the image. (It can be edited if you click on the Edit tab for the page.) The second text item is a comment displayed further down on the same page, below the heading "File history"; one "File history" comment is associated with each version of the file that is uploaded. The word "comment" is used ambiguously for both of these items.

Part of the confusion is that the names of arguments to the function recordUpload2 don't match the names of the variables passed to that function; $summary becomes $comment, while $commentText becomes $pageText.

It would be better never to use the word "comment" to refer to the text of the "File:..." page. It should be reserved for the item that is actually labeled "comment" under "File history". For the page text, the name "page text" or "image description page text" would be clearer and more consistent. It's not clear why the word "summary" should be used at all; it seems to have been used instead of "comment" because "comment" had been inappropriately used instead of "page text".

Import previously deleted files
It seems that it is not possible to upload a previously deleted file to your wiki with. It will report success but only the page in the File: NS is created but the actual file is not uploaded. Entered a bug report for this. Regards --Jongfeli (talk) 07:36, 13 November 2013 (UTC)

First new revision for uploaded images causes error and missing file
After running the maintenance script successfully (MW 1.19.4), my users now report that trying to upload a new revision of one of these images causes this error:

Could not store file "/php_tmpdir/phpOurtUz" at "mwstore://local-backend/local-public/8/8b/".

This causes a new revision of the image to be created with no image data or filename, just the path to the containing directory (/images/8/8b/).

This only seems to occur once, attempting to update the image a 2nd time works correctly.