Manual talk:Configuring file uploads

Latest comment: 1 year ago by 2001:9E8:E5CD:6E00:3915:497A:62:AB08 in topic Change upload directory

enabling upload pdf[edit]

I enabled uploading pdf but on that page I get this message. What does it mean? pdf file has problem or a php extension or wikimedia itself?

File has insufficient data for an image. GPL Ghostscript 8.71: Unrecoverable error, exit code 1 convert: no decode delegate for this image format `/tmp/magick-9uL6qG5N' @ error/constitute.c/ReadImage/544. convert: no images defined `/tmp/transform_8e246748821a.jpg' @ error/convert.c/ConvertImageCommand/301

Images not displaying after upload; 404 page displays following image link[edit]

I'm using Bluehost, with Mediawiki 1.20.5, PHP 5.4.13, MySQL 5.5.30. Images directory in /w is set to 777

Local Settings:
     $wgEnableUploads  = true;
     $wgUseImageMagick = true;
     $wgImageMagickConvertCommand = "/usr/bin/convert";


     file_uploads = On

The upload process on the wiki itself seems to work fine-- the upload screen shows the thumbnail of the image about the imported. Once the upload is done however, no image displays-- just empty thumbnail boxes. When I click on the image link itself, it takes me to a 404 screen with the URL /w/images/'number or letter'/'number or letter'/'my filename'. No folder or file is created in /images, however.

I've also tried configuring php.ini to move the uploaded file, using: move_uploaded_file($_FILES['userfile']['tmp_name'], "{IP}/images") although I'm not sure if I did that right or not, or if that is even the problem to begin with

Any ideas?

Same Problem here after I upgraded from MW 1.19 to MW 1.23. Still searching for the real cause. -- 22:58, 8 June 2014 (UTC)Reply[reply]

I looked in apache logs. The following error "sh: /cp: not found" appears each time I try a new upload. (I use MW 1.23.)

      I may know the problem because i think i have the same problem. it could be that the server 
      you're working on does not work with $wgImageMagickConvertCommand = "/usr/bin/convert";
      MW 1.29 14:15, 9 October 2017 (UTC)

Added openoffice file extentions[edit]

In the wiki, I added the openoffice file extentions in order not to privilege Microsoft extentions, and so that the readers easily may copy them.

 I am unable to upload ods and other open office files. I have included them in the $wgFileExtensions. Its not in the black lists. I have also set the mime types in the mime.types file.

Please advice

Upload link not shown in Toolbox[edit]

The Upload option is not displayed in my toolbox. My LocalSettings.php upload configuration is this:

$wgEnableUploads = true;
$wgGroupPermissions['autoconfirmed']['upload'] = true;
$wgGroupPermissions['autoconfirmed']['reupload'] = true;
$wgGroupPermissions['user']['upload'] = true;
$wgFileExtensions = array('png', 'gif', 'jpg', 'jpeg', 'doc', 'xls', 'mpp', 'pdf', 'ppt', 'tiff', 'bmp', 'docx', 'xlsx', 'pptx', 'ps', 'psd', 'swf', 'fla', 'mp3', 'mp4', 'm4v', 'mov', 'avi');

The Server Settings seem to be right, but if not that wouldn't prevent MediaWiki to show the Link wouldn't it?

09:27, 17 December 2010 (UTC)

Solved the problem there was another "$wgEnableUploads = false" in the File. 09:54, 17 December 2010 (UTC)Reply[reply]

I have the same problem, same LocalSettings.php configuration, but no upload option in my sidebar. Thanks! -- 08:57, 11 May 2011 (UTC)Reply[reply]

Cannot upload file name for the gbk code[edit]

I want to provide a convenient way to upload,But in the program utf-8 mediawiki cannot upload file name for the gbk code.Please try for this file name.

Is the server running Windows? Max Semenik 09:42, 8 December 2010 (UTC)Reply[reply]

Can upload file name for gbk code, but cannot point it(the url is error)[edit]

The server is running in Windows。I can upload the file with chinese name to server as follows,


but the file is renamed to corrupted characters in the server directory as follows,


And then, the url in the file page is error as follows,

The requested URL /ismwiki/images/1/15/æ ‡å¿—.jpg was not found on this server.
  • MediaWiki version: 1.16.1
  • Mysql:5.5.8
  • PHP:5.3.3
  • OS:Windows Server 2003

Cannot upload PDFs[edit]

I cannot upload PDFs to my wiki. I am logged in as a sysop. I can upload images just fine. The research I have done leads be to believe these changes in LocalSettings should do the trick, but they don't... The public directory is now 777. I don't an error message.

$wgEnableUploads       = true;
$wgAllowExternalImages = true;
$wgAllowCopyUploads 	= true;
$wgAllowImageMoving		= true;
# $wgUseImageMagick = true;
# $wgImageMagickConvertCommand = "/usr/bin/convert";
# allow more file types:
$wgFileExtensions[] = 'pdf';
# trying to get pdfs to work
$wgVerifyMimeType = false;
$wgStrictFileExtensions = false;
$wgCheckFileExtensions = false;
## $wgMimeDetectorCommand = "file -bi"; 
ini_set( 'memory_limit', '64M' );
/** This is a flag to determine whether or not to check file extensions on upload. */
$wgUploadSizeWarning = true;

Any advice? --Two7s clash 16:08, 23 April 2010 (UTC)Reply[reply]

$wgEnableUploads as the very last line. Setting it to true before setting $wgAllowExternalImages and $wgVerifyMimeType can cause errors. See '".[FILE EXTENSION]" is not a recommended image file format.' below. --Brian F. 19:46, 10 August 2010 (UTC)


