Show only the first file and up to max

Just add the below to multiupload.js and you are ready to go.

// should probably be in i18n
wgAddMoreName = 'Add next file'; // en
//wgAddMoreName = 'Dodaj następny plik'; // pl
/**
 * Enable showing one file at first and add more
 *
 * This will hide all files input but the first one
 * and will add an add more button.
 *
 * @note $wgMaxUploadFiles param sets maximum number of files uploaded at once
 */
function wgUploadHideSetup() {
	var eRows;
	try {
		eRows = document.getElementById( 'mw-htmlform-source' ).getElementsByTagName('tr');
	} catch (e) {
		return;
	}
	if( eRows ) {
		//
		// get rows array
		//
		var arrRows = new Array();
		var iLastRow;
		var oRow = new Object();
		for (var i=0; i<eRows.length; i++) {
			var e = eRows[i];
			if (e.className.search(/(^| )mw-htmlform-field-UploadSourceField( |$)/)>=0) {
				oRow.rIn = e;
				iLastRow = i;
			} else if (e.className.search(/(^| )mw-htmlform-field-HTMLTextField( |$)/)>=0) {
				oRow.rOut = e;
				iLastRow = i;
				arrRows.push(oRow);
				oRow = new Object();
			}
		}
		
		if (arrRows.length <= 0)
		{
			if (typeof(console) != 'undefined' && typeof(console.log) == 'function')
			{
				console.log ('wgUploadHideSetup: no form fields found - class name changed?');
			}
			return;
		}
		
		//
		// hide all but first
		//
		var strRowNormalDisplay = arrRows[0].rIn.style.display;
		for (var i=1; i<arrRows.length; i++) {
			arrRows[i].rIn.style.display = 'none';
			arrRows[i].rOut.style.display = 'none';
		}
		
		//
		// add button
		//
		// cells
		var nel = document.createElement('tr');
		var nelTd = document.createElement('td');
		nel.appendChild(nelTd);
		nelTd = document.createElement('td');
		nel.appendChild(nelTd);
		// the button
		var nelInp = document.createElement('input');
		nelInp.setAttribute('type', 'button');
		var lastVisible = 0;
		nelInp.onclick = function () {
			if (lastVisible<arrRows.length-1) {
				lastVisible++;
				arrRows[lastVisible].rIn.style.display = strRowNormalDisplay;
				arrRows[lastVisible].rOut.style.display = strRowNormalDisplay;
			}
			if (lastVisible>=arrRows.length-1) {
				this.style.display = 'none';
			}
		}
		nelInp.value = wgAddMoreName;
		nelTd.appendChild(nelInp);
		if (iLastRow == eRows.length-1) {
			eRows[iLastRow].parentNode.appendChild(nel);
		} else {
			eRows[iLastRow+1].parentNode.insertBefore(nel, eRows[iLastRow+1]);
		}
	}
}
addOnloadHook( wgUploadHideSetup );

Regards, --Nux 15:00, 19 January 2011 (UTC) 05:46, 23 August 2011 (UTC)

Just edited (added the hide-setup function behind the normal setup) multiupload.js but did not affected anything. I still have my maxupload fields (I use default which is 5- therfore not explicit value in wgMaxUpload in LocalSettings).

I wanted to try that to see if i can get rid of the warnings in case you only upload one and not the max number allowed.

Is adding the function to multiupload.js the really the only thing to do? AW 09:28, 28 November 2011 (UTC)

I must be missing something here. I appended the above code to the end of the .js but I didn't see what apparently is working... am I supposed to search and replace? Or is there a specific line it should be inserted at? Teststudent 21:08, 11 December 2011 (UTC)

Fixed above. As seems HTML changed. And yes - you just paste the code at the end of "multiupload.js" (this is AFTER `addOnloadHook( wgUploadSetup );`). --Nux 20:19, 14 December 2011 (UTC) 20:19, 14 December 2011 (UTC)

Excellent, it works! Thx. Teststudent 03:44, 23 December 2011 (UTC)

Bug: Name uniqueness is not checked for uploaded files

The problem occurs when a user tries to upload multiple files and mistakenly adds one file twice. Then you get a warning that the file already exist, but after uploading other files. Then weird thing happen and notices/warning are thrown at you (if you happen to have notices on in PHP config). Looks like a bug. --Nux 15:00, 19 January 2011 (UTC) 05:47, 23 August 2011 (UTC)

