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 [1].

Using the Overwrite option

Example:

• Running the script (MS Server 2003) the first time with:

php importimages.php --skip --comment="[[Category:xxxx]]" D:\imagedir

• This imports 60 tiff files and assign them to [[category:xxxx]]
• 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 [[category:yyyy]]:

php importimages.php --overwrite --comment="[[Category:yyyy]]" D:\imagedir

• 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. --[[kgh]] 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 --extensions= parameter, you may want to get a comma-delimited list of all the file extensions in the directory. Here's a script, getAllFileExtensions.php, that will do that:

<?php
// Usage: php getAllFileExtensions.php path/to/files
$number = 0;
$path = '.';
if ( isset ( $argv[1] ) ) {
        $path = $argv[1];
}
$extensions = array();
if ( $handle = opendir ( $path ) ) {
    while (false !== ( $entry = readdir ( $handle ) ) ) {
        if ( $entry != "." && $entry != ".." ) {
             $extensions[] = pathinfo ( $entry, PATHINFO_EXTENSION );
             $number++;
        }
    }
    closedir ( $handle );
}
echo "$number images\n";
$isFirst = true;
$extensions = array_unique ( $extensions );
foreach ( $extensions as $ext ) {
        if ( !$isFirst ) {
                echo ',';
        }
        echo $ext;
        $isFirst = false;
}
echo "\n";

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)

There is a bug in PHP:

Bug #37268 basename() doesnt work with non-latin first letters of the file.

This caused ImportImages.php to fail for me. It can be fixed by changing basename() in ImportImages.inc to mb_basename documented here:

https://bugs.php.net/bug.php?id=37268

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 ImportImages.php. 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/<ImageFileName.extension>".

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. — Preceding unsigned comment added by Joseph.messerschmidt (talk • contribs)

That may happen because the script was being run as root or another user different from the user running apache/PHP. What is strange, though, is that a second attempt fixes the problem --Ciencia Al Poder (talk) 09:18, 1 July 2014 (UTC)

Import one image then stop

When I attempt to run importImages.php one image is imported, then the script quits. The wiki is on a server which I can access over our network. When mapping the network drive (in this case to Y:\) I do not generally have problems with MediaWiki maintenance scripts. Below is the command I ran:

php Y:\wiki\maintenance\importImages.php --conf Y:\wiki\LocalSettings.php C:\wiki\import\images svg png jpg jpeg gif bmp SVG PNG JPG JPEG GIF BMP

After running the script four times I get output like:

C:\wiki\import>php Y:\wiki\maintenance\importImages.php --conf Y:\wiki\LocalSetti
ngs.php C:\wiki\import\images svg png jpg jpeg gif bmp SVG PNG JPG JPEG GIF BMP
Import Images

Image1.jpg exists, skipping
Image2.jpg exists, skipping
Image3.jpg exists, skipping
Importing Image4.jpg...
C:\wiki\import>

The first run of the script imported Image1, the second Image2, and so on. There are 60+ images in the folder, so it should not quit after the fourth.

--Jamesmontalvo3 (talk) 13:27, 1 July 2014 (UTC)

Can't Import the images of my old MediaWiki

Hello ! Here is what I do to import my old images :

php maintenance/importImages.php ./images svg png jpg jpeg gif bmp SVG PNG JPG JPEG GIF BMP.

I did as well

php maintenance/importImages.php ./tmp/images svg png jpg jpeg gif bmp SVG PNG JPG JPEG GIF BMP

Actually, i have 2 servers, on the old one, I copied the folders with all the picture and the tree (images/0, images/1, images/0/00 etc...) but I am not sure that it's like this I have to do :