False folder permission[edit]

After uploading images I'm not able to see them because the subfolders don't have the permission 755. Can I change that automatically or do I have to change them after every upload? It would also be ok if all images would be stored in the images/ folder instead in the images/firstletter/firstletternumber. I hope someone can help me.

MediaWiki's $wgEnableUploads vs. PHP's file_uploads[edit]

How come when editing MediaWiki's $wgEnableUploads between true and false becomes noticeable immediately (unable to upload vs. upload enabled) but editing PHP $file_uploads (if already 'on') is not impacting/denying my upload experience at all?

You have to restart Apache for your PHP config changes to take effect

End User[edit]

Who is the "end user"; someone accessing the wiki using a web browser, or a local user on the machine running the wiki?

In this case, "end user" refers to the user accessing the wiki using a web browser.

File Types[edit]

Are file uploads only for images, or for any type of file?

You can configure MediaWiki to accept additional file types using the $wgFileExtensions configuration setting.


Shouldn't the chmod for the upload directory be 744? That gives rwxr--r--. 755 gives r-x, which I thought was what we were trying to avoid...
Execute privilege on directories is required to access files inside them. (Yes, this is confusing. Blame AT&T.) --Brion VIBBER 00:47, 19 February 2006 (UTC)Reply[reply]

There are pages on this site that say 744,755,777. Could someone explain wich to use when? -- anon

The important thing is that the webserver has write access. Thus if the upload directory is owned by the webserver user ( e.g. www-data ) 755 would suffice. If the webserver is not owner, but is in the group owning the directory, 775 would be better. 777 is the extreme case where all users on the system have full access. In most cases this would not be advisable. -- anon
Thanks for that. Actually the bit about setting the owner to www-data just helped me. As an additional note on this, I think I'm also seeing (on a standard ubuntu apache set-up) that setting the directory to 777 will trip some other security checks thus preventing access. But could be my imagination.
So combining these things, I needed to set 755, but also set the owner of the file and the group of the file to 'www-data'. I also needed to do these things recursively because I was restoring from a backed up directory tree:
chmod -R 755 images
chown -R www-data images
chgrp -R www-data images
The page currently doesn't mention what the owner should be set to. It's important no? Of course 'www-data' wont always be the correct username. Worked for me on ubuntu.
-- Harry Wood 16:44, 21 June 2011 (UTC)Reply[reply]
For me this worked:
chown -R username:psaserv /var/www/vhosts/
chmod -R 775 /var/www/vhosts/
--Subfader (talk) 15:15, 25 January 2014 (UTC)Reply[reply]

Making Uploads Lowercase[edit]

Does anyone have any idea how to allow files to be uploaded and named with lowercase letter, for some reason all uploaded file default to a capital letter for the first letter of the file name? 21:13, 3 May 2006 (UTC)Reply[reply]

wuh. just under a year response time. Anywho: A technical limitation of Mediawiki is that all pagenames have to start with an uppercase letter. this is most likely the cause for all files beeing renamed. 12:24, 2 May 2007 (UTC)Reply[reply]

The file is corrupt or has an incorrect extension. Please check the file and upload again.[edit]

I did as mentioned.

It's a little frustrating, but it seems like mediawiki does not bother that I changed settings in localsettings.php.

I added zip as an extension, than I turned off the extension check, then I turned of mime check etc.

Still I can only upload images and no zip files.

what to do?

How I fixed it[edit]

I had to set $wgVerifyMimeType=false; in my LocalSettings.php which means my mime types are probably screwed up. Its an symptomatic fix to a bigger problem, i suspect.

Perhaps have a look at Manual:Mime type detection -- Duesentrieb 11:10, 6 March 2007 (UTC)Reply[reply]

".[FILE EXTENSION]" is not a recommended image file format.[edit]

I have set file extensions to allow wmv and avi, set $wgStrictFileExtensions=false; and $wgVerifyMimeType=false in LocalSettings.php, but get the message " ".avi" is not a recommended image file format. " (same for .wmv) when I try to upload avi (and wmv) files. Files sizes are under the cap in php.ini. I have not problems uploading static image files (eg .jpg, .png).

With $wgStrictFileExtensions=false, you will still get that warning, but should be able to override it ("upload anyway" or some such). $wgVerifyMimeType=false has nothing to do with this, it just tells MediaWiki not to check if the file actually is an avi file (failing that test would result in a different error message though). -- Duesentrieb 11:45, 21 April 2007 (UTC)Reply[reply]
Thanks for the speedy response. Unfortunately no override option appeared on the screen. I just got "Upload warning" header above the "not a recommended image file format" message. This also happened when I check "Ignore any warnings" on the upload screen. However, I then rearranged the order of in LocalSetting.php so that $wgStrictFileExtensions=false appeared before $wgEnableUploads=true and $wgFileExtensions = .... I can now upload video files without any difficulties.
Turning of $wgStrictFileExtensions seems a little dangerous. I fixed a similar problem I was having with xls files by adding the following line to mime.types:
application/msword xls
Depending upon the mime detection engine on your server, certain types are misidentified. The true solution is to fix the engine, but this is a pretty safe alternative. - dan

MUst be server pixies then. -- Duesentrieb 13:21, 21 April 2007 (UTC)Reply[reply]

This file is bigger than the server is configured to allow[edit]

How do you change the maximum allowed size of a file for uploading?

This is what I have in my php.ini:

; Maximum allowed size for uploaded files.
;upload_max_filesize = 2M
upload_max_filesize = 250M

You may also have to change post_max_size in the same file. Apache itself might also have a limit set. And keep in mind that you have to restart Apache for any changes to the PHP configuration to take effect...

