Mediawiki internal error

You see a blank page

A blank white page indicates a PHP error which isn’t being printed to the screen.
To force this, add the following lines to the LocalSettings.php file, underneath the <?php:

error_reporting( E_ALL );
ini_set( 'display_errors', 1 );

You can also set a value for error_log in PHP.ini and read the PHP error log to find out what’s going on.
In some cases, PHP errors might also be recorded in the web server error log.

Error reports may include:

• «Warning […] It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function.» Check if date.timezone = is set correctly (or set at all) in php.ini.
• Certain files may be reported as missing (e.g. when the media folder in your /includes folder is no longer present, you may receive the message that a required imaging process «failed to open stream»). Check the original installation package at MediaWiki (make sure to consult the appropriate version) to see if this is the case. If so, simply copy the missing files from the package into your MediaWiki directory. It may be necessary to refresh the cache and restart the webserver afterwards.
• MySQL socket cannot be found. If LocalSettings.php is set to the correct MySQL socket but php.ini is not, it may result in a blank screen with no error output from the webserver or PHP. The fix is to update the mysql.default_socket entry in the php.ini file.

Many people report blank pages in recent versions after submitting articles to their new wiki.
A likely cause is the memory limit in default php installations (usually 8 MB).
Please check your PHP and/or Apache error logs.
To modify this setting edit /etc/php.ini and increase the «memory_limit» setting.
For example to raise it to 32 MB replace the existing text with memory_limit = 32M.
Make sure to restart your webserver after you have changed this value.

The memory limit may also have been set in your LocalSettings.php file.
Scan for the line containing the memory_limit setting and increase as needed.
20M may not be enough if you are running version 1.15.1.
Change it to e.g. «memory_limit = 32M«.
This change does not require you to restart Apache.

If the page just hangs loading during some time (like 30 seconds) doing a specific action, and then it results in a blank page or HTTP 500 error, the problem is a timeout connecting to some server.
This may be the database server, or if it happens doing a specific action, the mail server (if you have configured email settings).
If it’s the email server, check if you can connect to it from the server running MediaWiki, for example, running the Telnet client to the server and port configured on $wgSMTP and seeing if it can connect.

If you can see the page contents briefly, and suddenly the entire page goes blank, most likely the problem is caused by the presence of a document.write, document.writeln, or document.open JavaScript instruction in one of the scripts of the wiki.
You can check if that’s the case if you open your browser console (hit F12) and reload the page.
If the network tab returns a HTTP 200 status, and the transfer is of several kilobytes, it’s very likely this is the problem.
These are legacy methods of the Document interface that cause the entire page to become blank if it’s used outside of the page HTML, and it may be present on the wiki’s JavaScript pages.
Their usage is strongly discouraged, as indicated by the HTML specification itself.
You can disable JavaScript on your browser, or set $wgUseSiteJs and $wgAllowUserJs to false to disable those scripts until you fix the broken scripts.

MediaWiki Errors

All pages have no content, but when editing a page the wiki text is there

Optionally with those error messages:

PHP Warning: preg_replace(): Compilation failed: group name must start with a
  non-digit at offset 4 in /var/www/wiki/htdocs/includes/MagicWord.php

This is caused by a change in PCRE 8.34, which no longer allows names of capturing groups to start with a digit.
You need to update MediaWiki to a supported version.
See Updating to PCRE 8.33 or Higher.
The problem is solved in all currently supported versions of MediaWiki (see task T60640).

See report:
Topic:Rz2zo0m88rrxqrfn, Thread:Project:Support desk/MediaWiki don’t work with PCRE 8.34 (2)

Image Thumbnails not working and/or appearing

This section lists problems and solutions relating to thumbnails not rendering or displaying.

Error creating thumbnail: File missing:

This might happen due to wrong values of global variables as explained in:

• Manual:$wgUploadDirectory
• Manual:$wgUploadPath
• Manual:$wgScriptPath

Decimal-point in srcset locale bug

If image thumbnails simply don’t appear, and there’s no error visible on those pages, look at the HTML source of the page and search for «srcset«.
If you find something like <img ... srcset="/images/thumb/File.png/600px-File.png 1,5x, /images/thumb/File.png/800px-File.png 2x">, where it appears 1,5x instead of 1.5x, the problem is caused by task T181987, and you should add this to LocalSettings.php:

setlocale(LC_NUMERIC, "C");

Be sure there’s no $wgShellLocale defined in your LocalSettings.php, or add also this:

$wgShellLocale = "C.UTF-8";

SVG

First, determine your $wgSVGConverter setting.
By default, it is set to use ImageMagick for conversion.

Using ImageMagick

You need at least ImageMagick 6.x.x.
Ensure that your $wgImageMagickConvertCommand variable is valid.
Common settings are:

$wgImageMagickConvertCommand = "/usr/bin/convert";
$wgImageMagickConvertCommand = "/usr/local/bin/convert";

If it does not work, try setting $wgSVGConverterPath.

$wgSVGConverterPath = "/usr/bin";
$wgSVGConverterPath = "/usr/local/bin";

Shared hosts may provide different ImageMagick versions to meet the needs of different users.
Please use version 6.x.x.

• To determine the version of ImageMagick, search the help files of your host provider, or use /usr/bin/convert --version or /usr/local/bin/convert --version to detect.
• On GoDaddy Linux shared hosts, «/usr/bin/convert» for Version 5.5.6 and «/usr/local/bin/convert» for Version 6.2.8.

If generating thumbnails with ImageMagick fails with a web server error log message like «Memory allocation failed» or «/bin/ulimit4.sh: Segmentation fault /usr/bin/convert …», the $wgMaxShellMemory value may need to be increased.

When the path is missing non-ASCII characters

• Check if UTF-8 locals are available on your server by running locale -a
• When it’s not available run locale-gen en_US.utf8 or put in the locales with UTF-8 for your country and change the value for $wgShellLocale according to this.

When using IIS/FastCGI on Windows, the guest account that is used also needs execute permission on C:WindowsSystem32cmd.exe otherwise you’ll receive an «Unable to Fork» error.

Using Batik

MediaWiki places time and memory limits on shell commands under Linux.
If you receive the error «Error occurred during initialization of VM, Could not reserve enough space for object heap, Could not create the Java virtual machine.», try increasing the value of $wgMaxShellMemory.

Using rsvg

On some Linux and BSD installations rsvg is renamed:

Instead of setting (default)

$wgSVGConverters = array( 'rsvg' => '$path/rsvg -w$width -h$height $input $output' );

you would like to set

$wgSVGConverters = array( 'rsvg' => '$path/rsvg-convert -w $width -h $height -o $output $input' );

JPEG

Symptom:
This error message within a grey box:

Error creating thumbnail: Invalid thumbnail parameters

One cause: the number of pixels in the original image exceeding $wgMaxImageArea.
The default value 1.25e7 is too small for many modern cameras.
Too bad the diagnostic really doesn’t hint at the problem.

You can increase the value of $wgMaxImageArea or switch to using ImageMagick which evades this restriction (set $wgUseImageMagick and $wgImageMagickConvertCommand).

Large images can take significant processing time.
It may be good policy to cap the size of images.

JPEG (using GD)

Symptom:
This error message within a grey box:

Error creating thumbnail: Incomplete GD library configuration: missing function imagecreatefromjpeg

Some PHP 4.x and 5.x versions of PHP have a bug where libjpeg is detected but not enabled during the ./configure step; this is fairly prevalent on Red Hat/RHEL/CentOS systems.
If you don’t want to use ImageMagick, the fix for this is to recompile PHP.
First, find out (from phpinfo()) what the existing ./configure switches were, and add --with-jpeg-dir before --with-gd.

make clean
./configure --with-various-switches --with-jpeg-dir --with-gd --with-more-switches
make
make test
# switch to root
make install

Afterwards, restart the webserver (for Apache on Red Hat: service apache stop then service apache start ).
To test, simply view the File:… page again (no need to upload again).
For more information see the comments on PHP: imagecreatefromjpeg (function synopsis)

Unable to save thumbnail to destination

If you get the error «Error generating thumbnail / Error creating thumbnail: Unable to save thumbnail to destination» and the $wgUploadDirectory directory has the correct permissions (at all levels), check that $wgTmpDirectory actually exists.
(Unlike some path variables such as $wgCacheDirectory, $wgTmpDirectory is not created at runtime.)
A more detailed error message may be available if you turn on logging with $wgDebugLogFile.

This error can also occur when read only mode ($wgReadOnly) has been set in LocalSettings.php.
You can try to remove $wgReadOnly to see if that solves the issue for you.

Error creating thumbnail Error code: 25

If you get «Error creating thumbnail Error code: 25» with ImageMagick, try increasing $wgMaxShellFileSize.

Manually adding thumbnail files

