Enable MediaWiki uploads by setting $wgEnableUploads = true; in LocalSettings.php, but that switch works only when PHP uploads, the temporary directory, the MediaWiki upload directory, permissions, file-type rules, and size limits are configured correctly. The safe order is: prepare the server, protect the upload directory, enable the feature, grant the right user permission, allow required extensions, then test Special:Upload.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What the upload setting does
$wgEnableUploads controls whether MediaWiki exposes its upload functionality. MediaWiki 1.5 and later read this setting from LocalSettings.php. Add the following line, or change an existing false value:
As an Amazon Associate I earn from qualifying purchases.
$wgEnableUploads = true;This setting does not create a directory, change PHP limits, grant every user permission to upload, or make unsafe file types acceptable. Those are separate controls. Treat the setting as the final application-level switch after the server is ready.
Prerequisites to check before changing LocalSettings.php
PHP must accept HTTP file uploads
In the PHP configuration used by the web server, confirm that file_uploads = On. Check the configuration for the web-facing PHP process, not only the command-line PHP installation; those can load different configuration files. If PHP’s open_basedir restriction is enabled, its allowed paths must include both MediaWiki’s upload directory (normally $IP/images) and PHP’s temporary upload directory.
After changing PHP configuration, reload or restart the relevant PHP service and web server according to your platform. A command-line check alone cannot prove that the web request path has picked up the new value.
The upload directory must exist and be writable
MediaWiki normally stores uploaded files below the installation’s images directory. Older installations may use an uploads directory instead. The configured path is available as $wgUploadDirectory when a wiki has moved it from the default.
The web-server account running PHP must be able to create files and subdirectories there. The MediaWiki upload manual recommends permissions equivalent to 755; use ownership and access-control settings appropriate to your operating system rather than making the directory world-writable. Uploaded files should not be executable.
Keep the directory protected from script execution
Copy and preserve the protection supplied with the MediaWiki upload directory. If you move the directory, apply equivalent rules in the new location and in the web server’s configuration. The goal is that a visitor may retrieve an allowed uploaded file but cannot upload a server-side script and then execute it through the web server. This is a security boundary, not an optional hardening step.
Also decide whether directory listing should be disabled. Listing is not the same as script execution, but hiding an index of stored files reduces accidental disclosure when direct browsing is possible.
Step-by-step: enable uploads
- Back up the configuration. Make a copy of
LocalSettings.phpand note the current PHP and web-server configuration so you can roll back a change. - Confirm PHP support. Set
file_uploads = On. Ifopen_basediris enabled, include both the MediaWiki upload directory and PHP’s temporary directory. - Prepare storage. Confirm that the
imagesdirectory, or the path in$wgUploadDirectory, exists and is writable by the web-server process. Keep the supplied access protections in place. - Enable the feature. Add this line to
LocalSettings.php:
$wgEnableUploads = true;- Check the upload right. The
uploadright is granted to logged-in users by default in the documented standard setup. If you want a narrower policy, configure$wgGroupPermissionsso only a selected group has that right. - Configure formats. Add only the extensions your wiki needs with
$wgFileExtensions, while retaining MIME and prohibited-extension checks. - Align limits. Compare PHP, MediaWiki, and web-server request-size limits. The smallest applicable value wins.
- Test the interface. Sign in and open
Special:Upload. Upload a harmless test file in an approved format, then confirm that it is stored and displayed as expected.
Granting and restricting upload permissions
MediaWiki separates the feature switch from user rights. A user needs the upload right to submit a file. In the standard documented configuration, logged-in users receive that right. Anonymous visitors do not automatically gain it simply because uploads are enabled.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →To limit uploads to a particular group, use the group-permission configuration in LocalSettings.php. The exact group name and policy are yours to choose; the important distinction is that enabling uploads does not require giving upload access to every account.
Replacing an existing file is a separate capability. The reupload right controls replacement, so a policy that permits new uploads does not necessarily permit overwriting files already present in the wiki.
Allowing PDF, ZIP, and other extensions
MediaWiki checks both the extension and the detected MIME type. To add an extension, append it to the allowed list, for example:
$wgFileExtensions[] = 'pdf';Use the same pattern for another required extension, changing only the value. Add formats one at a time and test each one. An extension on the allow-list can still be rejected if its MIME type is prohibited, cannot be detected correctly, or conflicts with the prohibited-extension configuration.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallDo not solve a rejected file by broadly disabling strict extension checks or weakening $wgProhibitedFileExtensions. The MediaWiki documentation warns that such changes can expose users to malicious uploads. A public wiki should keep MIME verification and strict checks enabled unless an administrator has a specific, reviewed reason to change them.
Upload-size limits: why a file can be rejected
There is no single universal limit. An upload must fit under every limit applied by PHP, MediaWiki, and the web server or proxy. The effective ceiling is therefore the smallest applicable value.
| Layer | Setting or documented value | What it controls |
|---|---|---|
| PHP | upload_max_filesize: 2 MB default documented by the MediaWiki upload manual |
Maximum size of an individual uploaded file accepted by PHP. |
| PHP | post_max_size: 8 MB default documented by the MediaWiki upload manual |
Maximum size of the complete POST request, including the file and form data. |
| MediaWiki | $wgMaxUploadSize: 100 MiB in the current MediaWiki core configuration schema |
MediaWiki’s own maximum upload size. |
| Web server or proxy | Configured request-body limit | Whether the request is accepted before PHP and MediaWiki process it. |
The PHP figures are documented defaults, not a recommendation for every installation. If you intend to accept larger files, raise the relevant PHP values, set a MediaWiki limit that does not exceed them, and adjust any nginx, Apache, IIS, reverse-proxy, or hosting control-panel request limit. Keep post_max_size larger than the maximum file size because the request also contains form fields.
After changing a limit, test a file just below the intended ceiling. A browser message can be misleading when the web server rejects the request before MediaWiki has a chance to display its own error.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Using Special:Upload and image processing
Once PHP, storage, permissions, rights, file rules, and limits are aligned, users upload through Special:Upload. The form may ask for the file, a destination name, a description, and licensing or attribution information according to the wiki’s configuration and policy.
Uploading an image and generating resized versions are separate operations. On-the-fly resizing and thumbnail creation require a working ImageMagick installation when those conversions are enabled. The web-server process must be able to execute the configured conversion command and write the generated output. A successful original upload therefore does not guarantee that thumbnails will work.
Security checklist for a public wiki
- Keep the upload directory non-executable for uploaded server-side scripts.
- Preserve the supplied
.htaccessprotections, or implement equivalent rules in the web server when the directory is relocated. - Keep MIME verification enabled.
- Use a narrow allow-list in
$wgFileExtensions; add only formats with a clear editorial need. - Do not weaken
$wgProhibitedFileExtensionsor$wgStrictFileExtensionsmerely to make one troublesome file pass. - Give the
uploadright only to the groups that need it, and treatreuploadas a separate privilege. - Use filesystem ownership, permissions, ACLs, and (where applicable) SELinux policy so PHP can write uploads without granting unnecessary access elsewhere.
- Review whether directory indexing is exposed and disable it when direct listing is not part of the site’s design.
The central risk is execution, not just storage. An upload directory that lets an end user place and execute a script can expose the web directory and damage the wiki or the wider site.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshooting by symptom
Special:Upload is missing or says uploads are disabled
- Confirm that
$wgEnableUploads = true;is present in the activeLocalSettings.php, with valid PHP syntax. - Verify that you edited the configuration used by this wiki, especially when several installations share a server.
- Confirm that the account has the
uploadright. - If the interface still looks unchanged after a correction, clear relevant browser and application cache layers, then sign in again.
Permission denied, failed write, or an upload that never completes
- Check ownership and permissions on
imagesor the configured$wgUploadDirectory. - Check that PHP’s temporary upload directory exists and is writable by the PHP process.
- If mandatory access control is enabled, inspect SELinux or equivalent ACL and policy denials.
- Check available disk space and inodes; a writable directory cannot accept files when the filesystem is full.
“File type not allowed”
- Check that the extension appears in
$wgFileExtensions. - Check that it is not listed among prohibited extensions.
- Check the MIME type detected for the actual file, not just the name shown in the file manager.
- Confirm that the user has the
uploadright.
Do not respond by globally disabling extension checks. If the file is legitimate but misdetected, identify the MIME-detection problem and make the narrowest reviewed correction.
Free tools Windows power users keep installed
One-click scans. No signup required.
“File is corrupt” or “incorrect extension”
These messages commonly indicate a mismatch between the file’s contents and its name, or a failure in MIME detection. Re-save or obtain a valid copy of the file, verify its actual format, and check the server’s MIME-detection configuration. Broadly disabling strict checks removes an important security control and is not a safe general fix.
“File is too large”
Compare all four layers: PHP’s upload_max_filesize, PHP’s post_max_size, MediaWiki’s $wgMaxUploadSize, and any request-size limit in nginx, Apache, IIS, a reverse proxy, or a hosting platform. Raise the smallest relevant limit, reload the service that owns it, and test again. If the web server rejects the request first, MediaWiki may not log a useful application-level error.
Original uploads work but thumbnails fail
Install and configure ImageMagick for the required conversions. Then confirm that the web-server account can execute the configured command and write thumbnail output. Review the web server and MediaWiki logs for command-path, permission, and policy errors.
Local uploads versus a shared repository
Keeping files on the wiki’s own server gives the wiki’s administrators direct control over storage, access policy, retention, and backups. It also makes them responsible for disk capacity, upload-directory security, and every file served by the site.
Recommended Free Tools
A shared repository such as InstantCommons provides access to freely licensed Wikimedia Commons files without storing each file locally. That can reduce local storage and avoid a separate upload workflow, but it changes who controls the source files and introduces licensing and availability considerations. Choose between local uploads and a shared repository by evaluating:
- Who owns and administers the files.
- Whether files must be stored locally or can remain in the shared repository.
- Licensing, attribution, and content-policy requirements.
- Local storage, bandwidth, backup, and security responsibilities.
- Whether contributors need single-file uploads, batch imports, or both.
Single-file and batch workflows
Special:Upload is the straightforward choice for occasional individual files. For larger editorial operations, the official MediaWiki documentation lists UploadWizard, MsUpload, and SimpleBatchUpload as extension options. Their required MediaWiki versions and maintenance status differ, so check compatibility against the exact version installed on your wiki before enabling one.
Batch tools do not remove the underlying obligations: every file still needs an acceptable type, a safe destination, sufficient size limits, and a policy for attribution and licensing. Test a small batch in a non-public or restricted environment before processing a large collection.
Production verification checklist
- Open the wiki through the same hostname and protocol that normal users use.
- Confirm
Special:Uploadis visible to an account that should have theuploadright. - Upload a small approved file and verify that it appears in the file history.
- Attempt a deliberately disallowed extension in a controlled test to confirm that policy checks reject it.
- Test a file near, but below, the configured size ceiling.
- If the wiki creates thumbnails, upload an image and verify both the original and a generated thumbnail.
- Inspect the stored upload path and confirm that an uploaded script cannot execute as server-side code.
- Review web-server, PHP, and MediaWiki logs for warnings that a successful small-file test might not reveal.
- Document the final PHP values, MediaWiki settings, directory path, ownership, and group-right policy for future administrators.
Bottom line
Set $wgEnableUploads = true; only after the PHP upload path and protected storage directory are ready. Then grant the upload right deliberately, allow only needed extensions, keep MIME and prohibited-extension checks enabled, and make every size limit agree. Most failed uploads are caused by one of those surrounding controls rather than by the MediaWiki switch itself.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