On my system I'm apparently using PHP FPM, so the file to edit is /etc/php/7.2/fpm/php.ini (editing /etc/php/7.2/apache2/php.ini had no effect). After doing that you need to restart the PHP FPM process.

Upload Privileges[edit]

Is there a way to set it so that only SysOp can upload files?

Try meta:Uploading_files#Is_it_possible_to_let_only_some_users_upload_Images.3F --Flominator 07:26, 29 January 2007 (UTC)Reply[reply]

anonymous uploads[edit]

Is there a way to allow users to upload files without logging in?

That'd be a great help for corporate environments where only a limited number of people can access the wiki (server) anyway...

  • Edit SpecialUpload.php file in the includes folder
  • Comment out the following two lines:
$wgOut->errorPage( 'uploadnologin', 'uploadnologintext' );

Now users will not have to login to reach the upload form.

Simpler method, modify LocalSettings.php:

$wgEnableUploads       = true;
$wgGroupPermissions['*']['upload'] = true;

In which file is variable $wgFileExtensions?[edit]

Im trying to change my extensions list, but it is not in LocalSettings? Where is it?

  • The default is set in includes/DefaultSettings.php. But you shouldn't change it here. Just copy the line into your LocalSettings.php and alter it the way you like here. The intention for this procedure is just that the DefaultSettings is responsible for everything that is NOT explicity set by yourself. Also if you like to make an update someday you won't destroy your current settings, cause the LocalSettings.php won't be touched through an update.

Check directory security[edit]

In the manual page, it says under "Check directory security" that "The upload directory needs to be configured so that it is not possible for an end user to upload and execute other scripts, which could then exploit access to your web directory and damage your wiki or web site."

Unfortunately, the PHP function that makes subdirectories is:

function wfMkdirParents( $fullDir, $mode = 0777 ) { ... }

and many places that call this use the fault mode 0777 which is world-writable. For example, everywhere in Image.php it uses one argument calling this method, such as:

./includes/Image.php:1078: wfMkdirParents( $thumbDir );

The consequence of this is that every directory recursively under images is world-writable. The files themselves seem to be fine (mode 644), however, any user who can login to the system on which the MediaWiki instance is running can copy or destroy files at will.

Can we get wfMkdirParents (and everywhere that 0777 is passed to that method) to use a mode of 0755 instead? --Caswick 21:09, 15 March 2007 (UTC)Reply[reply]

How to link "other" file types on pages?[edit]

Case 1 - When i want to upload images, i follow the following steps

  • go to page edit
  • write a suitable name
  • make it into an image link by clicking the 6th button from the left on the edit menu
  • save page
  • view page, the link is shown in red.
  • click it and upload the image


But with file types other than images,it give an error as to "not a jpeg format", there is no such option. I have to link the thing by copy/pasting the exact names everytime. There must some other way around! Please help me on this !! --Ankit.madan 07:12, 21 August 2007 (UTC)Reply[reply]

Error when uploading from URL[edit]

Fatal error: Call to undefined function curl_init() in /path/to/wiki/includes/SpecialUpload.php on line 165

Any idea what could cause this? I've googled it, but it seems only the chinese have experiences this problem. Using MW 1.11 - followed the directions on the configuration page. Regular uploads work fine.

I solved this by typing on Ubuntu: 'sudo apt-get install php5-curl' followed by 'sudo /etc/init.d/apache2 restart'

Folder permissions & SUPHP[edit]

If you are using suphp you might want to check the suphp configuration file ( /etc/suphp.conf )

and ensure the Umask value is set to something sane (so when the folders get created they get the proper permissions)

Umask to set, specify in octal notation


You can also set the umask locally at the LocalSettings.php:


Multiple Uploads[edit]

Is it possible to upload multiple files at one time (like for a photo gallery) rather than uploading each file individually? Or if I FTP them to my server without using MediaWiki's upload page, can I still use the <gallery> tags to display them somehow?

There's Extension:MultiUpload, havn't tried it though. If you upload files directly to the server using FTP or SCP or whatever, you have to import them into MediaWiki to make them work wiki-style: That is done using maintenance/importImages.php but it requires shell access. I believe some of the bots that exist for mediawiki also support file upload, but I havn't looked into that. There's also the commonist upload tool, which was designed for wikimedia commons, but can be adopted to other sites as well.
HTH -- Duesentrieb 06:56, 11 April 2008 (UTC)Reply[reply]
Thanks so much for the info! I do have shell access, and I think FTP and import would probably the fastest for lots of images. I may use MultiUpload as well - it would be nice if I had just a few files.
Just saw that I do not want drag'n'drop mutple upload via interface. Too much abuse. Will also try MultiUpload. Thanks --Subfader 04:55, 7 December 2008 (UTC)Reply[reply]
The absolute best extension for this is Extension:SpecialUploadLocal which currently works for all version but 1.16. Adamtheclown 08:35, 15 November 2010 (UTC)Reply[reply]

Image File Names[edit]

I'm webmaster of, a Spanish language wiki. We recently moved from one hosting server to another and it took us weeks to finish the migration because of problems with the names of some images. The main problem was that our former hosting (yahoo) didn't allow the creation of files or folders with certain characters, but wiki did it anyway and we didn't care until we moved away. Our former wiki could read the folders and images in them, but we could not see them or ftp them out of yahoo because of invalid characters in the names.