May this extension MultiUpload from other URL?

I think it's easy, just need to add more URL upload bar.

May be you need to find whether the system use URL upload. ---晒太阳的冰 12:37, 9 May 2011 (UTC) 05:48, 23 August 2011 (UTC)

I want bulkupload image by URL too. 116.77.140.61 12:11, 9 October 2011 (UTC)

Images only!

I am trying to import files other than images (pdf, for example). This extension places everything in /images by default.

1) How can I place files in somewhere else?

2) How can I properly link to non-image files? (PDF, etc). Use Media:filename.ext MKRD info 20:02, 8 October 2011 (UTC)

This is not the problem if this extension. See File_upload#Configuring file types and other sections on that help page. --Nux 20:35, 8 October 2011 (UTC)

Impossible and epic fail of ancient versions when only images were expected to be uploaded. See Manual:Image Administration. Previously even the namespace was reading "Image:Filename.pdf"... but changing the directory name seems impossible, otherwise it would have happened alrerady. Subfader 02:45, 9 October 2011 (UTC)

Not quite true - you can change the folder: Manual:$wgUploadDirectory. If something won't work for you after changing this (I'm guessing this might happen if you don't start from scratch) then I guess you can create a junction to the old (original) name. Nux 08:05, 9 October 2011 (UTC)

Select more than one image at a time

Hi there! MultiUpload is the best upload extension I could find. There is only one thing that I could be improved.... Sometimes I have to upload 40-60 pictures at the same time. Then I have to select them one by one. This is very time consuming. I found this other extension, called Uploadify. It seems like the extension had this feature but it is not working anymore. Is it possible to add this feature to MultiUpload? Thanks for your answers in advance! C.eiermann 05:21, 27 December 2011 (UTC)