In situations in which it’s not feasible to create the thumbnails dynamically on request (e.g. for very large images, «Error creating thumbnail: unable to extend cache», «Error creating thumbnail: convert: no images defined», and similar), it is possible to manually add the thumbnail files.
This involves creating the smaller images in the desired sizes and uploading them to the thumb/ directory in $wgUploadDirectory.

For example, a file that has uploaded to:

images/f/f8/Foo.png

should have its thumbnails at:

images/thumb/f/f8/Foo.png/100px-Foo.png
images/thumb/f/f8/Foo.png/600px-Foo.png

The pixel size is the horizontal dimension.
An example Bash script for creating thumbnails is available at Phabricator:P7049.

Error creating thumbnail: Error code: -1 on OVH mutualized hosting

For unidentified reason, creation of thumbnails on some mutualized OVH hosting are failing with this error, even if running the command in SSH shell works.

Solution is to specifically prevent from using ImageMagick by setting $wgUseImageMagick to false in LocalSettings.php:

$wgUseImageMagick = false;

Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn’t work, try logging out and logging back in.

Content Limits

If your Apache server has the Hardened PHP patch, you may need to edit several variables in your /etc/php.ini file if you wish to have wiki pages with large amounts of content.
In particular, consider the settings for varfilter.max_value_length, hphp.post.max_value_length, hphp.request.max_value_length.
The default settings may limit your pages to less than 10k or 64k in size.

Another possibility is if your Apache server is using mod_security that could be interfering with MediaWiki.
You will need to turn it off for MediaWiki to work properly.

You have not specified a valid user name / Completely blank page edits and previews / Unable to upload

This is caused by something truncating or dropping POST data from the browser to the web server.

In at least one instance, this was caused by post_max_size and upload_max_filesize in php.ini being set too high (2048M).
Setting them back to more sane values (8M) fixed it.
Apparently, no POST data was actually making it through to MediaWiki.

In another instance, mod_auth_sspi was interfering with http posts to MW.
Using FireFox and entering domain credentials would work fine, but MSIE would fail.
This is a known defect in mod_auth_sspi 1.0.4.

You have a few options to make this work:

• Set SSPIOfferSSPI off ← users will get prompted and have to enter domain credentials, same as BASIC mode
• Set SSPIPerRequestAuth on ← I don’t see how this is a healthy configuration but it worked (except over the high latency connection I’m forced to contend with)
• Downgrade to 1.0.3 but it’s basically the same as #2 above.

The wiki appears without styles applied and images are missing

If the wiki looks fine if you browse it from the same server where it’s being hosted but it appears without CSS styles applied (no colors, no backgrounds, no images, very minimal formatting, etc) if you access it from other machines (or some of them), the most probable cause is that the server is having problems with determining the IP or host name that is being used to access it, or it’s misconfigured.
This causes URLs to styles and images to be generated using the loopback IP address 127.0.0.1, localhost, or a host name not known outside of the server.
You can see the source code of any page and check how URLs look like and what happens if you try to access them directly via your browser.

The solution is to manually specify the $wgServer variable to the host name that everyone will use to access the wiki.

If your wiki is being accessed from an internal network and an external one, you may need to use the external address for $wgServer.
Don’t forget the port number if you are using a non-standard port as may by the case if your ISP has blocked port 80 (Example: $wgServer = "http://example.domain.com:8080";)