This was most likely solved by our move to a new hosting and upgrade to the latest wiki, but after so many problems I simply don't want to risk it. My question: There's way to forbid users from uploading files with names containing symbols (as in #, @, etc) and accented words (as in "ó")?

Right now we are running with a modification I did to Specialupload.php in line 426, where I changed this:

$filtered = preg_replace ( "/[^".Title::legalChars()."]|:/", '-', $filtered );

To this:

$filtered = preg_replace ( "/[^a-z0-9\\040\\.]|:/i", 'x', $filtered );

With this change users cannot upload files with symbols or accented words, but they still can upload the "ugly" and nondescriptive file names created by my patch. Meaning, words with a bunch of X's where the symbols or accented words used to be.

  • So, is there a way to just reload the page and say, Please change your filename, such and such characters are invalid?
  • Is there a way to transform accented words like "ó" into plain "o"s?

In Especial:Allmessages I found a message titled illegalfilename that warns against using invalid characters, so I guess there's some sort of option without having to change Specialupload.php directly.

Thanks in advance, here's my upload page in case you need to test it.

--Mark 09:55, 25 April 2008 (UTC)

reload the page and say, Please change your filename -> yes, you can write a piece of code using the hook UploadVerification (you can adapt UploadBlacklist extension for this purpose) --Yannouk (talk) 12:05, 9 January 2013 (UTC)Reply[reply]

Upload files to FTP server[edit]

Is it possible to upload files to FTP server?

Yes, then use /maintenance/importImages.php Read above section.

Odd filenames?[edit]

Hey, I recently installed the newest Mediawiki and any files (I only tried images though) I upload always come up as Image:[USERNAME]--[IMAGENAME].[extension]. Is there any way to make it just go to the file name? Thanks. --Ratmaster 21:37, 21 November 2008 (UTC)Reply[reply]

I'm getting this too on a small wiki I'm an administrator on. There doesn't seem to be any obvious setting in includes/specials/SpecialUpload.php, does anyone have any clues they could offer me on where to look? Bryan Derksen 06:27, 15 June 2009 (UTC)Reply[reply]
After digging a bit further on this site I found the answer here: Project:Support_desk/Archives/Images/002#(RESOLVED) Preloaded Image Names?. Apparently the "KeepYourHandsToYourself" extension is responsible. Commenting out the line
'extensions/KeepYourHandsToYourself.php' -- $wgHooks['UploadForm:BeforeProcessing'][] = 'prependUsernameToFilename';
seems to be one way to fix it. Bryan Derksen 06:35, 15 June 2009 (UTC)Reply[reply]

File size and postgres[edit]


I'm using mediawiki1.7 with postgres. When uploading a file, the pg_query() can't write in img_size in the image table and I get an error message -

ERROR: value "202205" is out of range for type smallint 

and some other details...

...out of range for type smallint in /usr/share/mediawiki1.7/includes/DatabasePostgres.php

I have modified $wgMaxUploadSize and $wgFileExtensions in LocalSettings.php

$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ppt', 'pdf', 'doc', 'psd', 'mp3','xls', 'zip','swf', 'doc', 'odt', 'odc', 'odp', 'odg', 'mpp'); $wgUploadSizeWarning = 1000 * 1024; $wgMaxUploadSize = 1024 * 1024 * 100;

This did not help. I think, the problem is in the definition of the image table. Is there a way to enable upload of larger files, up to 2M?

Thank you in advance,




I was able to solve this problem by going into the database using phpPgAdmin and modifying the 'image' table by changing the Column/Field img_size type from 'smallint' to 'integer' and now I am able to upload files which exceed the 32K limit which was imposed by using a 'smallint' type for that field.

I hope you can resolve this issue on your end...

muman613 20:07, 1 March 2012 (UTC)

Changing the text on the File Upload Page[edit]

How does one change the text on this page?

I need to add some extra copyright warning text.

--Stuart Halliday 14:44, 12 January 2009 (UTC)Reply[reply]

Ah. Discovered how to do this: Go to the 'MediaWiki:Uploadtext' page of your Wiki and edit it. --Stuart Halliday 15:15, 12 January 2009 (UTC)Reply[reply]

Missing File = Errors[edit]

Right up in Prerequisites, it mentions that a file called php.ini needs to be changed to allow uploads. Problem is, I searched though on my FTP thing, and I don't seem to HAVE a file called php.ini. I did change the bit for LocalSettings.php, and that much allows me to upload images... but to try looking at the page for it, or a page that it's supposed to appear on at all, all that comes up is a 500 Internal Server Error that includes, "Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."

So... I have no idea what to do.

php.ini is a system configuration file; you probably don't have access to it. Your host may or may not be willing to change settings in php.ini for you, and may or may not have a way for you to use your own custom php.ini file.
In any event, you are able to upload files, but the resulting image pages give internal server errors? Enable error reporting and post what you find. —Emufarmers(T|C) 15:24, 7 February 2009 (UTC)Reply[reply]

Upload on a different FTP server[edit]

Is it possible to change the directory of images to a differnt FTP Server? At the moment all images are placed on server1 with all the other folders. Is it possible to extract just the image folder to a different FTP server? The rest of the wiki folders will stay on server1. How do I address the server2 with the uploaddirectory and the uploadpath?

I would also like this feature. My hosting providers offers a separate service for just file hosting without scripting. It's much cheaper, get lots of space, and great transfer allocations. Then, it would be images.mydomain.tld. But, it only has FTP access for uploads, and HTTP access for downloads. 21:53, 19 May 2010 (UTC)Reply[reply]

Upload from URL[edit]

On trying to upload a pic directly from an URL I get an error message

Warning: file_exists():open_basedir restriction in effect. File(/temp/xcvsderd)is not within the allowed path(s): (/var/www/web/html:/var/www/web/phptmp:/var/www/web/files:/var/www/web/atd: /var/www/web/wiki/includes/specials/SpecialUpload.php on line 150

I'm runnig MediaWiki 1.14.0 mysql 5.0.51 php 5.2.9

What am I doing wrong ? How to "config" this feature ? Thanks

Red ant 18:33, 19 April 2009 (UTC)Reply[reply]

File uploads in 1.15.1[edit]

Hey, I'm upgrading from 1.11 to 1.15.1. I have a lot of customized extensions, so I set up 1.15.1 in a separate area of my server to test it out first. However, in 1.15.1 I can't enable file uploads. It says "Uploads disabled. File uploads are disabled in PHP. Please check the file_uploads setting." But my php settings are unchanged, file_uploads is on and it is working fine in the already installed 1.11 wiki (same server but different folder, same database but different table prefixes). Do anyone know what could cause this? I have set $wgEnableUploads=true, and I have set the upload folder to be writable by the server (even set it to 777 just to check). I'd be grateful for any help! --Anderssl 22:41, 10 September 2009 (UTC)Reply[reply]


I've added this topic to the main article. I spent a few hours trying to get my uploads working and it wasn't until I saw the Upload File option under Special Pages that it finally told me I had to register and logon. This would be expected for Wikipedia but for own wikis starting up people (like me) won't necessary register and logon to set it up. 21:04, 11 October 2009 (UTC)Reply[reply]

Fails to rename if tmp and image dirs reside in different volumes (Windows)[edit]

I had the following problem with mediawiki installed on Windows with wamp server and it took me pretty long to solve it:

If the temp directory is in a different volume that the image directory, then the error "could not rename x to y" error arises. That's because PHP (at least version 5.3) does not like renaming files among volumes. In my case I had wamp installed on C: (so the temp directory was the default one c:/wamp/tmp) and wamps webroot directory installed on D: (so the image directory was something like D:/wamp/www/mediawiki/images).

I know this is no strictly a mediawiki issue, but it would have saved me lots of time if a note about this was included in the article.

--Mmutilva 13:23, 25 November 2009 (UTC)Reply[reply]

finding php.ini[edit]

Typical location of where php.ini maybe found.
post_max_size and upload_max_filesize in php.ini

neither of the commands on the main page worked for me in putty.exe or find php.ini, so searching the internet i found this:

For an example of where the php.ini file is: see Where is php.ini located?. Igottheconch 08:43, 16 January 2011 (UTC)Reply[reply]

I have a problem, I don't think I have the file at all :/ No idea why, but what to do now?

I have the same issue. I'm running MW 1.23 and don't see these folders or the file mentioned. Maldarthe1st 13 February, 2015
I had this problem too. I'm afraid this help article is so bad it's worse than useless for the novice. After much effort and googling, I found a way to locate php.ini, only to find that it isn't in a mediawiki folder at all-- it's apparently a sort of system file that applies to everything you do on your server. In my case, it was /etc/php72/php.ini, which is on a read-only directory on the server of the company that hosts my website. I wonder if most users are able to change that directory-- maybe you can't unless you have your own linux installation under your completely control, so users like me who have university or company or commercial servers can't change it. Some discussion of that would be helpful. Don't assume that all mediawiki users know php and linux-- not even the bare basics.

Editeur24 (talk) 03:58, 27 September 2020 (UTC)Reply[reply]

See Manual:php.ini. There's a link to that page in a lot of instances of php.ini of the manual... To prevent confusion, I've removed instructions from the section "locating the php.ini" and pointed to that page instead --Ciencia Al Poder (talk) 17:42, 30 September 2020 (UTC)Reply[reply]

Could not create directory "public/archive/e/ef"[edit]

Hello, I've started uploading photos and it worked great except for some photos. I have the following warning " Could not create directory "public/archive/e/ef" ". This is strange as php.ini allows upload, $wgEnableUploads is set to true, and especially it worked OK before and after these 2 photos. I run MW1.16 with php5, image directory is fully writable as well as subfolders "archive", "e" and "thumb". but where is this "public" folder? Any clue? thx! — Preceding unsigned comment added by (talkcontribs) 10:42, 1 March 2011

So, I found and I'll let you know! basically, the subfolder "e" had no special right and no new subfolder could be written. I simply gave it full authorisation...
Sorry and envoy MW!!! — Preceding unsigned comment added by (talkcontribs) 11:20, 1 March 2011

Could not rename file "/tmp/phpH4iyTE" to "public/9/9b/Germany.png".[edit]

Trying to solve this, any idea?

same as the post just above you, folder 9/9b does not have the correct user rights. Go into your files and change the folder attributes to 777. Igottheconch 00:09, 24 September 2011 (UTC)Reply[reply]
Maybe the owner of the directories is different from the user that the apache process is using (see section Chmod).
-- 15:37, 1 October 2012 (UTC)Reply[reply]

Maximum file size: 7 KB (a file on your computer)[edit]

Recently I have upgraded media wiki from 1.16 to 1.17. Since the upgrade my upload page is displaying the message "Maximum file size: 7 KB (a file on your computer)" and throws me the warning "This file is bigger than the server is configured to allow." when I try to upload a file of modest size.

in the php.ini Localsettings.php file I have the upload limit defined as follows

## Set upload limit
$wgMaxUploadSize = "50M";

and in php.ini, I have these settings (pertaining to file upload)

upload_max_filesize = 50M
post_max_size = 50M

What's missing in my configuration? Any idea? -- 04:45, 2 October 2011 (UTC)Reply[reply]

Yea, take a look in your includes/DefaultSettings.php file. Copy the upload size code over to you local settings and edit the '100' to be the size you're looking for. There is also an example in there for uploads from different sources.. url or other. --Pher122s (talk) 17:23, 20 January 2014 (UTC)Reply[reply]

Uploading on Linux Server[edit]

What is the problem on uploading files in linux godaddy. When I had my mediawiki on windows, I've uploaded files, but now on linux I can't site


Hello everyone. Is there anyway to configure a mw wiki to allow users to upload more than one image at a time? Say I have a folder with 20 various icons I want to upload for a template (let's just say smiley faces), is there anyway to upload them all in one shot instead of one file at a time? Is there an extension out there that will allow this? Thanks for any ideas or suggestions dealing with this. -- ShoeMaker   ( Contributions Message )   23:09, 11 July 2012 (UTC)Reply[reply]

Extension:MultiUpload is what you're looking for, although it's unmaintained.Jasper Deng (talk) 23:17, 11 July 2012 (UTC)Reply[reply]

.htaccess file in images folder causes images not to load[edit]

Today I recognized that images in my wiki do not load. So I checked the logs /var/log/apache2/error.log :

[Tue Aug 14 21:24:47 2012] [alert] [client] /var/www/wiki/images/.htaccess: RewriteEngine not allowed here, referer:

This is the content of the .htaccess file under /var/www/wiki/images:

# Protect against bug 28235
<IfModule rewrite_module>
        RewriteEngine On
       RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]
       RewriteRule . - [forbidden]

I just renamed this file so everythings starts working again, but I would like to reveal the cause of this error. I Think the error originates from my apache's "sites-available", maybe someone could give me a hint. Do I need to set the "AllowOverwrite" option in the images segment?

cat /etc/apache2/sites-available/default-ssl
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride AuthConfig
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride AuthConfig
                Order allow,deny
                allow from all
        <Directory /var/www/wiki/images>
                Options -Indexes

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/ssl_access.log combined

        Alias /doc/ "/usr/share/doc/"
        <Directory "/usr/share/doc/">
                Options Indexes MultiViews FollowSymLinks
                AllowOverride None
                Order deny,allow
                Deny from all
                Allow from ::1/128

        #   SSL Engine Switch:
        #   Enable/Disable SSL for this virtual host.
        SSLEngine on

        SSLCertificateFile      /etc/apache2/ssl/cert/server.cer
        SSLCertificateKeyFile   /etc/apache2/ssl/cert/server.key
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        BrowserMatch "MSIE [2-6]" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
        # MSIE 7 and newer should be able to use keepalive
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown


Roemer2201 (talk) 19:47, 14 August 2012 (UTC)Reply[reply]

Error 500 suddenly appears[edit]

I'm using MW 1.18.0+PHP 5.2.17 on IIS. I've been using it for several months now with no problems. Suddenly for no apparent reason, I cannot upload files anymore. I get error 500 for regular upload file, and cannot open file error for import. What could be the reason? I checked php.ini and LocalSettings.php. They did not change and both allow uploading. Thank you Osishkin (talk) 06:02, 23 August 2012 (UTC)Reply[reply]

open_basedir restriction in effect[edit]

When uploading files I'm getting "File extension ".jpg" does not match the detected MIME type of the file ()." and when $wgVerifyMimeType = false; is set I get "An error was encountered when opening the file for ZIP checks." The first error showing in the log is

PHP Warning: is_file(): open_basedir restriction in effect. File(C:\Windows\Temp\phpC132.tmp) is not within the allowed path(s): (C:\inetpub\\live) in C:\inetpub\\live\includes\filerepo\backe nd\FSFile.php on line 42

I've tried adding C:\Windows\Temp to the open_basedir line in php.ini, but it doesn't seem to change anything. I've also tried everything I can find to change the temp folder to something else with upload_tmp_dir and others, but they also seem to not have any effect. I have IUSR and IIS_IUSRS set to full for testing on both temp directory and images directory with no luck. I'm at a complete loss as to whats going on. Any help would be greatly appreciated!

EXE uploads Administrators-only?[edit]

I would like to know, is it possible for administrators - and ONLY administrators - to upload EXE files? What can I add to LocalSettings.php that makes it so?

File name capitalization[edit]

It seems that mediawiki capitalizes all files, and all I could find to prevent that is to disable this feature for article titless. Is there a way to keep filenames as they are, but capitalize articles? We want to store certain files that require exact filenames.


Fedora 19 and selinux[edit]

Some of the commands I've just used to enable file upload:

grep bash /var/log/audit/audit.log | audit2allow -M mypol
setsebool -P httpd_setrlimit 1
grep mysqld /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp
semanage fcontext -a -t httpd_sys_rw_content_t 'images'
restorecon -v 'images'
setsebool -P httpd_unified 1

You can use SELinux Troubleshooter (on System menu) to fix detected problems

Images in skins/common/images[edit]

I have just inherited a MediaWiki and a fair number of images are in the regular images directory, but some are duplicated in skins/common/images. I'd like to clear those out, but I'm concerned that I don't know how they got there in the first place. Any ideas?

BZ2 Does Not Match Detected MIME Type[edit]

My Wiki is invitation only, so I trust the editors enough to allow ZIP uploading. I followed the guide here to add the extension in and remove it from the blacklist and everything works great.

However, several users want to upload UNIX/LINUX archives using BZip2. I've added "bz2" to the $wgFileExtensions array and MediaWiki allows for them to be selected, but when I hit "Upload" I get back:

File extension ".bz2" does not match the detected MIME type of the file (application/x-bzip2).

I'm pretty confident that the BZip2 file has the correct headers and isn't corrupt in anyway, as I have compressed it myself using two separate programs. I've looked at $wgMimeTypeBlacklist, but it doesn't prevent bzip2 by default. Anyone have any luck with this? --TheAlmightyGuru (talk) 21:59, 16 September 2014 (UTC)Reply[reply]


A reader named Duncan was able to put me in the right direction for this problem. The problem lies in the ./includes/mime.types file. My existing line read:

application/x-bzip gz bz2

Which considers BZip2 files as regular BZip files. I fixed it by changing the line to read:

application/x-bzip2 bz2

Now, BZip2 files are identified as a mime type of BZip2. GZ files are already covered in a line further down in the file, so it's safe to remove it. I also added the following line to my ./includes/

application/x-bzip2	[ARCHIVE]

So the Wiki would be able to accept BZip2 files.

This may not be the most correct way of doing it, but it did allow my users to upload bz2 files properly. If anyone has a better way, please post here.

Mediawi Image uploads succeed, but can't view images[edit]

I'm having a trouble with a new, clean install of Mediawiki 1.23.9 (advanced one-click method in hostgator's QuickInstall). Images can be successfully uploaded, but they are not usable in wiki pages: attempting to click and view the just-uploaded image yields an Internal Server Error (500).

On a wiki page where the image is embedded, the image simply doesn't display- instead I just see the image title. How can I fix this and make uploads usable on wiki pages?

Possibly helpful info: - Turning off short URLs does not fix this problem- it just clarifies that the internal error is a 505. - ImageMagick, file upload.. etc are all set to true. - Via SFTP, I can download the image (and thumbnails). The files aren't corrupt. (Mediawiki even reads the image metadata correctly- it just doesn't display the image!) - The permissions on the "images" directory (and subfolders) are drwxr-xr-x, the default setting.