You're right, it's a pity that no adequate solution has been found for what seems like a basic need for many users. For similar functionality, there is Extension:SpecialMultiUploadViaZip, but it was last updated in 2007, so not very likely to work with current versions of MW (correct me if I'm wrong though). I don't know about Extension:UploadWizard, which requires ImageMagick and I don't have shell access to install it. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 12:03, 27 December 2011 (UTC)

Extension:UploadWizard can do that meanwhile. I just checked it on the example website. Looks good. Subfader 13:21, 28 December 2011 (UTC)

Even if this thread is almost 3 years old I just wanted to let you know that I am now using UploadLocal.

I upload all the files to my FTP and then import them with one click. Not suitable for a wiki with many users since you don't want to give everyone access to your FTP but for my needs it is perfect. C.eiermann (talk) 10:13, 31 July 2014 (UTC)

Does not work with 1.18

I have not been able to get this to work with 1.18. No matter how many files I upload, the last one always returns an error that the file is empty (see screenshot). All the files are successfully uploaded and usable, so it seems that a bad result is just being passed somewhere.

Jlemley 17:47, 25 January 2012 (UTC)

Nothing new there. The error message also occurred with MW 1.17 and possibly MW 1.16 as well. You can simply ignore it I think. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 08:28, 26 January 2012 (UTC)

I've been using this extension successfully with 1.16.5 with no problem. I'm looking to update to 1.18 - I have all the other extensions we use updated and functioning, but not this one.

Yes, the error could be ignored, but it's horribly unprofessional to appear in a corporate document repository. I'm sure I could hack a way to suppress it, but I would rather find a solution that allows the features of MediaWiki to keep working when uploading files. Jlemley 03:42, 29 January 2012 (UTC)

You're absolutely right, of course, and there's some more room for improvement. Unfortunately, User:Tderouin (the creator of this extension) hasn't shown up to comment on this page. In fact, unless someone is prepared to take over from him, the extension does not appear to be maintained any longer. I don't know why so many useful extensions are being neglected by the developing community lately, but maybe slapping an Unmaintained tag could help to ignite some interest. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 16:37, 29 January 2012 (UTC)

Good idea. Sometimes it might be a good idea too to contact the coder directly. Cheers [[kgh]] 16:41, 29 January 2012 (UTC)

Cavila, this might be due to the fact of creating ResourceLoader in 1.17 which supposed to make JavaScript developing easier and it only made it much complicated or even impossible or at least impractical in some use cases (see Bug 27488).

I'm using this extension and I could probably fix it for new versions of MediaWiki but I simply cannot upgrade to the latest version. Nux (talk) 10:39, 4 March 2012 (UTC)

Yeah, this "The file you uploaded seems to be empty." bug is still happening in MediaWiki 1.19.0. If I knew any PHP I would try to fix it. Maybe I'll poke around. 173.13.177.204 20:02, 18 May 2012 (UTC)

MW 1.19: PHP Fatal Error

Extension (trunk) seems to broken with MW 1.19. Get a PHP Fatal Error if I call the special page:

PHP Fatal error: Call to a member function getValues() on a non-object in /var/www/mediawiki/extensions/MultiUpload/MultiUpload.body.php on line 56, referer: http://[...] Singlespeedfahrer (talk) 11:06, 9 April 2012 (UTC)

Try to modify the function in MultiUpload.body.php.

Original:

protected function loadRequest( $request ) {

global $wgUser, $wgMaxUploadFiles;

Modified:

protected function loadRequest() {

global $wgUser, $wgMaxUploadFiles;

$request = $this->getRequest(); Ericyu (talk) 08:25, 8 May 2012 (UTC)

FYI, the fix above seems to work on my MediaWiki 1.19.0 install. Still some other minor bugs, but that was the big one. 173.13.177.204 20:11, 18 May 2012 (UTC)

Missing UI text running under 1.19.0

Using MW 1.19.0 but the 1.18 version of the extension, seeing <-source> and <-description> on the Special:MultipleUpload page. What am I missing? --173.13.177.204 173.13.177.204 19:45, 18 May 2012 (UTC)

MW 1.19.1: transform() PHP Fatal Error

Extension seems to broken with MW 1.19. Get a PHP Fatal Error if I call the special page:

Fatal error: Call to a member function transform() on a non-object in /home/tnbzpdrr/public_html/wiki/includes/specials/SpecialListfiles.php on line 198 190.85.146.218 20:34, 23 July 2012 (UTC)

MW 1.19 Compatibility

This extension is compatible with MW 1.19. But a small error may be present if you are using other extensions that also work with uploading or U/I variables.

One such case

Warning: Missing argument 1 for MultipleUpload::loadRequest(),

needed a removal of an unclosed bracket in the

/includes/specials/SpecialUpload.php on line 159; 

the argument was not defined. A quick suggestion to resolve;

Remove argument.

In the event it states another type of missing object(s); locate each object via its error path and manual check to see if the argument is needed. If not;

Remove argument.

A review of this issue is being proposed and a candidacy for 1.20 inclusion will be sought in the case. Habatchii (talk) 15:07, 30 July 2012 (UTC)

MW 1.19 Compatibility Update (Reiteration)

Reiteration!!!

This extension DOES HAVE SEVERE MEDIA RELATED VULNERABILITIES and is advise against installing unto your hard drive.

Problems: This extension has a HIGH LEVEL VULNERABILITY(HLV) to parser based attacks and a high propensity to become susceptible to HTTP/Directory events and server-related incidents. Probable causes that may contribute to these errors would be heavy media loads or other upload content already on the server. Various MW 1.19 directory files, especially maintenance files such as HipHop have been known to cause extensive server related incompatibility issues.

Another possible approach in recognizing the problems may be in the GIT repository, whereby older extensions (possibly over 90%) of the GIT populated files may have compatibility issues due to maintenance updates. The repository hosts multiple types of files for download (zip, 7z, tar, etc.) from which possible vulnerability attacks may be instigated. Accordingly, a growing number of inclusion files are being targeted for removal from the repository; due to the High Level Vulnerability ratings and lack of supported extension content such as variable/parser functions.

Solution:

As of Habatchii (talk) 17:33, 30 July 2012 (UTC); the most effective solution for the vulnerability issue is to contact the [desk] and

1. Notify of attacks against one or more of your sites
2. Request for Review of the GIT process
3. Apply to one or more volunteer programs to police known HLV extensions
4. Use existing templates to document as many broken or vandalized extensions possible
5. Maintain and adopt extensions that you can modify to re-submit to the repository.
6. Arrange for discussion page conferences such as this to be included in a final petition for review.

Additional Solutions:

• for maintainers and authors
• commit request
• pre-commit checklist Habatchii (talk) 17:33, 30 July 2012 (UTC)

Warning: The code or configuration described here poses a major security risk. Site administrators: You are advised against using it until this security issue is resolved. Problem: Vulnerable to code injection attacks, because it passes user input directly to executable statements, such as exec(), passthru() or include(). This may lead to arbitrary code being run on your server, among other things. Solution: Strictly validate user input and/or apply escaping to all characters that have a special meaning in executable statements.

Category:Extensions with arbitrary execution vulnerabilities Habatchii (talk) 20:10, 30 July 2012 (UTC)

MW 1.22 Fatal Error

Extension doesn't work with MW 1.20. Get a PHP Fatal Error if I call the special page: Fatal error: Cannot make non static method SpecialUpload::getDupeWarning() static in class MultipleUpload in extensions/MultiUpload/MultiUpload.body.php on line 0 , and when I call upload file Fatal error: Cannot make non static method SpecialUpload::getDupeWarning() static in class MultipleUpload in extensions/MultiUpload/MultiUpload.body.php on line 10 82.19.15.121 09:26, 20 December 2013 (UTC)

Remove the "static" keyword on line 354 of Multiupload.body.php to look like:

public function getDupeWarning( $dupes, $dupeTitle = null ) {

Eric William Cochran (talk) 13:09, 13 January 2014 (UTC)

I'm getting this same error when I go to the upload file page - Fatal error: Cannot make static method SpecialUpload::getDupeWarning() non static in class MultipleUpload in extensions/MultiUpload/MultiUpload.body.php on line 10

I went to Multiupload.body.php and removed "static" from that line per instructions, but that didn't fix it. Still getting same error. Please help? GreenBryn (talk) 00:21, 12 February 2014 (UTC)

I am getting the exact same error message in 1.19 (installed from repo).

I tried applying the same fix as suggested above, but, Multiupload.body.php did not contain the keyword static on the suggested line, which as it turns out, is 357 on the file I am working with. 206.83.81.178 14:31, 28 February 2014 (UTC)

WOW !

I just upgraded my MultiUpload installation and OMG what a difference, I usually don't make post as exuberant but, ya made my day :) thank you very much ! Mlpearc (open channel) 22:12, 30 May 2014 (UTC)

MW 1.22.6 Not Loading.

Hi. I'm not getting multi upload working. When I load the SpecialPage I get some text telling me about the type of files I can upload and under that is a spinner which must be running on Duracel because it just keeps on going. 2001:8B0:FFB3:0:C218:85FF:FE6B:53DE 00:41, 3 June 2014 (UTC)

The same is happening to me - the page is http://coasterpedia.net/wiki/Special:MultiUpload and I'm running 1.23.0 - does anyone have a fix? 2.25.17.163 15:28, 16 July 2014 (UTC)

I managed to get it working using the GIT master rather than the extension distributor. No idea why this worked but it did. 2.28.33.231 19:35, 16 July 2014 (UTC)

I too am getting the spinning wheel in IE8. Seems to be a javascript error. Browser Mode IE8, Document Mode: IE8 Standards

LOG: Exception thrown by special.upload.patched

TypeError: Object doesn't support this property or method

Tried IE8 Compatibility mode - no change.

If I set Document Mode to IE7 Standards or Quirks mode, no spinners, and it works but this error:

Expected identifier, string or number load.php?debug=false&lang=en&modules=ext.multiupload.top%7Cjquery.client%2Ccookie%2CmwExtension%2Cthrottle-debounce%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.notify%2Ctoc%2Cutil%7Cmediawiki.page.startup%7Cskins.vector.js&skin=vector&version=20140825T193003Z&*, line 1 character 515

Works great in Chrome of course.

MediaWiki 1.23.2 159.116.1.11 20:26, 25 August 2014 (UTC)

I have this on 1.27 also after migrating from 1.24. If you refresh the page you can see the form loading, especially in Firefox but also in Chrome. The spinner then takes over. Gfist (talk) 23:26, 30 August 2016 (UTC)

I found a replacement for MultiUpload, discussion here: https://www.mediawiki.org/w/index.php?title=Extension%20talk%3ASimpleBatchUpload#c-Gfist-2016-08-31T16%3A03%3A00.000Z-Yaron_Koren-2016-07-18T14%3A55%3A00.000Z.

The replacement is called SimpleBatchUpload, and can be found here: https://github.com/s7eph4n/SimpleBatchUpload. Gfist (talk) 16:06, 31 August 2016 (UTC)

Destination FIle name changes

Mediawiki 1.23.2 When I select File 2 to upload, the destination filename of File 1 upload reverts back to the default file name. How can I stop this happening? 31.185.135.233 19:13, 15 September 2014 (UTC)

Add Link to Toolbox

Here is a quick and easy way to add this to the "Toolbox" at the end of the sidebar. Add this code to the end of MultiUpload.php:

// Hook to toolbox:
$wgHooks['BaseTemplateToolbox'][] = 'onBaseTemplateToolbox';


function onBaseTemplateToolbox( $sk, &$toolbox) {

        $toolbox['multiupload']['href'] = Skin::makeSpecialUrl('MultiUpload');
        $toolbox['multiupload']['msg'] = 'multipleupload-toolbox';
        $toolbox['multiupload']['id'] = 't-multiupload';

        return true;
}

Jlemley (talk) 02:45, 20 September 2014 (UTC)

Under 1.23.5 unpacking zip or tarfile gives errormessage

No matter what I try but trying to the contents of a 14MB-zipfile (or tarfile) results upon unpacking that it says "Error uploading package file" "Error: Invalid file title specified"

There are approx. 55 files in the zipfile and maxuploadfiles has been set to 100.

Also I had to modify the post_max_size in php.ini as this value is being used instead of upload_max_size.

Doesn't matter if I run this under Firefox or Chrome. DikkieDick (talk) 11:03, 6 October 2014 (UTC)

MultiUpload-bug when using Zip-file

If I upload a zipfile with a bunch of images, the filesize of all but one file (the first) is set to 0 bytes, although the image is present and has a larger than 0 filesize on the server. DikkieDick (talk) 11:02, 11 November 2014 (UTC)

Not compatible with MediaWiki 1.25

Upon accessing Special:SpecialPages, it thows: Fatal error: Cannot redeclare class SpecialMultiUpload in /home/www/lib/mediawiki-1.25.1/extensions/MultiUpload/SpecialMultiUpload.php on line 120 Ciencia Al Poder (talk) 18:23, 1 June 2015 (UTC)

Hi.

I've fixed this errors with this patch, preventing the class to be loaded again:

diff -r MultiUpload/SpecialMultiUpload.php MultiUpload.orig/SpecialMultiUpload.php
42,47d41
< /* IGGL */
< /* Try to fix
<  * PHP Fatal error:  Cannot redeclare class SpecialMultiUpload in /usr/local/mediawiki-extensions/MultiUpload/SpecialMultiUpload.php on line 0, referer: https://wiki03.terma.com/sandbox/index.php/Special:Upload
<  */
< if(!class_exists('SpecialMultiUpload')){
< 
127,135d120
< /* IGGL */
< }
< 
< /* IGGL */
< /* Try to fix
<  * PHP Fatal error:  Cannot redeclare class MultiUploadForm in /usr/local/mediawiki-extensions/MultiUpload/SpecialMultiUpload.php on line 0, referer: https://wiki03.terma.com/sandbox/index.php/Special:Upload
<  */
< if(!class_exists('MultiUploadForm')){
< 
208,209d192
< /* IGGL */
< }
233,237d215
< 
< 	/* Try to fix
< 	 * PHP Fatal error:  Cannot redeclare class DerivativeRequest in /usr/local/mediawiki-extensions/MultiUpload/SpecialMultiUpload.php on line 0, referer: https://wiki03.terma.com/sandbox/index.php/Special:Upload
< 	 */
< 	if ( !class_exists( 'DerivativeRequestWithFiles' ) ) {
254,255d231
< 	/* IGGL */
< 	}
260,263d235
< 	/* Try to fix
< 	 * PHP Fatal error:  Cannot redeclare class DerivativeRequest in /usr/local/mediawiki-extensions/MultiUpload/SpecialMultiUpload.php on line 0, referer: https://wiki03.terma.com/sandbox/index.php/Special:Upload
< 	 */
< 	if ( !class_exists( 'DerivativeRequestWithFiles' ) ) {
265,266d236
< 	/* IGGL */
< 	}
269,274d238
< /* IGGL */
< /* Try to fix
<  * PHP Fatal error:  Cannot redeclare class UploadRow in /usr/local/mediawiki-extensions/MultiUpload/SpecialMultiUpload.php on line 0, referer: https://wiki03.terma.com/sandbox/index.php/Special:Upload
<  */
< if(!class_exists('UploadRow')){
< 
497,504d460
< /* IGGL */
< }
< 
< /* IGGL */
< /* Try to fix
<  * PHP Fatal error:  Cannot redeclare class UploadFormRow in /usr/local/mediawiki-extensions/MultiUpload/SpecialMultiUpload.php on line 0, referer: https://wiki03.terma.com/sandbox/index.php/Special:Upload
<  */
< if(!class_exists('UploadFormRow')){
634,636d589
< /* IGGL */
< }
<

This seems to fix the form display, but sadly still do not works.

When trying to upload files, I always get the error:

The file you uploaded seems to be empty. This might be due to a typo in the filename. Please check whether you really want to upload this file.

I'm not able to find the problem. The debug information:

Start request POST /sandbox/index.php/Special:MultiUpload
HTTP HEADERS:
HOST: <HOSTNAME>
USER-AGENT: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
ACCEPT-LANGUAGE: en-US,en;q=0.5
ACCEPT-ENCODING: gzip, deflate
REFERER: https://<HOSTNAME>/sandbox/index.php/Special:MultiUpload
COOKIE: wikisandboxdbUserID=3; wikisandboxdbUserName=Iggl; wikisandboxdb_session=<SESSION>; uls-previous-languages=%5B%22en%22%5D
CONNECTION: keep-alive
CONTENT-TYPE: multipart/form-data; boundary=---------------------------38489103911317133881752535727
CONTENT-LENGTH: 22936
[caches] main: EmptyBagOStuff, message: SqlBagOStuff, parser: SqlBagOStuff
Connected to database 0 at localhost
Connected to database 0 at localhost
[caches] LocalisationCache: using store LCStoreDB
Fully initialised
User: cache miss for user 3
User: loading options for user 3 from database.
User: logged in from session
User: loading options for user 3 from override cache.
[MessageCache] MessageCache::load: Loading en... got from global cache
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser
Parser: using preprocessor: Preprocessor_DOM
Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct
User::getBlockedStatus: checking...
UploadBase::createFromRequest: class name: UploadFromFile
UploadBase::createFromRequest: class name: UploadFromFile
[GlobalTitleFail] MessageCache::parse called by FileIndexer::addCheckboxToUploadForm/Message::__toString/Message::toString/Message::parseText/MessageCache::parse with no title set.
[GlobalTitleFail] MessageCache::parse called by MultiUploadForm::__construct/Message::parse/Message::toString/Message::parseText/MessageCache::parse with no title set.
[Preprocessor] Saved preprocessor XML to memcached (key wikisandboxdb:preprocess-xml:<HASH>:0)
[Preprocessor] Saved preprocessor XML to memcached (key wikisandboxdb:preprocess-xml:<HASH>:0)
[GlobalTitleFail] MessageCache::parse called by MultiUploadForm::getLegend/Message::parse/Message::toString/Message::parseText/MessageCache::parse with no title set.
[GlobalTitleFail] MessageCache::parse called by MultiUploadForm::getLegend/Message::parse/Message::toString/Message::parseText/MessageCache::parse with no title set.
[GlobalTitleFail] MessageCache::parse called by MultiUploadForm::getLegend/Message::parse/Message::toString/Message::parseText/MessageCache::parse with no title set.
DatabaseBase::query: Writes done: REPLACE INTO `objectcache` (keyname,value,exptime) VALUES ('X')
OutputPage::sendCacheControl: private caching;  **
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
[runJobs] Running 1 job(s) via '/sandbox/index.php?title=Special%3ARunJobs&tasks=jobs&maxjobs=1&sigexpiry=1435317559&signature=<SIGNATURE>'
[runJobs] Failed to start cron API: received 'HTTP/1.1 403 Forbidden
'
Request ended normally

Same information using builtin upload form:

Start request POST /sandbox/index.php/Special:Upload
HTTP HEADERS:
HOST: <HOSTNAME>
USER-AGENT: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
ACCEPT-LANGUAGE: en-US,en;q=0.5
ACCEPT-ENCODING: gzip, deflate
REFERER: https://<HOSTNAME>/sandbox/index.php/Special:Upload
COOKIE: wikisandboxdbUserID=3; wikisandboxdbUserName=Iggl; wikisandboxdb_session=<SESSION>; uls-previous-languages=%5B%22en%22%5D
CONNECTION: keep-alive
CONTENT-TYPE: multipart/form-data; boundary=---------------------------1832873965988468950239988269
CONTENT-LENGTH: 175165
[caches] main: EmptyBagOStuff, message: SqlBagOStuff, parser: SqlBagOStuff
Connected to database 0 at localhost
Connected to database 0 at localhost
[caches] LocalisationCache: using store LCStoreDB
Fully initialised
User: cache miss for user 3
User: loading options for user 3 from database.
User: logged in from session
User: loading options for user 3 from override cache.
[MessageCache] MessageCache::load: Loading en... got from global cache
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser
Parser: using preprocessor: Preprocessor_DOM
Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct
User::getBlockedStatus: checking...
UploadBase::createFromRequest: class name: UploadFromFile
WebRequestUpload::getName: <FILE>.png normalized to '<FILE>.png'
WebRequestUpload::getName: <FILE>.png normalized to '<FILE>.png'
WebRequestUpload::getName: <FILE>.png normalized to '<FILE>.png'
FSFile::getProps: Getting file info for /tmp/phpQWmUQm
MimeMagic::__construct: loading mime types from <MWPATH>/sandbox/includes/mime.types
MimeMagic::__construct: loading mime info from <MWPATH>/sandbox/includes/mime.info
MimeMagic::doGuessMimeType: analyzing head and tail of /tmp/phpQWmUQm for magic numbers.
MimeMagic::doGuessMimeType: getimagesize detected /tmp/phpQWmUQm as image/png
MimeMagic::guessMimeType: guessed mime type of /tmp/phpQWmUQm: image/png
MimeMagic::improveTypeFromExtension: improved mime type for .png: image/png
[XMP] XMPReader::doAttribs Ignoring unrecognized element <http://ns.adobe.com/xap/1.0/mm/:InstanceID>.
[XMP] XMPReader::doAttribs Ignoring unrecognized element <http://ns.adobe.com/xap/1.0/mm/:DocumentID>.
[XMP] XMPReader::startElementModeInitial Ignoring unrecognized element <http://ns.adobe.com/xap/1.0/mm/:DerivedFrom>.
FSFile::getProps: /tmp/phpQWmUQm loaded, 173826 bytes, image/png.
mime: <image/png> extension: <png>
UploadBase::detectScript: checking for embedded scripts and HTML stuff
UploadBase::detectScript: no scripts found
ZipDirectoryReader: Fatal error: zip file lacks EOCDR signature. It probably isn't a zip file.
UploadBase::detectVirus: virus scanner disabled
FSFile::getProps: Getting file info for /tmp/phpQWmUQm
MimeMagic::doGuessMimeType: analyzing head and tail of /tmp/phpQWmUQm for magic numbers.
MimeMagic::doGuessMimeType: getimagesize detected /tmp/phpQWmUQm as image/png
MimeMagic::guessMimeType: guessed mime type of /tmp/phpQWmUQm: image/png
MimeMagic::improveTypeFromExtension: improved mime type for .png: image/png
[XMP] XMPReader::doAttribs Ignoring unrecognized element <http://ns.adobe.com/xap/1.0/mm/:InstanceID>.
[XMP] XMPReader::doAttribs Ignoring unrecognized element <http://ns.adobe.com/xap/1.0/mm/:DocumentID>.
[XMP] XMPReader::startElementModeInitial Ignoring unrecognized element <http://ns.adobe.com/xap/1.0/mm/:DerivedFrom>.
FSFile::getProps: /tmp/phpQWmUQm loaded, 173826 bytes, image/png.
UploadBase::verifyExtension: mime type image/png matches extension png, passing file
UploadBase::verifyFile: all clear; passing.
FileBackendStore::getFileStat: File mwstore://local-backend/local-public/f/fc/<FILE>.png does not exist.
FileBackendStore::getFileStat: File mwstore://local-backend/local-public/archive/f/fc/20150626111255!<FILE>.png does not exist.
DatabaseBase::query: Writes done: INSERT IGNORE INTO `image` (img_name,img_size,img_width,img_height,img_bits,img_media_type,img_major_mime,img_minor_mime,img_timestamp,img_description,img_user,img_user_text,img_metadata,img_sha1) VALUES ('X')
[ContentHandler] Created handler for wikitext: WikitextContentHandler
[StashEdit] No cache value for key 'wikisandboxdb:prepared-edit:<HASH>'.
[GlobalTitleFail] MessageCache::parse called by FileIndexer::articleSave/Message::__toString/Message::toString/Message::parseText/MessageCache::parse with no title set.
[GlobalTitleFail] MessageCache::parse called by FileIndexer::articleSave/Message::__toString/Message::toString/Message::parseText/MessageCache::parse with no title set.
WikiPage::doEditUpdates: No vary-revision, using prepared edit...
Saved in parser cache with key wikisandboxdb:pcache:idhash:43-0!*!*!*!*!*!* and timestamp 20150626111255 and revision id 69
DatabaseBase::query: Writes done: REPLACE INTO `objectcache` (keyname,value,exptime) VALUES ('X')
BacklinkCache::queryLinks: got results from DB
BacklinkCache::queryLinks: got results from DB
BacklinkCache::queryLinks: got results from DB
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
Title::getRestrictionTypes: applicable restrictions to [[File:<FILE>.png]] are {edit,move,upload}
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
Job with hash '<HASH>' is a duplicate.
BacklinkCache::partition: got from full result cache
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
IP: <HOSTIP>
BacklinkCache::partition: got from full result cache
OutputPage::sendCacheControl: private caching;  **
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
[runJobs] Running 1 job(s) via '/sandbox/index.php?title=Special%3ARunJobs&tasks=jobs&maxjobs=1&sigexpiry=1435317180&signature=<SIGNATURE>'
[runJobs] Failed to start cron API: received 'HTTP/1.1 403 Forbidden
'
Request ended normally

94.16.81.106 11:22, 26 June 2015 (UTC)

Same error I have here,

MediaWiki version 1.25,

MultiUpload version 1.25

MultiUpload: REL1_25

2015-06-16T21:13:04

db0c9d4 116.228.206.178 10:10, 30 June 2015 (UTC)

The solution seems more simple:

Comment out this line in MultiUpload.php by adding a # character in front of it:

$wgAutoloadClasses['FauxWebRequestUpload'] = __DIR__ . '/SpecialMultiUpload.php';

Once done, it works for me. Ciencia Al Poder (talk) 13:26, 1 July 2015 (UTC)

That got me past the error also. Now have to fix forever spinning gif. Gfist (talk) 21:36, 30 August 2016 (UTC)

For me, the error was, when accessing http://<mymediawikiinstallation>:Especial:PáginasEspeciales

Fatal error: Cannot redeclare class SpecialMultiUpload in /var/www/mediawiki-1.25.2/extensions/MultiUpload/SpecialMultiUpload.php on line 0

The solution I found from @Ciencia Al Poder's:

sudo sed -i "s/\(\$wgSpecialPages\['MultiUpload'\] = 'SpecialMultiUpload';\)/# \1/" /var/www/mediawiki-1.25.2/extensions/MultiUpload/MultiUpload.php efedoso (talk) 08:58, 16 August 2015 (UTC)

Better Extension

For applications where you want a quick upload to a private Wiki this extension might be a '''much''' better alternative. It has less complexity (and thus less bugs), it does not require editor integration, the workflow is much faster and the UI is lean. It might be worth checking it out.

https://github.com/j-yun/mediawiki-extension-QuickUploadZone 217.95.173.191 (talk) 15:53, 20 October 2018 (UTC)

I see an extension which is far more likely to have security issues than this one: it's only had three commits, there's a single fork which appears to have been created by accident, there are no reported issues, and there's virtually no documentation. The presence of a minified JS file (modules/clipboad.min.js) without an unminified version available for inspection is suspicious as well. 「ディノ奴千？！」^{☎ Dinoguy1000} 20:58, 20 October 2018 (UTC)

Does not work anymore with 1.34

A great extension, but unfortunately unmainted and now, with MediaWiki 1.34, it isn't working any longer. :-( 93.236.78.172 (talk) 17:21, 27 January 2020 (UTC)

Archiving this unmaintained broken extension

See phab:T268667. AKlapper (WMF) (talk) 07:57, 6 April 2021 (UTC)

Done [[kgh]] (talk) 08:59, 6 April 2021 (UTC)