Manual:Common errors and symptoms

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  file, underneath the  :

You can also set a value for  in   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  is set correctly (or set at all) in.
 * Certain files may be reported as missing (e.g. when the  folder in your   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  is set to the correct MySQL socket but   is not, it may result in a blank screen with no error output from the webserver or php. The fix is to update the   entry in the   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  and increase the "memory_limit" setting. For example to raise it to 32 MB replace the existing text with " ". Make sure to restart your webserver after you have changed this value.

The memory limit may also have been set in your  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. " ". 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.

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. You need to downgrade PCRE, or update MediaWiki to version 1.22.1 or newer (see ).

See report: Topic:Rz2zo0m88rrxqrfn and Thread:Project:Support_desk/MediaWiki_don't_work_with_PCRE_8.34_(2)

SVG

 * See also: 

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:

If it does not work, try setting $wgSVGConverterPath.

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  or   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 When using IIS/FastCGI on Windows, the guest account that is used also needs execute permission on %SYSTEMROOT%\System32\cmd.exe otherwise you'll receive an "Unable to Fork" error.
 * Check if UTF-8 locals are available on your server by running
 * When it's not available run  or put in the locales with UTF-8 for your country and change the value for $wgShellLocale accoring to this

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) you would like to set

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 the libjpeg is detected but not enabled during the  step; this is fairly prevalent on Red Hat/RHEL/CentOS systems. The fix for this (if you don't want to use ImageMagick) is to recompile PHP. First, find out (from phpinfo) what the existing  switches were, and add   before.

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:  then   ). To test, simply view the File:... page again (no need to upload again). For more information see the comments on PHP: imagecreatefromjpeg (function synopsis)

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.
Assuming you get this error even when you do have a seemingly valid logon session:
 * Check if /var/lib/php5 is writable and not readable for user and world ( # chmod 733 /var/lib/php5 )
 * Check to see if your session.save_path value in php.ini is valid and writable to the webserver - PHP configuration.
 * Check to see if there is enough disk space.
 * If you are using an extension or Apache for authentication, verify you are using the fqdn to access the wiki.

After making changes restart Apache.


 * If you use memcached and enable $wgSessionsInMemcached, make sure that memcached is really working.
 * You may be attaching to an old, stale session. If you see old session files in your session.save_path directory delete them.

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, and 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 &larr; users will get prompted and have to enter domain credentials, same as BASIC mode
 * Set SSPIPerRequestAuth on &larr; 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 styles applied (no colors, no backgrounds, no images, very minimal formatting, etc) if you access it from other machines (or some of them), most probably cause is that the server has problems to determine 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.

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  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 should see a comment similar to. If so, it may be a problem with the web server's  file (see here Manual:Load.php).

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.

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 limit of 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.

Error: invalid magic word 'speciale'
If you get that error message after upgrading, you must run the rebuildLocalisationCache.php maintenance script with the  option:

php rebuildLocalisationCache.php --force

This can happen at least upgrading to 1.20.

Missing edit toolbar, JavaScript not working
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, reload the page and see if any error message appears there.

If you get errors like  or , 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 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.

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 yourelf.

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  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.

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.
 * 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.

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.

Fatal error: Allowed memory size of nnnnnnn bytes exhausted (tried to allocate nnnnnnnn 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.

Note 1: In versions 1.15 and earlier, the memory limit in php.ini may be overridden by default in LocalSettings.php with the line: ini_set('memory_limit', '20M'); You may increase the memory limit here, or comment this line out in LocalSettings.php to use the limit specified in php.ini.

Note 2: 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  package for your distro. Example:
 * Alternatively, change the MediaWiki 'preprocessor' class in LocalSettings.php (see $wgParserConf)

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

Warning: Cannot modify header information - headers already sent by (...)
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  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  configuration variable of PHP is set to , 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  function exists, replace it with:

You can turn off PHP errors 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 " " and verify there's nothing (even whitespace) before " ".

Fatal Error: Cannot redeclare wfprofilein
This could happen if you upgraded and you have a  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 : 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:

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

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

Error selecting database wikidb: 1044 Access denied for user 'username'@'localhost' to database 'wikidb'
You need to Grant permissions on wikidb.* - See Manual:Installation

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

NOTE: Replace 192.168.0.x with your Webserver's IP

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 http://www.php.net/manual/en/book.mysql.php

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.

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  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.

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. See SELinux.

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. A fix for this will need to be done in the future. In the interim the only option is to find a paid hosting site. This may be considered a bug, and is being reported.

Debian, Apache2, and PHP5
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-mysql option?) try uncommenting: ';extension=mysql.so' in the '/etc/php5/apache2/php.ini' file.

If that does not work, try the following...

Check that MySQL module for php5 is installed:

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

Then restart Apache2:

'user_password' can't have a default value
Ensure that MySQL is not running in strict mode.

Specified key was too long
If you selected "experimental UTF-8", there may be a MySQL error of the type "specified key was too long". One way of solving that is to edit the file  so that the table causing the problem uses shorter keys. (Depending on MediaWiki version, there might be other  files you also need to change; for example,   in 1.6.10 if you use MySQL 5.)

For example, if you find the error message: PRIMARY KEY job_id (job_id), KEY (job_cmd, job_namespace, job_title) ) TYPE=InnoDB " failed with error code "Specified key was too long; max key length is 1024 bytes (localhost)".

Then you should find table "job" in tables.sql and replace  with something like.

The point is that the total length of all the fields in every KEY declaration should be less then the max key size mentioned in the error message, even when you multiply the varchar fields with three (because a UTF-8 character takes up 3 bytes). In the example, job_cmd is varchar(255), job_namespace is int, job_title is varchar(255), thus the total key length in  is 3*255 + 4 + 3*255 = 1534, which is greater than 1024. After replacing, 3*160 + 4 + 3*160 = 964, which should be okay.

After fixing, you should drop all the tables you have made before, and then run the install script again (just reload the page with the error message, that way you don't have to enter everything again). You might get this error for several tables - job and page_restrictions are some that can be affected.

See also.

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.

Class SkinStandard not found; skipped loading
If pages are displayed without skins, try enabling logging by adding  to your LocalSettings.php. If you get an error like “Class SkinStandard not found; skipped loading,” try the symlink suggestion at http://forums.fedoraforum.org/archive/index.php/t-159726.html. What worked for me was:

MySQL connection fails with error [2013] or [2002]
If you are getting the error:  or , 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  from the command line; if it is not installed, see Manual:Running_MediaWiki.

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 ), add   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  to a path that's allowed but doesn't exist.

$wgGitBin = "";