The file size is 600 KB, well below the upload limit. A smaller image gives the same problem.

I tried EVERYTHING, I'm desperate. Please help for me and any future person that gets the same problem!

Have you solved it?--Jipre (talk) 10:53, 9 September 2015 (UTC)Reply[reply]

Cannot open .oft or .msg files in Internet Explorer 11, but can with Firefox[edit]

Hey there, I've scoured the internet on this topic. I may have even came across the answer, but if I did - I couldn't understand it.

I've enabled file uploads for a few files (specifically .oft - a Microsoft Outlook 2013 template). I've successfully uploaded them. When I open it in Firefox, it opens great. When I open it in Internet Explorer, I get something like this:

ÐÏ�ࡱ�á>�þÿ ������þÿÿÿ�ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿRoot Entry��ÿÿÿÿÿÿÿÿ� Á²ô¹UÏ� À*__properties_version1.00�ÿÿÿÿÿÿÿÿÿÿÿÿLÐ�__nameid_version1.0(��ÿÿÿÿÿÿÿÿ�ðK²ô¹UÏ� Á²ô¹UÏ�__substg1.0_0E04001E*��ÿÿÿÿ�ÿÿÿÿþÿÿÿ�ýÿÿÿÿÿÿÿÿÿÿÿ���7E �����@������������ !"#$%&

Imagine that, except about 1,000 lines worth. What am I doing wrong? Thanks!

You're doing nothing wrong. IE just can't handle .oft files. -- 18:14, 17 May 2015 (UTC)Reply[reply]

Mediawiki seems to associate a bogus MIME type with these files: MIME-Typ: chemical/x-mdl-rgfile. At my site, we're only able to open them via Firefox if right-clicking and saving the file (else 0kB). In IE11, additionally you need to change the .htm extension to .oft, then IE11 can delegate them to Outlook. MichaelKesper (talk) 14:11, 13 January 2016 (UTC)Reply[reply]

Upload Files Into Subdirectories[edit]

I already have hundreds of files and images set in my site directory structure, i.e., Media/Photos, Media/Documents. I can set the default upload directory to "Media" but is there a way to use the subfolders I already have? I've found and installed the UploadLocal extension to "upload" all of these files that are already on the server into MediaWiki, but I'd really like to retain the directory structure I already have because of previous usage and links to these files. I really don't want to start from scratch on THAT and try to catch all of those -- and I don't want all of these files in one directory. These files are used by several different programs and website areas -- I need to retain these directory structure paths.

Is there a file upload configuration that will allow me to specify the use of these subdirectories? Or is there an extension that would allow me to select a subfolder when uploading a file? I was able to change upload directories to test the UploadLocal extension, and it will put them where I want them, but I can't access them through MediaWiki after that, of course, with the upload path of only "Media". Thanks.

ZIP checks error[edit]

I'm using a localhost wiki, but every time I upload an image, I get this error: An error was encountered when opening the file for ZIP checks.

How do I fix it? I am running MediaWiki 1.25.2, PHP 5.6.11 (cgi-fcgi), MySQL 5.6.25-log, and IIS 7 on a Windows 7 Home Premium.

-- 23:48, 17 December 2015 (UTC)Reply[reply]

Media links yield wrong version of uploaded files[edit]


We have a corporate wiki and been having some issues with uploaded files with multiple versions.

General use case is this: Someone uploads a certain file1.docx to the wiki, creating a link to it using [[Media:file1.docx]] on a certain article/page. So far, so good. You can click the resulting link to download the file (call this the original, version 1).

As time goes by, another user decides to update file1 so he goes to /File:file1.docx and clicks "upload a new version of this file". He uploads a new version (call it version 2) of the file and everything seems to be ok, as both versions appear on the file's version history.

Now, if you try to download the file again (either from the article linking to the file, or from the file description page itself) you'd expect to get the second version of the file, however, we keep getting the original one (version 1) instead.

It seems to be some sort of cache issue, but I am not familiar with the MediaWiki code to look any deeper.

Here's our setup:

  • Linux server on shared hosting (dreamhost)
  • MediaWiki 1.26.2
  • PHP 5.6.29 (cgi-fcgi)
  • MySQL 5.6.25-log
  • Installed Extensions: CategoryTree; Cite; DynamicPageList3; EmbedVideo; NumberFormat; ParserFunctions; SimpleMathJax; Google Analytics Integration

Any help, comments, ideas will be greatly appreciated.

Thanks in advance

--Rbirmann (talk) 17:15, 30 January 2017 (UTC)Reply[reply]

UPDATE: This error seems to be happening only on files with non-ascii titles. Still investigating.
--Rbirmann (talk) 18:27, 30 January 2017 (UTC)Reply[reply]
UPDATE: I tried to replicate this error on my user page here on this wiki, but failed. The uploaded file (FILE_NON-ASCII_TITLE_Ã Ó é ü TEST FILE.pdf) worked perfectly. Tried the exact same thing on our wiki with both .pdf and .docx files and it also worked, so I am guessing it is not related to the non-ASCII characters (still inconclusive, however). Bottom-line is we have this error in some files on our wiki, but can´t really seem to replicate it deliberately :(
--Rbirmann (talk) 19:43, 30 January 2017 (UTC)Reply[reply]
If you open the file using private browsing, if you get the old version then it's being cached on the server, otherwise it's being cached on your browser. In the second case, the server may be sending too far expires: HTTP headers causing browser to cache the URL a very long time. --Ciencia Al Poder (talk) 21:10, 30 January 2017 (UTC)Reply[reply]

reused reference[edit]

Tried to reuse reference <ref name="kavoir" /> in section Manual:Configuring_file_uploads#Set_maximum_size_for_file_uploads but there's some weird interaction between the ‎<translate> tags I don't understand. Can someone fix that? Thanks. NE Ent (talk) 18:52, 7 March 2017 (UTC)Reply[reply]

another way of uploading[edit]

Is there another way of uploading a file to the wiki when the server doesn't work with the convert command? User: Valamesh 14:21, 9 October 2017 (UTC)Reply[reply]

Convert is used for thumbnailing. I think you can disable convert entirely (set $wgUseImageMagick to false) and uploads should work. However, no thumbnailing would be done. --Ciencia Al Poder (talk) 09:15, 10 October 2017 (UTC)Reply[reply]

small uploads works, large don't[edit]

I have increased the upload limit to 500mb. When i upload smaler files > 6mb everything works fine, but when i upload larger files (30mb, 100mb etc..) the site stops working and chrome shows "ERR_SPDY_PROTOCOL_ERROR". Sadly the wiki itself or php don't show any errors. My wiki runs on IIS 10, wiki version 1.29.1 and i have done the "Image Authorization".

Edit: i have found the error, i had to increase the maximum allowed upload file in the iis itself.

MediaWiki also has a $wgMaxUploadSize option statement[edit]

The statement, MediaWiki also has a $wgMaxUploadSize option, but that is currently not enforced for normal uploads (when uploading a local file). The only way of restricting the upload size is through the use of modifying the php configuration., does not appear to be a true statement. I have observed on MW 1.27 leaving this unset and uploads greater than the default 100MB value fail. I took the value up to match the php.ini settings which were set higher than 300MB and the upload worked. Can we update this statement if it is no longer valid. Or update it if it is valid for older versions of MW? Thanks Hutchy68 (talk) 23:25, 25 October 2017 (UTC)Reply[reply]

Reading further down the page, there is even a reference to update $wgMaxUploadSize to upload up to 2GB files along with the server setttings. So these two pieces of information are at odds with each other.

(SOLVED) File uploads and Nginx: "mwstore://local-backend/local-public/" blocked[edit]

I've enabled file uploads on my MediaWiki 1.33 and Nginx 1.17 environment, but I always got an error message saying that mwstore://local-backend/local-public/x/y/filename was blocked. I tried a lot of things, such as change /image folder ownership and permissions, LocalSettings.php variables etc. Nothing worked. So, I just defined /images folder owner as apache (is it a problem from MediaWiki code?) and now I can upload files!

Upload from URL (Sideloading) time out[edit]

During sideloading, the curl timeout is default and larger files will not load.

Setting $wgCopyUploadTimeout to 300 will increase this to 300 seconds.

This really should be added on the main page for completeness.

Change upload directory[edit]


Not reporting a problem, but a solution I found.

I'm running MediaWiki on a Raspberry Pi and wanted to place the images folder on an external hard disk in order to save space on the small micro SD card. I found the documentation very poor and confusing and no helpful advice on SO or anywhere else, however I managed to solve this problem and would like to share my solution. I'd welcome any feedback on whether my solution is good or not.

Let's assume that the external disk is mounted at /mnt/externaldisk .

Here's what I did:

  1. Create a folder called mediawiki-images on the external disk.
  2. chown www-data:www-data /mnt/externaldisk/mediawiki-images
  3. chmod 755 /mnt/externaldisk/mediawiki-images
  4. Add the line $wgUploadDirectory = "/mnt/externaldisk/mediawiki-images" to my LocalSettings.php.
  5. Add the following to the Apache VHost configuration in /etc/apache2/sites-available/mediawiki.conf:
Alias /images /mnt/externaldisk/mediawiki-images
<Directory "/mnt/externaldisk/mediawiki-images">
    Require all granted
  1. Restarted the web server

So far, I have successfully uploaded, viewed and deleted multiple files.

If this is a reasonable approach, I'd love to see it documented somewhere.

Thank you for your time. 2001:9E8:E5CD:6E00:3915:497A:62:AB08 22:26, 14 February 2023 (UTC)Reply[reply]