cd /var/www/mediawiki-1.16.1
scp -rp images/* root@<new-server>:/var/www/mediawiki-1.23/images

But it's not working :

Import Images

wiki.png exists, skipping

Found: 1
Skipped: 1

If I do --search-recursively, it does not change anything. At the end, I do maintenance/update.php.

What's happen please, Ive already managed once but not this time. Haroun al Mouwahid (talk) 12:31, 22 July 2014 (UTC)

In your 2 examples, you don't have the --search-recursively argument. About the folders of the old images, you should delete all thumbnails before importing, otherwise you'll end importing all thumbnails from the old server as new images, something you want to avoid. --Ciencia Al Poder (talk) 13:19, 22 July 2014 (UTC)

Thank you for your response. Of course I have tested with the --search-recursively arguments :) How you deletes the thumbnails ? Haroun al Mouwahid (talk) 15:21, 22 July 2014 (UTC)

Usually with find /path/to/images/ -type d -name thumb -exec rm {} \;. Apart from that, to transfer a wiki from one host to another, you can just export your database (if it's mysql, use mysqldump) and copy all uploads to the new server, no need to export an XML dump and import images using this, since the XML dump won't contain deleted revisions nor user accounts, --Ciencia Al Poder (talk) 16:22, 22 July 2014 (UTC)

Needs to be able to ignore thumb, archive and deleted directories

Hi.

This script is a great step forward in easing maintenance of images.

However, it needs to be able to skip the thumb, archive and deleted folders. Or perhaps an --exclude parameter. It is not convenient to have to delete the thumb directory each time this is run as they then have to be re-created.

Thanks.

SVG are not imported

I just moved a wiki, but importImages did not import svg images, even when I used

php maintenance/importImages.php /path/to/images/directory svg png jpg jpeg gif bmp SVG PNG JPG JPEG GIF BMP

The import only worked when I also added svg as allowed upload file extension in LocalSettings.php. Is this described in the manual? --10:29, 31 March 2016 (UTC)

Strange Error while executing importImages.php

Hey Guys

I get this really strange Error when trying to import Images to my Wiki..

09:00:32 root@server:/wiki$ sudo -u apache php maintenance/importImages.php --overwrite  importimages/

Import Images

ICO_Report_07588.pdf exists, overwriting.../bin/bash: pdfinfo: command not found <br/>
/bin/bash: pdftotext: command not found <br/>
/bin/bash: pdfinfo: command not found <br/>
/bin/bash: pdftotext: command not found <br/>
PHP Notice:  Undefined index: REQUEST_METHOD in /var/www/html/simplesamlphp/lib/SimpleSAML/Auth/Simple.php on line 120 <br/>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
        <meta http-equiv="content-type" content="text/html; charset=utf-8" />
        <title>POST data</title>
</head>
<body onload="document.getElementsByTagName('input')[0].click();">

        <noscript>
                <p><strong>Note:</strong> Since your browser does not support JavaScript, you must press the button below once to proceed.</p>
        </noscript>

        <form method="post" action="https://wiki-in.example.com/IDP/">
        <!-- Need to add this element and call click method, because calling submit()
        on the form causes failed submission if the form has another element with name or id of submit.
        See: https://developer.mozilla.org/en/DOM/form.submit#Specification -->
        <input type="submit" style="display:none;" />
<input type="hidden" name="SAMLRequest" value="PHNhbWxwOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIiBJRD0iXzZlMzA2YjkwOTkxMDk3MTU4NTE2N2Q2NTA3MTFmNTVhMTg1NWFjZGM0ZCINhbWwvc3Avc2FtbDItYWNzLnBocC9pc2NlY293aWtpIiBQcm90b2NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW5nczpIVFRQLVBPU1QiPjxzYW1sOklzc3Vlcj5odHRwczovL3dpa2ktaW4uaXNjZWNvLmFkbWluLmNoL3NpbXBsZXNhbWwvaXNjZWNvd2lraTwvc2FtbDpJc3N1ZXI+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgPGRzOlNpZ25lZEluZm8+PGRzOkNhbm9uaWNhbGl6YXRpb25NZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz4KICAgIDxkczpTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjcnNhLXNoYTEiLz4KICA8ZHM6UmVmZXJlbmNlIFVSST0iI182ZTMwNmI5MDk5MTA5NzE1ODUxNjdkNjUwNzExZjU1YTE4NTVhY2RjNGQiPjxkczpUcmFuc2Zvcm1zPjxkczpUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZW52ZWxvcGVkLXNpZ25==" /><input type="hidden" name="RelayState" value="http://localhost" />
                <noscript>
                        <button type="submit" class="btn">Submit</button>
                </noscript>
        </form>

</body>
</html>

PHP Notice: Uncommitted DB writes (transaction from LocalFile::recordUpload2). in /var/www/html/wiki/includes/db/Database.php on line 4262

Shouldn't it just import those images and not try to execute things in my simpleSAMLphp directory? It worked before, also with those not found commands. when I try a --dry run, everything seems to work just fine.

Thanks

— Preceding unsigned comment added by 193.5.216.100 (talk • contribs)

About the command not found errors, apparently you have Extension:PdfHandler installed or similar. In that extension there's configuration to indicate the path to pdfinfo and pdftotext. If you have them working from the web, maybe you're lacking a defined path for command line mode php.ini. The other about simpleSAMLphp looks like your server has a php extension (not MediaWiki extension) called simpleSAML, which from my understanding, shouldn't be executed from command line scripts. That looks like a server misconfiguration and you should ask about it to your hosting (if they're managing php configuration). --Ciencia Al Poder (talk) 10:28, 15 December 2016 (UTC)

yeah the simpleSAMLphp things shouldn't even be touched by this script, that's what is irritating me. I'm hosting my own server, so I'm the one managing the php configuration. Just activated full debug log of php, but with no big effect. And this "Since your browser does not support JavaScript, you must press the button below once to proceed"-thing, I sarched for a file containing this text, but I can't find anything. So how should i configure php?

I have no idea how simpleSAMLphp works, but it looks like it's installed somewhere as a php module, so it's basically executing on every php script. The generated HTML may very well be embedded inside some binary of that module. I'd guess it's configured somewhere in the php.ini --Ciencia Al Poder (talk) 20:42, 15 December 2016 (UTC)

So i was able to locate the Error, just had to disable the Extension:SimpleSamlAuth Extension, because each time I wanted to execute a php script for mediawiki, the extension tried to authenticate. But as it works now, it leads me to another question: How do I import the images without overwriting the User to "Maintenance Script" and the Description to "importing File"? I don't want to loose this information from the old wiki (I'm migrating to a new server and recent version) Edit: So I was able to find a Workaround for my stated problem. I posted it on Stack Overflow Forums.

Is it possible to use this script to import mp3 audio files?

I tried importing a folder of mp3 audio files but all I get in return is this message: "No suitable files could be found for import." Appreciate any tips or guidance on this! HausaDictionary (talk) 12:56, 11 February 2017 (UTC)

Were mp3 files whitelisted in $wgFileExtensions? --Ciencia Al Poder (talk) 11:41, 12 February 2017 (UTC)

Max size

Can I upload with this script images that size 10 mb (on my wiki max size is 2 mb)?

Overwriting...failed. (at recordUpload stage)

I uploaded a large number of images, but they got stuck in moderation and were a pain to indivudally approve, so I disabled the moderation extension and tried to re-upload using ImportImages.php, using the "--overwrite" option. But each image upload failed, with the following message: a5dff9dc4fa626c434649fbd7f3eff5c-d.jpg exists, overwriting...failed. (at recordUpload stage). Not a big problem, but thought I'd share it and find out if anyone knows of a solution. Thanks

--Postprefix (talk) 01:55, 7 June 2019 (UTC)

simplify image import

Hi,

I use the mediawiki as a knowledge base within my IT department. Several users remind me of the "heaviness" of the image import process, with the need to put a name, a description before finally being able to use the media. The objective will be to import, whith simple copy pasted, images in the wiki. It is then the Wiki directly which will put a random import name. Is this possible or is it planned to make a move in this direction?

thank you

Patrice ROUX

You may try Extension:MsUpload --Ciencia Al Poder (talk) 10:32, 25 February 2020 (UTC)

overwriting...failed. (at recordUpload stage)

Since updating to MW 1.33, using the --overwrite option does not seem to work anymore. I get the error overwriting...failed. (at recordUpload stage). Prior to the update (we were on 1.29), this error did not occur.

In my debug log I get this error LocalFile::recordUpload2: File 2/2c/file.PNG already exists! every time the upload fails. This debug error is thrown in LocalFile->recordUpload2 by this conditional: $row && $row->img_sha1 === $this->sha1. It appears that the overwrite flag is not accounted for here. Perhaps this is a bug?

Any suggestions would be greatly appreciated. We are currently using a workaround where we wipe out all files first and then re-import. — Preceding unsigned comment added by Dstoeltz (talk • contribs)

If you're really wiping all files first, you may want to truncate the image table as well, --Ciencia Al Poder (talk) 22:15, 1 March 2020 (UTC)

Description of "license" parameter

The description of the "license" parameter could be clarified to indicate that it expects the name of a template, rather than "code" since the script effectively surrounds whatever is passed to it with double braces.

--Ahmad Gharbeia أحمد غربية (talk) 09:38, 1 April 2020 (UTC)

Error running in MW 1.39 & SMW 4.0.2

PHP Deprecated:  Use of PersonalUrls hook was deprecated in MediaWiki 1.39. [Called from SMW\MediaWiki\Hooks::register in /home/XXX/public_html/extensions/SemanticMediaWiki/src/MediaWiki/Hooks.php at line 151] in /home/XXX/public_html/includes/debug/MWDebug.php on line 381

Importing Files

No suitable files could be found for import.

Does it means that this script required a lower version of PHP 7.4  ?

I am running with PHP 7.4.32 Lotusccong (talk) 10:17, 8 December 2022 (UTC)