If styles aren’t applied even when browsing the wiki from the server where it’s hosted, the problem may be a PHP error on the ResourceLoader load.php script.
Try to browse the load.php file of your MediaWiki installation with your web browser and see if it displays any errors or just a blank page (see #You see a Blank Page).
You should see a comment similar to /* No modules requested. Max made me put this here */.
If so, it may be a problem with the web server’s .htaccess file.

If you instead see a 404 Not found error, it may be a problem with the web server’s rewrite rules if you attempted to configure Short URLs.

If you’re getting 500 error responses from load.php urls, check the webserver’s error log files to get more information of the errors.
There seems to be a problem with some PHP versions and Gentoo that causes Apache to segfault.^[1]
This can also happen if you have APC enabled, setting apc.serializer=php in php.ini might help.^[2]

Since MediaWiki 1.23, you may end with a wiki with most of the Vector-specific skin styles, like sidebar placed at the end of the page.
That may be caused by a low pcre.backtrack_limit set up on some distributions like FreeBSD.
It’s known to have problems with values of 10000.
Increase that value to 100000, or the current default of 1000000.

Since MediaWiki 1.26, some skins, and specially Vector, may have this problem.
If you see the error Internal error Problematic modules: {«startup»:»error»} in the error console of your browser, most likely cause is the lack of permissions of MediaWiki to write to the default temp folder, either because PHP has no permissions to write to /tmp (C:WINDOWSTEMP on Windows), or because there’s an open_basedir restriction and that path isn’t included on it.
See task T119934.
You can also set $wgTmpDirectory if you’re unable to change permissions on the system’s default temp directory.

Error: invalid magic word ‘speciale’

If you get that error message after upgrading, you must run the rebuildLocalisationCache.php maintenance script with the --force option:

php rebuildLocalisationCache.php --force

Missing edit toolbar, JavaScript not working

Since MediaWiki 1.32, MediaWiki no longer has a «JavaScript-powered» wikitext toolbar built in. The old «bulletin board style toolbar», known as «the 2006 wikitext editor», has been removed, and instead sysadmins will be required to choose one (or more) of the several extensions available for this purpose if they need the functionality. The MediaWiki «tarball» releases have included the replacement extension for this, the WikiEditor extension aka «the 2010 wikitext editor», for many years now. Be sure this extension has been installed.

If JavaScript is not working (one of the symptoms is the edit toolbar not appearing when editing a page) it may be caused by a JavaScript error.
Open the error console of your web browser (usually by hitting F12), reload the page and see if any error message appears there.
If it displays an error, usually, setting $wgShowExceptionDetails would give you more information.
Sometimes the problem is that the system’s temp directory is not writable.
In that case, you can also set $wgTmpDirectory if you’re unable to change permissions on the system’s default temp directory.

If you get errors like Uncaught SyntaxError: Unexpected token < or Error: SyntaxError: syntax error (...) Source Code: <script (...), the cause is usually a hosting provider that is automatically injecting HTML code for tracking or advertising inside the load.php script, which is used by ResourceLoader to load the scripts and CSS used by MediaWiki.
Open a support ticket with your hosting provider asking them to disable that injection.
If that’s not possible, you should migrate your site to another hosting provider.
That usually happens on free hosting providers.

Every page displays a fatal error, Log shows «MagicWordArray::parseMatch: parameter not found»

Try rebuilding the Localisation Cache:

php maintenance/rebuildLocalisationCache.php

From this thread.

All uploads fail with the message «The file you uploaded seems to be empty…»

It may be caused by wrong rewrite rules when configuring Short URLs.
Try disabling them (and the related configuration variables of MediaWiki) to see if that solves the problem.

Another problem may be a limit imposed by the web server about how many data the server can receive on a single request.
See Manual:Configuring file uploads#Set maximum size for file uploads for some configuration variables.
If you have mod_security or suhosin installed, they may also be limiting the size of uploaded files, discarding the upload entirely without PHP noticing it.

Check also the upload_tmp_dir configuration directive from php.ini, and be sure that the folder has proper write permissions for the user account running PHP.
On Windows, this directive often points to C:WindowsTEMP, which may not be accessible in some circumstances.
In that case, you can set up a different temp folder like C:TEMP with proper permissions.
To discard other problems, give temporarily all permissions to that folder (on Windows, add the local user group «Everyone» with full permissions), and then restrict the permissions as needed once you verify uploads are working.

If all uploads fail with the message «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.», and in the Apache error logs you have entries like this:

Notice: Undefined index: tmp_name in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1153
Notice: Undefined index: size in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1140
Notice: Undefined index: error in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1167

This is a problem with the PHP version your server is using.
There have been several reports of this problem with PHP 5.3.8 on SLES11 sp2.
You may need to upgrade PHP or recompile it yourself.

WAMP/Apache on Windows: Some Special: pages are inaccessible

It may happen, on Windows installations under Apache, that some Special pages are inaccessible, giving a error, and in the logs you can see something like this:

[core:error] The given path is misformatted or contained invalid characters: [client 127.0.0.1] AH00127: Cannot map GET /wiki/Special:SpecialPages HTTP/1.1 to file

This can be caused by various PHP bugs.
One of them is when the wiki is installed in a NTFS junction.
If that’s not the problem, upgrading PHP to a newer version can help (see this forum thread)

Attempting to save an edit gives you a 403 Forbidden error, or you get redirected to the main page

This is a common issue for shared host which have mod_security enabled.
To know if it’s a problem with mod_security or not, create a simple test page and save it with a small text (something as simple as writing just a dot in the content).
If the edit is saved, but other edits aren’t, that’s caused by mod_security.
Ask your hosting customer support to disable it completely or the rules affecting your edits.

If even saving a very simple edit gets you redirected to the main page, or to the same page without the edit appearing, it may be a problem with how you’ve set up $wgServer or some other configuration variable that controls the path of the index.php script, or conflicts with rewrite rules in your webserver’s configuration.

Login page warns about cookies disabled

You may get a message like MediaWiki uses cookies to log in users.
You have cookies disabled.
Please enable them and try again..

If cookies aren’t disabled on your browser, it could be one of those problems:

• You have $wgSessionsInMemcached set to true but MediaWiki can’t connect to Memcached. Turn off this setting or check the Memcached configuration.
• A wrong cookie configuration. Configuration variables about cookies should work with their default values. Try to not override any of them.
• session_save_path() is not set correctly on the server, or the server doesn’t have permissions to write to that path.
• If you use some sort of caching proxy in front of MediaWiki, check that it doesn’t filter any cookie.
• session.referer_check() is wrongly set. You should normally leave it empty.

Setting a debug log should display any cookie received by MediaWiki, so it may be a first step to detect if cookies are actually received by MediaWiki or not.

MediaWiki does not function when magic quotes are enabled

Magic quotes was a feature in PHP that was deprecated in PHP 5.3 and removed in PHP 5.4.
If you get this error, you need to disable the magic quotes in your server setting.
See how to do it.

Discussions: Thread:Project:Support_desk/Problems_with_installing_mediawiki, Topic:S79xdn9u15xw55vj, Topic:Sdpbmy9q9e0ttp6k, Topic:S7g4rybniat2i36e, Topic:S6vqwk0tysl6m8lc

Error creating thumbnail: File with dimensions greater than 12.5 MP

It may help to increase $wgMaxImageArea to get rid of the problem (tried with MediaWiki 1.26.2).

Internal Server Error when opening any image

If images are not displayed on the pages, and manually opening the URL of any image results in an Internal Server Error page, the problem is most likely caused by the .htaccess file from the images directory.
This configuration file contains some rewrite rules to prevent old Internet Explorer versions from being affected by a cross site scripting vulnerability.
However, some hosts like strato.de prevents disallow the RewriteOptions directive in .htaccess, causing any request for a file in the images folder to fail with an error.
If you can’t enable rewrite rules on .htaccess file, you may need to comment-out or remove those lines from .htaccess, or the entire .htaccess altogether.
See this thread.

Category pages, Special:Whatlinkshere and file usage aren’t being updated

Information about pages contained in a category, links to other wiki pages and images embedded in pages are tracked in special tables.
The update of such tables is not done immediately after the edit is saved, but deferred to the job queue for performance reasons.
If it takes too long to update, you may need to adjust $wgJobRunRate, or try setting $wgRunJobsAsync to false in LocalSettings.php.
This can happen in some installations, especially since MediaWiki 1.27 (see task T142751).

Error: Could not open lock file for «mwstore://local-backend/local-public/./../image.png

Check that the «images» directory has permissions which allow writing.
For example: chown -R www-data:www-data images and chmod -R 777 images.
If you have SELinux enabled, this could also be problematic.

Notice: Did not find alias for special page ‘Foo’. Perhaps no aliases are defined for it? [Called from SpecialPageFactory::getLocalNameFor in …

You need to create an alias file.
So, put something like this in your extension file (e.g. /extensions/Foo/Foo.php):

$wgExtensionMessagesFiles['FooAlias'] = __DIR__ . '/Foo.alias.php';

Then create an alias file like this:

<?php
/**
 * Aliases for Special:Foo
 *
 * @file
 * @ingroup Extensions
 */
// @codingStandardsIgnoreFile

$specialPageAliases = array();

/** English (English) */
$specialPageAliases['en'] = array(
   'Foo' => array( 'Foo' ),
);

Make sure you don’t have a $wgMessagesDirs item with the same key.
Keys of $wgExtensionMessagesFiles which are also in $wgMessagesDirs will be skipped.

Warning: Invalid argument supplied for foreach() in ./includes/objectcache/SqlBagOStuff.php

Probably you just moved your wiki, and didn’t import your database, so it’s empty.

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please resubmit the form.

Please follow Manual:How to debug/Login problems.

Call to undefined method

If a MediaWiki extension shows this error after installing that MediaWiki extension, double-check that you downloaded the version or branch of that MediaWiki extension which matches the version or branch of your MediaWiki installation.

Unable to run external programs, proc_open() is disabled

The function has been disabled in php.ini.
This prevents using ImageMagick to resize images to create thumbnails.
Either contact your hosting provider, or try to use gd instead of ImageMagick by setting $wgUseImageMagick to false.

CAS update failed on user_touched for user ID ‘*’ (read from slave); the version of the user to be saved is older than the current version

There are several reasons for this error.
One simple one is if the content of the user_touched column of the user table is empty or is set to a time in the future.

You might want to check if the server’s time is set correctly and synchronized.
Also check the contents of that column and fill the column with valid content e.g. with this SQL statement:

UPDATE `user` SET user_touched='20230207235037'
WHERE HEX(
	user_touched
)='0000000000000000000000000000';
-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- 28 zeroes

Where the date is in YYYYMMDDHHMMSS format for the current date/time.
See phab:T247751.

Lua error: Internal error

A database query error has occurred. This may indicate a bug in the software.

If you recently upgraded MediaWiki, or recently installed or upgraded extensions, try running the update.php maintenance script.
(See also Manual:Upgrading.)

If that doesn’t help, then you really may have ran into a bug in the software.
Try to obtain more details about the query that fails (Manual:How to debug) and file a bug.

$wgSecretKey key is insecure, generated with mt_rand()

Your system does not support /dev/urandom so the key was generated with mt_rand().
See $wgSecretKey.

PHP Errors

Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)

Raise PHP’s memory limit in php.ini:

memory_limit = 64M      ; Maximum amount of memory a script may consume (32MB)

You can add a higher value for $wgMemoryLimit in LocalSettings.php.

ini_set('memory_limit', '20M');

This error can often happen for other reasons. Look for Unicode usage on systems that do not support it properly. Look for the filename and line and if you find that you are in a language translation section that uses non-ascii characters, strip out that section. If you have increased the RAM allocated to PHP to 512MB and *still* have the problem with the memory error, it is not likely a memory issue per-se.

Read here for more information on configuring resource limits in PHP.

Fatal error: Class ‘DOMDocument’ not found in xxxxxxxx/Preprocessor_DOM.php on line nnn

This error happens when PHP hasn’t been compiled with DOM support, or the DOM/xml extension is missing.

• Install the right php-xml package for your distro. Example: sudo yum install php-xml
• Alternatively, change the MediaWiki ‘preprocessor’ class in LocalSettings.php (see $wgParserConf)

$wgParserConf['preprocessorClass'] = 'Preprocessor_Hash';

Fatal error: Invalid opcode 153/1/8. in xxx/includes/cache/MessageCache.php on line nnn

That issue seems to indicate it’s a problem with a PHP code accelerator that doesn’t match the installed version of PHP or it’s outdated.
Try upgrading the accelerator.
report

Most likely, your text editor added a byte order mark (BOM) while you edited MediaWiki’s PHP files, but any other content before the opening <?php causes the same problem.
This usually happens with LocalSettings.php — but see error message for exact file.
Note that BOMs are invisible in most text editors.
To remove the BOM, edit the file with something better than Windows Notepad, but if you don’t really have time — open the file with it and choose Save as…, then choose «Unicode (UTF-8 Without signature) — Codepage 65001» as file type.

Strict Standards: date_default_timezone_get(): It is not safe to rely on the system’s timezone settings.

If you get Strict Standards: errors in the HTML output, that’s because your error_reporting configuration variable of PHP is set to E_ALL, but since PHP 5.4.0, E_STRICT became part of E_ALL.
E_STRICT are not errors, but warnings about code interoperability and forward compatibility of PHP code, and they shouldn’t be visible in production environments.

Just add your time zone to LocalSetting.php, e.g.

$wgLocaltimezone = 'Europe/Berlin';

The following does not work in all cases.
It may be better to put this in the php.ini which must be present in all affected directories.

You may turn of E_STRICT errors putting the following line of code inside your LocalSettings.php, or in case a line with the error_reporting function exists, replace it with:

error_reporting( E_ALL & ~( E_STRICT | E_NOTICE ) );

You can turn off PHP error reporting entirely using this instead:

See also: Setting error reporting in PHP.

If nothing works, please check at the start of your LocalSettings.php file:
If that error happened on the setup process, the LocalSettings.php that it generated could have included the error message at the top of it (example).
If that was what happened, edit the file removing everything before «<?php» and verify there’s nothing (even whitespace) before «<?php«.

Fatal Error: Cannot redeclare wfprofilein()

This could happen if you upgraded and you have a StartProfiler.php file in the root MediaWiki installation directory, probably because you enabled profiling in an old installation.
To solve the issue simply remove that file.

Warning: Inaccessible files

After your move, you might see PHP warnings that certain files could not be accessed.
This is most likely caused by task T37472:
The column md_deps in the module_deps table contains absolute file paths, which are used to locate the images and LESS files that CSS depends on.
These paths break when the wiki is, e.g., moved to another folder or another server.
Until this bug is solved, you can use this workaround to manually fix wrong entries in the module_deps table:

-- Update entries in module_deps table
SET @old='wiki.old-domain.org';
SET @new='wiki.new-domain.org';

UPDATE `module_deps` SET `md_deps` = REPLACE( `md_deps`, @old, @new );

This can be used to update wrong path segments and to fix the error.

A similar issue can happen when MediaWiki tries to read ResourceLoader messages.
In this case the solution is to truncate the according tables:

-- Truncate message related caches
TRUNCATE TABLE `msg_resource`;
TRUNCATE TABLE `msg_resource_links`;

Fatal error: Uncaught Exception: extension.json does not exist

If this error happens when you try to install an extension, it usually means that the extension still requires to use the native PHP require_once language construct instead of the newer wfLoadExtension() method.

Installation Errors

LocalSettings.php not readable

• On a Linux machine, use chown or chgrp to correct the file permissions of LocalSettings.php.
• On some Linux machines, temporarily disable SELinux by running the command sudo setenforce 0.

The installer is unstyled when installing under IIS

The installer is unstyled and instead of the stylesheet, /mw-config/index.php?css=1 shows this error message: «Less_Exception_Parser from line 447 of …vendoroyejorgeless.phplibLessParser.php: Less.php cache directory isn’t writable: C:WindowsTEMP»

Make sure that the webserver user, who by default is named IUSR, is allowed to access the C:WindowsTEMP directory.
At least read and write permissions are necessary.

Error selecting database wikidb: 1044 Access denied for user ‘username’@’localhost’ to database ‘wikidb’

You need to Grant permissions on wikidb.*.

GRANT ALL ON wikidb.* TO 'username'@'localhost' IDENTIFIED BY 'password';

or if your Web Server is on a different box than your DB server — you have to configure remote access to MySQL and grant differently

GRANT ALL ON wikidb.* TO 'username'@'192.168.0.x' IDENTIFIED BY 'password';

NOTE: Replace 192.168.0.x with your Webserver’s IP.
Also note that the apostrophes (‘) need to stay.

Database returned error «1142: CREATE command denied to user ‘username’@’localhost’ for table ‘user_properties’ (localhost)»

As above, or temporarily use the mysql root user.

Could not find a suitable database driver!

PHP MySQL support is not installed/enabled — See https://php.net/book.mysqli.
Depending on your operating system, you may need to install an additional package.
For example, on debian/ubuntu run sudo apt install php-mysql.

Filename Case Errors

If you are using a different FTP client than FileZilla to upload files to your server, be sure to configure the client to not force uppercase or lowercase filenames.
MediaWiki filenames are case-sensitive.

Incomplete Upload Errors

The MediaWiki package includes a lot of files, spread over dozens of directories.
Be careful when uploading.
If the transfer is interrupted, you might have missing or incomplete files.
You may have to retry your upload several times, especially if you have an unreliable connection.

403 Forbidden with Symbolic Links

If your webserver produces a «403 Forbidden error» page and you are using symbolic links, then make sure your Apache httpd.conf file has Options FollowSymLinks to allow symbolic links and that each directory leading up to your linked directory has +x permission for user running httpd.

HTTP 500 Internal Error during installation

If your webserver produces a «500 Internal Error» at the beginning of the install process, you may need to change the permissions on the mw-config directory to 755.
If you have changed the permissions for the config directory and still get an unwritable error try changing the owner to apache.

chown -R apache:apache /var/www/html/mediawiki/*

HTTP 500 Internal Error after installation

If you downloaded the MediaWiki code from Git, and after finishing the installation process, accessing your MediaWiki installation in the web browser produces a «500 Internal Error», go to the MediaWiki installation folder and running the following commands:

find . -type f -exec chmod 644 {} ;
find . -type d -exec chmod 755 {} ;

SELinux

Linux distributions which support SELinux (‘Security Extensions’) are becoming more widespread.
On such systems, PHP scripts will still be unable to write to the config directory, after you have set the normal file permissions.
You will also need to use the ‘chcon’ command to change the SELinux file type.

Required Advertisements on Hosted Sites

If you are running the MediaWiki software on a free site that requires banners or prefix advertising, this may cause MediaWiki not to work, and appear to only generate empty pages beyond the banner advertising.
You will have to contact your host to make them make their advertising compatible with MediaWiki, or choose a different host.

Debian, Apache2, and PHP

If you’re running the MediaWiki on Debian with Apache2 and PHP5, and have problems connecting to MySQL, e.g you get the following error message in your browser: (Can’t contact the database server: MySQL functions missing, have you compiled PHP with the —with-mysqli option?) try uncommenting: extension=mysqli.so in the /etc/php5/apache2/php.ini file.

If that does not work, try the following…

Check that MySQL module for php is installed:

dpkg --list | grep php-mysql

If you need to install the php5-mysql module enter:

apt-get install php-mysql

Then restart Apache2:

/etc/init.d/apache2 restart

‘user_password’ can’t have a default value

Ensure that MySQL is not running in strict mode.

Missing table prefix

If you are using a hosting service, the database name and database username may have an extra prefix (normally the userid given by your hosting provider).
For example, if you have created a database named db01 with username u01 and your userid is ocom (given by your hosting provider), you should enter the database name and database username as ocom_db01 and ocom_u01 respectively.

MySQL connection fails with error [2013] or [2002]

If you are getting the error: failed with error [2013] Lost connection to MySQL server during query. or failed with error [2002] Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’ (13)., this may be caused by using the wrong database host name or by a permissions issue with the mysql.soc file or directory.

If you are using a hosting provider, ensure that you are using the correct host name for the database.

The MySQL manual has a good set of pages on dealing with common errors (such as these).
Visit the page for links to documentation for other versions of MySQL.

If you are unsure if MySQL is even installed, try the command mysql from the command line; if it is not installed, see Manual:Running MediaWiki#System-specific instructions.

UNIX utility binaries not found

Errors include:

• GNU diff3 not found
• Git version control software not found
• ImageMagick not found

PHP must have access to /usr/bin.
In php.ini (probably /etc/php/php.ini), add :/usr/bin/ to open_basedir config variable as below:

open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/var/www/:/usr/bin/

To disable GIT set $wgGitBin to a path that’s allowed but doesn’t exist.

«Forbidden: You don’t have permission to access /mediawiki/ on this server.»

This is usually an issue with the configuration of your web server software and unrelated to MediaWiki itself.
See for example here or other web server forums.

Update/Upgrade Errors

Missing rc_timestamp field of recentchanges table. Should not happen.

Might e.g. happen on upgrading from MW 1.27 to another version.
If there is no database content at all you might see this message.
See phab:T236671.

This may happen if you didn’t specify the same $wgDBprefix as your original installation, causing MediaWiki to not find its tables.
Check the existing tables on the database and see if they all share a common prefix, and update that setting accordingly.

Another cause may be that you set an empty database.
Reinstall the database content from a backup and proceed with migrating.

Parsoid / VisualEditor

See Parsoid/Troubleshooting and Extension:VisualEditor#Troubleshooting.

References

See also

• Manual:Config script#Installation errors
• Manual:How to debug

Вы видите пустую страницу

A blank white page indicates a PHP error which isn’t being printed to the screen.
To force this, add the following lines to the LocalSettings.php file, underneath the <?php:

error_reporting( E_ALL );
ini_set( 'display_errors', 1 );

You can also set a value for error_log in PHP.ini and read the PHP error log to find out what’s going on.
In some cases, PHP errors might also be recorded in the web server error log.

Error reports may include:

• «Warning […] It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function.» Check if date.timezone = is set correctly (or set at all) in php.ini.
• Certain files may be reported as missing (e.g. when the media folder in your /includes folder is no longer present, you may receive the message that a required imaging process «failed to open stream»). Check the original installation package at MediaWiki (make sure to consult the appropriate version) to see if this is the case. If so, simply copy the missing files from the package into your MediaWiki directory. It may be necessary to refresh the cache and restart the webserver afterwards.
• MySQL socket cannot be found. If LocalSettings.php is set to the correct MySQL socket but php.ini is not, it may result in a blank screen with no error output from the webserver or PHP. The fix is to update the mysql.default_socket entry in the php.ini file.

Many people report blank pages in recent versions after submitting articles to their new wiki.
A likely cause is the memory limit in default php installations (usually 8 MB).
Please check your PHP and/or Apache error logs.
To modify this setting edit /etc/php.ini and increase the «memory_limit» setting.
For example to raise it to 32 MB replace the existing text with memory_limit = 32M.
Make sure to restart your webserver after you have changed this value.

The memory limit may also have been set in your LocalSettings.php file.
Scan for the line containing the memory_limit setting and increase as needed.
20M may not be enough if you are running version 1.15.1.
Change it to e.g. «memory_limit = 32M«.
This change does not require you to restart Apache.

If the page just hangs loading during some time (like 30 seconds) doing a specific action, and then it results in a blank page or HTTP 500 error, the problem is a timeout connecting to some server.
This may be the database server, or if it happens doing a specific action, the mail server (if you have configured email settings).
If it’s the email server, check if you can connect to it from the server running MediaWiki, for example, running the Telnet client to the server and port configured on $wgSMTP and seeing if it can connect.

If you can see the page contents briefly, and suddenly the entire page goes blank, most likely the problem is caused by the presence of a document.write, document.writeln, or document.open JavaScript instruction in one of the scripts of the wiki.
You can check if that’s the case if you open your browser console (hit F12) and reload the page.
If the network tab returns a HTTP 200 status, and the transfer is of several kilobytes, it’s very likely this is the problem.
These are legacy methods of the Document interface that cause the entire page to become blank if it’s used outside of the page HTML, and it may be present on the wiki’s JavaScript pages.
Their usage is strongly discouraged, as indicated by the HTML specification itself.
You can disable JavaScript on your browser, or set $wgUseSiteJs and $wgAllowUserJs to false to disable those scripts until you fix the broken scripts.

All pages have no content, but when editing a page the wiki text is there

Optionally with those error messages:

PHP Warning: preg_replace(): Compilation failed: group name must start with a
  non-digit at offset 4 in /var/www/wiki/htdocs/includes/MagicWord.php

This is caused by a change in PCRE 8.34, which no longer allows names of capturing groups to start with a digit.
You need to update MediaWiki to a supported version.
См. Updating to PCRE 8.33 or Higher.
The problem is solved in all currently supported versions of MediaWiki (see задача T60640).

See report:
Topic:Rz2zo0m88rrxqrfn, Thread:Project:Support desk/MediaWiki don’t work with PCRE 8.34 (2)

Image Thumbnails not working and/or appearing

This section lists problems and solutions relating to thumbnails not rendering or displaying.

Error creating thumbnail: File missing:

This might happen due to wrong values of global variables as explained in:

• Manual:$wgUploadDirectory
• Manual:$wgUploadPath
• Руководство:$wgScriptPath

Decimal-point in srcset locale bug

If image thumbnails simply don’t appear, and there’s no error visible on those pages, look at the HTML source of the page and search for «srcset«.
If you find something like <img ... srcset="/images/thumb/File.png/600px-File.png 1,5x, /images/thumb/File.png/800px-File.png 2x">, where it appears 1,5x instead of 1.5x, the problem is caused by задача T181987, and you should add this to LocalSettings.php:

setlocale(LC_NUMERIC, "C");

Be sure there’s no $wgShellLocale defined in your LocalSettings.php, or add also this:

$wgShellLocale = "C.UTF-8";

SVG

First, determine your $wgSVGConverter setting.
By default, it is set to use ImageMagick for conversion.

Использование ImageMagick

You need at least ImageMagick 6.x.x.
Ensure that your $wgImageMagickConvertCommand variable is valid.
Common settings are:

$wgImageMagickConvertCommand = "/usr/bin/convert";
$wgImageMagickConvertCommand = "/usr/local/bin/convert";

If it does not work, try setting $wgSVGConverterPath.

$wgSVGConverterPath = "/usr/bin";
$wgSVGConverterPath = "/usr/local/bin";

Shared hosts may provide different ImageMagick versions to meet the needs of different users.
Please use version 6.x.x.

• To determine the version of ImageMagick, search the help files of your host provider, or use /usr/bin/convert --version or /usr/local/bin/convert --version to detect.
• On GoDaddy Linux shared hosts, «/usr/bin/convert» for Version 5.5.6 and «/usr/local/bin/convert» for Version 6.2.8.

If generating thumbnails with ImageMagick fails with a web server error log message like «Memory allocation failed» or «/bin/ulimit4.sh: Segmentation fault /usr/bin/convert …», the $wgMaxShellMemory value may need to be increased.

When the path is missing non-ASCII characters

• Check if UTF-8 locals are available on your server by running locale -a
• When it’s not available run locale-gen en_US.utf8 or put in the locales with UTF-8 for your country and change the value for $wgShellLocale according to this.

When using IIS/FastCGI on Windows, the guest account that is used also needs execute permission on C:WindowsSystem32cmd.exe otherwise you’ll receive an «Unable to Fork» error.

Использование Batik

MediaWiki places time and memory limits on shell commands under Linux.
If you receive the error «Error occurred during initialization of VM, Could not reserve enough space for object heap, Could not create the Java virtual machine.», try increasing the value of $wgMaxShellMemory.

Использование rsvg

On some Linux and BSD installations rsvg is renamed:

Instead of setting (default)

$wgSVGConverters = array( 'rsvg' => '$path/rsvg -w$width -h$height $input $output' );

you would like to set

$wgSVGConverters = array( 'rsvg' => '$path/rsvg-convert -w $width -h $height -o $output $input' );

JPEG

Symptom:
This error message within a grey box:

Error creating thumbnail: Invalid thumbnail parameters

One cause: the number of pixels in the original image exceeding $wgMaxImageArea.
The default value 1.25e7 is too small for many modern cameras.
Too bad the diagnostic really doesn’t hint at the problem.

You can increase the value of $wgMaxImageArea or switch to using ImageMagick which evades this restriction (set $wgUseImageMagick and $wgImageMagickConvertCommand).

Large images can take significant processing time.
It may be good policy to cap the size of images.

JPEG (с использованием GD)

Symptom:
This error message within a grey box:

Error creating thumbnail: Incomplete GD library configuration: missing function imagecreatefromjpeg

Some PHP 4.x and 5.x versions of PHP have a bug where libjpeg is detected but not enabled during the ./configure step; this is fairly prevalent on Red Hat/RHEL/CentOS systems.
If you don’t want to use ImageMagick, the fix for this is to recompile PHP.
First, find out (from phpinfo()) what the existing ./configure switches were, and add --with-jpeg-dir before --with-gd.

make clean
./configure --with-various-switches --with-jpeg-dir --with-gd --with-more-switches
make
make test
# switch to root
make install

Afterwards, restart the webserver (for Apache on Red Hat: service apache stop then service apache start ).
To test, simply view the File:… page again (no need to upload again).
For more information see the comments on PHP: imagecreatefromjpeg (function synopsis)

Unable to save thumbnail to destination

If you get the error «Error generating thumbnail / Error creating thumbnail: Unable to save thumbnail to destination» and the $wgUploadDirectory directory has the correct permissions (at all levels), check that $wgTmpDirectory actually exists.
(Unlike some path variables such as $wgCacheDirectory, $wgTmpDirectory is not created at runtime.)
A more detailed error message may be available if you turn on logging with $wgDebugLogFile.

This error can also occur when read only mode ($wgReadOnly) has been set in LocalSettings.php.
You can try to remove $wgReadOnly to see if that solves the issue for you.

Error creating thumbnail Error code: 25

If you get «Error creating thumbnail Error code: 25» with ImageMagick, try increasing $wgMaxShellFileSize.

Manually adding thumbnail files

In situations in which it’s not feasible to create the thumbnails dynamically on request (e.g. for very large images, «Error creating thumbnail: unable to extend cache», «Error creating thumbnail: convert: no images defined», and similar), it is possible to manually add the thumbnail files.
This involves creating the smaller images in the desired sizes and uploading them to the thumb/ directory in $wgUploadDirectory.

For example, a file that has uploaded to:

images/f/f8/Foo.png

should have its thumbnails at:

images/thumb/f/f8/Foo.png/100px-Foo.png
images/thumb/f/f8/Foo.png/600px-Foo.png

The pixel size is the horizontal dimension.
An example Bash script for creating thumbnails is available at Phabricator:P7049.

Error creating thumbnail: Error code: -1 on OVH mutualized hosting

For unidentified reason, creation of thumbnails on some mutualized OVH hosting are failing with this error, even if running the command in SSH shell works.

Solution is to specifically prevent from using ImageMagick by setting $wgUseImageMagick to false in LocalSettings.php:

$wgUseImageMagick = false;

Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn’t work, try logging out and logging back in.

Content Limits

If your Apache server has the Hardened PHP patch, you may need to edit several variables in your /etc/php.ini file if you wish to have wiki pages with large amounts of content.
In particular, consider the settings for varfilter.max_value_length, hphp.post.max_value_length, hphp.request.max_value_length.
The default settings may limit your pages to less than 10k or 64k in size.

Another possibility is if your Apache server is using mod_security that could be interfering with MediaWiki.
You will need to turn it off for MediaWiki to work properly.

You have not specified a valid user name / Completely blank page edits and previews / Unable to upload

This is caused by something truncating or dropping POST data from the browser to the web server.

In at least one instance, this was caused by post_max_size and upload_max_filesize in php.ini being set too high (2048M).
Setting them back to more sane values (8M) fixed it.
Apparently, no POST data was actually making it through to MediaWiki.

In another instance, mod_auth_sspi was interfering with http posts to MW.
Using FireFox and entering domain credentials would work fine, but MSIE would fail.
This is a known defect in mod_auth_sspi 1.0.4.

You have a few options to make this work:

• Set SSPIOfferSSPI off ← users will get prompted and have to enter domain credentials, same as BASIC mode
• Set SSPIPerRequestAuth on ← I don’t see how this is a healthy configuration but it worked (except over the high latency connection I’m forced to contend with)
• Downgrade to 1.0.3 but it’s basically the same as #2 above.

The wiki appears without styles applied and images are missing

If the wiki looks fine if you browse it from the same server where it’s being hosted but it appears without CSS styles applied (no colors, no backgrounds, no images, very minimal formatting, etc) if you access it from other machines (or some of them), the most probable cause is that the server is having problems with determining the IP or host name that is being used to access it, or it’s misconfigured.
This causes URLs to styles and images to be generated using the loopback IP address 127.0.0.1, localhost, or a host name not known outside of the server.
You can see the source code of any page and check how URLs look like and what happens if you try to access them directly via your browser.

The solution is to manually specify the $wgServer variable to the host name that everyone will use to access the wiki.

If your wiki is being accessed from an internal network and an external one, you may need to use the external address for $wgServer.
Don’t forget the port number if you are using a non-standard port as may by the case if your ISP has blocked port 80 (Example: $wgServer = "http://example.domain.com:8080";)

If styles aren’t applied even when browsing the wiki from the server where it’s hosted, the problem may be a PHP error on the ResourceLoader load.php script.
Try to browse the load.php file of your MediaWiki installation with your web browser and see if it displays any errors or just a blank page (see #You see a Blank Page).
You should see a comment similar to /* No modules requested. Max made me put this here */.
If so, it may be a problem with the web server’s .htaccess file.

If you instead see a 404 Not found error, it may be a problem with the web server’s rewrite rules if you attempted to configure Short URLs.

If you’re getting 500 error responses from load.php urls, check the webserver’s error log files to get more information of the errors.
There seems to be a problem with some PHP versions and Gentoo that causes Apache to segfault.^[1]
This can also happen if you have APC enabled, setting apc.serializer=php in php.ini might help.^[2]

Since MediaWiki 1.23, you may end with a wiki with most of the Vector-specific skin styles, like sidebar placed at the end of the page.
That may be caused by a low pcre.backtrack_limit set up on some distributions like FreeBSD.
It’s known to have problems with values of 10000.
Increase that value to 100000, or the current default of 1000000.

Since MediaWiki 1.26, some skins, and specially Vector, may have this problem.
If you see the error Internal error Problematic modules: {«startup»:»error»} in the error console of your browser, most likely cause is the lack of permissions of MediaWiki to write to the default temp folder, either because PHP has no permissions to write to /tmp (C:WINDOWSTEMP on Windows), or because there’s an open_basedir restriction and that path isn’t included on it.
See задача T119934.
You can also set $wgTmpDirectory if you’re unable to change permissions on the system’s default temp directory.

Error: invalid magic word ‘speciale’

If you get that error message after upgrading, you must run the rebuildLocalisationCache.php maintenance script with the --force option:

php rebuildLocalisationCache.php --force

Missing edit toolbar, JavaScript not working

Since MediaWiki 1.32, MediaWiki no longer has a «JavaScript-powered» wikitext toolbar built in. The old «bulletin board style toolbar», known as «the 2006 wikitext editor», has been removed, and instead sysadmins will be required to choose one (or more) of the several extensions available for this purpose if they need the functionality. The MediaWiki «tarball» releases have included the replacement extension for this, the WikiEditor extension aka «the 2010 wikitext editor», for many years now. Be sure this extension has been installed.

If JavaScript is not working (one of the symptoms is the edit toolbar not appearing when editing a page) it may be caused by a JavaScript error.
Open the error console of your web browser (usually by hitting F12), reload the page and see if any error message appears there.
If it displays an error, usually, setting $wgShowExceptionDetails would give you more information.
Sometimes the problem is that the system’s temp directory is not writable.
In that case, you can also set $wgTmpDirectory if you’re unable to change permissions on the system’s default temp directory.

If you get errors like Uncaught SyntaxError: Unexpected token < or Error: SyntaxError: syntax error (...) Source Code: <script (...), the cause is usually a hosting provider that is automatically injecting HTML code for tracking or advertising inside the load.php script, which is used by ResourceLoader to load the scripts and CSS used by MediaWiki.
Open a support ticket with your hosting provider asking them to disable that injection.
If that’s not possible, you should migrate your site to another hosting provider.
That usually happens on free hosting providers.

Every page displays a fatal error, Log shows «MagicWordArray::parseMatch: parameter not found»

Try rebuilding the Localisation Cache:

php maintenance/rebuildLocalisationCache.php

All uploads fail with the message «The file you uploaded seems to be empty…»

It may be caused by wrong rewrite rules when configuring Short URLs.
Try disabling them (and the related configuration variables of MediaWiki) to see if that solves the problem.

Another problem may be a limit imposed by the web server about how many data the server can receive on a single request.
See Manual:Configuring file uploads#Set maximum size for file uploads for some configuration variables.
If you have mod_security or suhosin installed, they may also be limiting the size of uploaded files, discarding the upload entirely without PHP noticing it.

Check also the upload_tmp_dir configuration directive from php.ini, and be sure that the folder has proper write permissions for the user account running PHP.
On Windows, this directive often points to C:WindowsTEMP, which may not be accessible in some circumstances.
In that case, you can set up a different temp folder like C:TEMP with proper permissions.
To discard other problems, give temporarily all permissions to that folder (on Windows, add the local user group «Everyone» with full permissions), and then restrict the permissions as needed once you verify uploads are working.

If all uploads fail with the message «Загруженный вами файл, вероятно, пустой. Возможно, это произошло из-за ошибки при наборе имени файла. Пожалуйста, проверьте, действительно ли вы хотите загрузить этот файл.», and in the Apache error logs you have entries like this:

Notice: Undefined index: tmp_name in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1153
Notice: Undefined index: size in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1140
Notice: Undefined index: error in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1167

This is a problem with the PHP version your server is using.
There have been several reports of this problem with PHP 5.3.8 on SLES11 sp2.
You may need to upgrade PHP or recompile it yourself.

WAMP/Apache on Windows: Some Special: pages are inaccessible

It may happen, on Windows installations under Apache, that some Special pages are inaccessible, giving a error, and in the logs you can see something like this:

[core:error] The given path is misformatted or contained invalid characters: [client 127.0.0.1] AH00127: Cannot map GET /wiki/Special:SpecialPages HTTP/1.1 to file

This can be caused by various PHP bugs.
One of them is when the wiki is installed in a NTFS junction.
If that’s not the problem, upgrading PHP to a newer version can help (see this forum thread)

Attempting to save an edit gives you a 403 Forbidden error, or you get redirected to the main page

This is a common issue for shared host which have mod_security enabled.
To know if it’s a problem with mod_security or not, create a simple test page and save it with a small text (something as simple as writing just a dot in the content).
If the edit is saved, but other edits aren’t, that’s caused by mod_security.
Ask your hosting customer support to disable it completely or the rules affecting your edits.

If even saving a very simple edit gets you redirected to the main page, or to the same page without the edit appearing, it may be a problem with how you’ve set up $wgServer or some other configuration variable that controls the path of the index.php script, or conflicts with rewrite rules in your webserver’s configuration.

Login page warns about cookies disabled

You may get a message like MediaWiki использует cookie для представления участников.
Вы отключили использование cookie.
Включите их и попробуйте снова..

If cookies aren’t disabled on your browser, it could be one of those problems:

• You have $wgSessionsInMemcached set to true but MediaWiki can’t connect to Memcached. Turn off this setting or check the Memcached configuration.
• A wrong cookie configuration. Configuration variables about cookies should work with their default values. Try to not override any of them.
• session_save_path() is not set correctly on the server, or the server doesn’t have permissions to write to that path.
• If you use some sort of caching proxy in front of MediaWiki, check that it doesn’t filter any cookie.
• session.referer_check() is wrongly set. You should normally leave it empty.

Setting a debug log should display any cookie received by MediaWiki, so it may be a first step to detect if cookies are actually received by MediaWiki or not.

MediaWiki does not function when magic quotes are enabled

Magic quotes was a feature in PHP that was deprecated in PHP 5.3 and removed in PHP 5.4.
If you get this error, you need to disable the magic quotes in your server setting.
See how to do it.

Discussions: Thread:Project:Support_desk/Problems_with_installing_mediawiki, Topic:S79xdn9u15xw55vj, Topic:Sdpbmy9q9e0ttp6k, Topic:S7g4rybniat2i36e, Topic:S6vqwk0tysl6m8lc

Error creating thumbnail: File with dimensions greater than 12.5 MP

It may help to increase $wgMaxImageArea to get rid of the problem (tried with MediaWiki 1.26.2).

Internal Server Error when opening any image

If images are not displayed on the pages, and manually opening the URL of any image results in an Internal Server Error page, the problem is most likely caused by the .htaccess file from the images directory.
This configuration file contains some rewrite rules to prevent old Internet Explorer versions from being affected by a cross site scripting vulnerability.
However, some hosts like strato.de prevents disallow the RewriteOptions directive in .htaccess, causing any request for a file in the images folder to fail with an error.
If you can’t enable rewrite rules on .htaccess file, you may need to comment-out or remove those lines from .htaccess, or the entire .htaccess altogether.
See this thread.

Category pages, Special:Whatlinkshere and file usage aren’t being updated

Information about pages contained in a category, links to other wiki pages and images embedded in pages are tracked in special tables.
The update of such tables is not done immediately after the edit is saved, but deferred to the job queue for performance reasons.
If it takes too long to update, you may need to adjust $wgJobRunRate, or try setting $wgRunJobsAsync to false in LocalSettings.php.
This can happen in some installations, especially since MediaWiki 1.27 (see задача T142751).

Error: Could not open lock file for «mwstore://local-backend/local-public/./../image.png

Check that the «images» directory has permissions which allow writing.
For example: chown -R www-data:www-data images and chmod -R 777 images.
If you have SELinux enabled, this could also be problematic.

Notice: Did not find alias for special page ‘Foo’. Perhaps no aliases are defined for it? [Called from SpecialPageFactory::getLocalNameFor in …

You need to create an alias file.
So, put something like this in your extension file (e.g. /extensions/Foo/Foo.php):

$wgExtensionMessagesFiles['FooAlias'] = __DIR__ . '/Foo.alias.php';

Then create an alias file like this:

<?php
/**
 * Aliases for Special:Foo
 *
 * @file
 * @ingroup Extensions
 */
// @codingStandardsIgnoreFile

$specialPageAliases = array();

/** English (English) */
$specialPageAliases['en'] = array(
   'Foo' => array( 'Foo' ),
);

Make sure you don’t have a $wgMessagesDirs item with the same key.
Keys of $wgExtensionMessagesFiles which are also in $wgMessagesDirs will be skipped.

Warning: Invalid argument supplied for foreach() in ./includes/objectcache/SqlBagOStuff.php

Probably you just moved your wiki, and didn’t import your database, so it’s empty.

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please resubmit the form.

Call to undefined method

If a MediaWiki extension shows this error after installing that MediaWiki extension, double-check that you downloaded the version or branch of that MediaWiki extension which matches the version or branch of your MediaWiki installation.

Unable to run external programs, proc_open() is disabled

The function has been disabled in php.ini.
This prevents using ImageMagick to resize images to create thumbnails.
Either contact your hosting provider, or try to use gd instead of ImageMagick by setting $wgUseImageMagick to false.

CAS update failed on user_touched for user ID ‘*’ (read from slave); the version of the user to be saved is older than the current version

There are several reasons for this error.
One simple one is if the content of the user_touched column of the user table is empty or is set to a time in the future.

You might want to check if the server’s time is set correctly and synchronized.
Also check the contents of that column and fill the column with valid content e.g. with this SQL statement:

UPDATE `user` SET user_touched='20230208083340'
WHERE HEX(
	user_touched
)='0000000000000000000000000000';
-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- 28 zeroes

Where the date is in YYYYMMDDHHMMSS format for the current date/time.
See phab:T247751.

Lua error: Internal error

A database query error has occurred. This may indicate a bug in the software.

If you recently upgraded MediaWiki, or recently installed or upgraded extensions, try running the update.php maintenance script.
(See also Manual:Обновление.)

If that doesn’t help, then you really may have ran into a bug in the software.
Try to obtain more details about the query that fails (Manual:How to debug) and file a bug.

$wgSecretKey key is insecure, generated with mt_rand()

Your system does not support /dev/urandom so the key was generated with mt_rand().
See $wgSecretKey.

Ошибки PHP

Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)

Raise PHP’s memory limit in php.ini:

memory_limit = 64M      ; Maximum amount of memory a script may consume (32MB)

You can add a higher value for $wgMemoryLimit in LocalSettings.php.

ini_set('memory_limit', '20M');

This error can often happen for other reasons. Look for Unicode usage on systems that do not support it properly. Look for the filename and line and if you find that you are in a language translation section that uses non-ascii characters, strip out that section. If you have increased the RAM allocated to PHP to 512MB and *still* have the problem with the memory error, it is not likely a memory issue per-se.

Read here for more information on configuring resource limits in PHP.

Fatal error: Class ‘DOMDocument’ not found in xxxxxxxx/Preprocessor_DOM.php on line nnn

This error happens when PHP hasn’t been compiled with DOM support, or the DOM/xml extension is missing.

• Install the right php-xml package for your distro. Example: sudo yum install php-xml
• Alternatively, change the MediaWiki ‘preprocessor’ class in LocalSettings.php (see $wgParserConf)

$wgParserConf['preprocessorClass'] = 'Preprocessor_Hash';

Fatal error: Invalid opcode 153/1/8. in xxx/includes/cache/MessageCache.php on line nnn

That issue seems to indicate it’s a problem with a PHP code accelerator that doesn’t match the installed version of PHP or it’s outdated.
Try upgrading the accelerator.
report

Most likely, your text editor added a byte order mark (BOM) while you edited MediaWiki’s PHP files, but any other content before the opening <?php causes the same problem.
This usually happens with LocalSettings.php — but see error message for exact file.
Note that BOMs are invisible in most text editors.
To remove the BOM, edit the file with something better than Windows Notepad, but if you don’t really have time — open the file with it and choose Save as…, then choose «Unicode (UTF-8 Without signature) — Codepage 65001» as file type.

Strict Standards: date_default_timezone_get(): It is not safe to rely on the system’s timezone settings.

If you get Strict Standards: errors in the HTML output, that’s because your error_reporting configuration variable of PHP is set to E_ALL, but since PHP 5.4.0, E_STRICT became part of E_ALL.
E_STRICT are not errors, but warnings about code interoperability and forward compatibility of PHP code, and they shouldn’t be visible in production environments.

Just add your time zone to LocalSetting.php, e.g.

$wgLocaltimezone = 'Europe/Berlin';

The following does not work in all cases.
It may be better to put this in the php.ini which must be present in all affected directories.

You may turn of E_STRICT errors putting the following line of code inside your LocalSettings.php, or in case a line with the error_reporting function exists, replace it with:

error_reporting( E_ALL & ~( E_STRICT | E_NOTICE ) );

You can turn off PHP error reporting entirely using this instead:

See also: Setting error reporting in PHP.

If nothing works, please check at the start of your LocalSettings.php file:
If that error happened on the setup process, the LocalSettings.php that it generated could have included the error message at the top of it (example).
If that was what happened, edit the file removing everything before «<?php» and verify there’s nothing (even whitespace) before «<?php«.

Fatal Error: Cannot redeclare wfprofilein()

This could happen if you upgraded and you have a StartProfiler.php file in the root MediaWiki installation directory, probably because you enabled profiling in an old installation.
To solve the issue simply remove that file.

Предупреждение: Недоступные файлы

After your move, you might see PHP warnings that certain files could not be accessed.
This is most likely caused by задача T37472:
The column md_deps in the module_deps table contains absolute file paths, which are used to locate the images and LESS files that CSS depends on.
These paths break when the wiki is, e.g., moved to another folder or another server.
Until this bug is solved, you can use this workaround to manually fix wrong entries in the module_deps table:

-- Update entries in module_deps table
SET @old='wiki.old-domain.org';
SET @new='wiki.new-domain.org';

UPDATE `module_deps` SET `md_deps` = REPLACE( `md_deps`, @old, @new );

This can be used to update wrong path segments and to fix the error.

A similar issue can happen when MediaWiki tries to read ResourceLoader messages.
In this case the solution is to truncate the according tables:

-- Truncate message related caches
TRUNCATE TABLE `msg_resource`;
TRUNCATE TABLE `msg_resource_links`;

Fatal error: Uncaught Exception: extension.json does not exist

If this error happens when you try to install an extension, it usually means that the extension still requires to use the native PHP require_once language construct instead of the newer wfLoadExtension() method.

Ошибки при установке

LocalSettings.php not readable

• On a Linux machine, use chown or chgrp to correct the file permissions of LocalSettings.php.
• On some Linux machines, temporarily disable SELinux by running the command sudo setenforce 0.

The installer is unstyled when installing under IIS

The installer is unstyled and instead of the stylesheet, /mw-config/index.php?css=1 shows this error message: «Less_Exception_Parser from line 447 of …vendoroyejorgeless.phplibLessParser.php: Less.php cache directory isn’t writable: C:WindowsTEMP»

Make sure that the webserver user, who by default is named IUSR, is allowed to access the C:WindowsTEMP directory.
At least read and write permissions are necessary.

Error selecting database wikidb: 1044 Access denied for user ‘username’@’localhost’ to database ‘wikidb’

You need to Grant permissions on wikidb.*.

GRANT ALL ON wikidb.* TO 'username'@'localhost' IDENTIFIED BY 'password';

or if your Web Server is on a different box than your DB server — you have to configure remote access to MySQL and grant differently

GRANT ALL ON wikidb.* TO 'username'@'192.168.0.x' IDENTIFIED BY 'password';

NOTE: Replace 192.168.0.x with your Webserver’s IP.
Also note that the apostrophes (‘) need to stay.

Database returned error «1142: CREATE command denied to user ‘username’@’localhost’ for table ‘user_properties’ (localhost)»

As above, or temporarily use the mysql root user.

Could not find a suitable database driver!

PHP MySQL support is not installed/enabled — See https://php.net/book.mysqli.
Depending on your operating system, you may need to install an additional package.
For example, on debian/ubuntu run sudo apt install php-mysql.

Filename Case Errors

If you are using a different FTP client than FileZilla to upload files to your server, be sure to configure the client to not force uppercase or lowercase filenames.
MediaWiki filenames are case-sensitive.

Incomplete Upload Errors

The MediaWiki package includes a lot of files, spread over dozens of directories.
Be careful when uploading.
If the transfer is interrupted, you might have missing or incomplete files.
You may have to retry your upload several times, especially if you have an unreliable connection.

403 Forbidden with Symbolic Links

If your webserver produces a «403 Forbidden error» page and you are using symbolic links, then make sure your Apache httpd.conf file has Options FollowSymLinks to allow symbolic links and that each directory leading up to your linked directory has +x permission for user running httpd.

HTTP 500 Internal Error during installation

If your webserver produces a «500 Internal Error» at the beginning of the install process, you may need to change the permissions on the mw-config directory to 755.
If you have changed the permissions for the config directory and still get an unwritable error try changing the owner to apache.

chown -R apache:apache /var/www/html/mediawiki/*

HTTP 500 Internal Error after installation

If you downloaded the MediaWiki code from Git, and after finishing the installation process, accessing your MediaWiki installation in the web browser produces a «500 Internal Error», go to the MediaWiki installation folder and running the following commands:

find . -type f -exec chmod 644 {} ;
find . -type d -exec chmod 755 {} ;

SELinux

Linux distributions which support SELinux (‘Security Extensions’) are becoming more widespread.
On such systems, PHP scripts will still be unable to write to the config directory, after you have set the normal file permissions.
You will also need to use the ‘chcon’ command to change the SELinux file type.

Required Advertisements on Hosted Sites

If you are running the MediaWiki software on a free site that requires banners or prefix advertising, this may cause MediaWiki not to work, and appear to only generate empty pages beyond the banner advertising.
You will have to contact your host to make them make their advertising compatible with MediaWiki, or choose a different host.

Debian, Apache2 и PHP

If you’re running the MediaWiki on Debian with Apache2 and PHP5, and have problems connecting to MySQL, e.g you get the following error message in your browser: (Can’t contact the database server: MySQL functions missing, have you compiled PHP with the —with-mysqli option?) try uncommenting: extension=mysqli.so in the /etc/php5/apache2/php.ini file.

If that does not work, try the following…

Check that MySQL module for php is installed:

dpkg --list | grep php-mysql

If you need to install the php5-mysql module enter:

apt-get install php-mysql

Then restart Apache2:

/etc/init.d/apache2 restart

‘user_password’ can’t have a default value

Ensure that MySQL is not running in strict mode.

Missing table prefix

If you are using a hosting service, the database name and database username may have an extra prefix (normally the userid given by your hosting provider).
For example, if you have created a database named db01 with username u01 and your userid is ocom (given by your hosting provider), you should enter the database name and database username as ocom_db01 and ocom_u01 respectively.

MySQL connection fails with error [2013] or [2002]

If you are getting the error: failed with error [2013] Lost connection to MySQL server during query. or failed with error [2002] Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’ (13)., this may be caused by using the wrong database host name or by a permissions issue with the mysql.soc file or directory.

If you are using a hosting provider, ensure that you are using the correct host name for the database.

The MySQL manual has a good set of pages on dealing with common errors (such as these).
Visit the page for links to documentation for other versions of MySQL.

UNIX utility binaries not found

Errors include:

• GNU diff3 not found
• Git version control software not found
• ImageMagick not found

PHP must have access to /usr/bin.
In php.ini (probably /etc/php/php.ini), add :/usr/bin/ to open_basedir config variable as below:

open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/var/www/:/usr/bin/

To disable GIT set $wgGitBin to a path that’s allowed but doesn’t exist.

«Forbidden: You don’t have permission to access /mediawiki/ on this server.»

This is usually an issue with the configuration of your web server software and unrelated to MediaWiki itself.
See for example here or other web server forums.

Update/Upgrade Errors

Missing rc_timestamp field of recentchanges table. Should not happen.

Might e.g. happen on upgrading from MW 1.27 to another version.
If there is no database content at all you might see this message.
See phab:T236671.

This may happen if you didn’t specify the same $wgDBprefix as your original installation, causing MediaWiki to not find its tables.
Check the existing tables on the database and see if they all share a common prefix, and update that setting accordingly.

Another cause may be that you set an empty database.
Reinstall the database content from a backup and proceed with migrating.

Parsoid / VisualEditor

See Parsoid/Troubleshooting and Extension:VisualEditor#Troubleshooting.

Примечания

Смотрите также

• Manual:Config script#Installation errors
• Manual:How to debug

Click here follow the steps to fix Mediawiki Internal Error 500 and related errors.

Instructions

Note:
This article was updated on 2023-02-03 and previously published under WIKI_Q210794

What is Mediawiki Internal Error 500 error?

The Mediawiki Internal Error 500 error is the Hexadecimal format of the error caused. This is common error code format used by windows and other windows compatible software and driver vendors.

This code is used by the vendor to identify the error caused. This Mediawiki Internal Error 500 error code has a numeric error number and a technical description. In some cases the error may have more parameters in Mediawiki Internal Error 500 format .This additional hexadecimal code are the address of the memory locations where the instruction(s) was loaded at the time of the error.

What causes Mediawiki Internal Error 500 error?

The Mediawiki Internal Error 500 error may be caused by windows system files damage. The corrupted system files entries can be a real threat to the well being of your computer.

There can be many events which may have resulted in the system files errors. An incomplete installation, an incomplete uninstall, improper deletion of applications or hardware. It can also be caused if your computer is recovered from a virus or adware/spyware
attack or by an improper shutdown of the computer. All the above actives
may result in the deletion or corruption of the entries in the windows
system files. This corrupted system file will lead to the missing and wrongly
linked information and files needed for the proper working of the
application.

How to easily fix Mediawiki Internal Error 500 error?

There are two (2) ways to fix Mediawiki Internal Error 500 Error:

Advanced Computer User Solution (manual update):

1) Start your computer and log on as an administrator.

2) Click the Start button then select All Programs, Accessories, System Tools, and then click System Restore.

3) In the new window, select «Restore my computer to an earlier time» option and then click Next.

4) Select the most recent system restore point from the «On this list, click a restore point» list, and then click Next.

5) Click Next on the confirmation window.

6) Restarts the computer when the restoration is finished.

Novice Computer User Solution (completely automated):

1) Download (Mediawiki Internal Error 500) repair utility.

2) Install program and click Scan button.

3) Click the Fix Errors button when scan is completed.

4) Restart your computer.

How does it work?

This tool will scan and diagnose, then repairs, your PC with patent
pending technology that fix your windows operating system registry
structure.
basic features: (repairs system freezing and rebooting issues , start-up customization , browser helper object management , program removal management , live updates , windows structure repair.)

I have been using XAMPP to install MediaWiki on my Windows 10 computer. The installation was going smoothly while I was following the guide here: https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki#Download_MediaWiki_software until I had to run the installation script. When I typed «localhost/w» into the search bar, instead of telling me that LocalSettings.php could not be found, and I could set up the wiki, it gave me an error that looked like this:

MediaWiki 1.36 internal error. Installing some PHP extensions is required.

Required components

You are missing a required extension to PHP that MediaWiki requires to run. Please install: intl 

After searching the web for a bit, I figured out that I needed to enable the intl extension by going into php.ini in the php folder and uncommenting «extension=intl». I figured that would solve the issue, but when I tried loading «localhost/w» again, it looks like a new problem popped up:

If I scroll down, it does give me the option of setting up a new wiki, but I’m not sure if I should without resolving the issue first. If you guys couldn’t tell, I don’t know anything about coding at all, so any help is appreciated. 

Some relevant maybe useful information:

I am using the most recent versions of Media Wiki (1.36.1) and I am using XAMPP 7.3.28 because apparently (from what I’ve read) the php files that come with the more recent versions don’t work with MediaWiki. 

Thanks in advance!