Manual:Common errors and symptoms

Install MediaWiki

Local development quickstart

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 :

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

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:

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 , 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");

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:\Windows\System32\cmd.exe otherwise you will 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 are 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 10,000. Increase that value to 100,000, or the current default of 1,000,000.

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:\WINDOWS\TEMP 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 are unable to change permissions on the system's default temp directory.

Error: invalid magic word 'speciale'

MediaWiki version:

≥ 1.20

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

php rebuildLocalisationCache.php --force

Localised strings show their message ID instead of a localized result

If you are seeing this, try running the rebuildLocalisationCache.php maintenance script with the --force option:

php rebuildLocalisationCache.php --force

This will force MediaWiki to rebuild the localisation cache.

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 are 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:

[1]

[2]