Manual:Errors and symptoms

MediaWiki Errors

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.

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.

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.

Image Thumbnails not working and/or appearing

SVG

See also: Manual:Image Administration 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 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)

$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 (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 ./configure 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 ./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)

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:

/etc/init.d/httpd restart

If you use memcached and enable $wgSessionsInMemcached, make sure that memcached is really working.

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

Update: You have a few options to make this work.

1. Set SSPIOfferSSPI off ← users will get prompted and have to enter domain credentials, same as BASIC mode
2. 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)
3. 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 $wgServer.

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

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

This can happen at least upgrading to 1.20.

PHP Errors

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)

MediaWiki version:

≥ 1.16

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

MediaWiki version:

≤ 1.15

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

Change the MediaWiki 'preprocessor' class:

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

Install the right 'php-xml' package for your distro:

sudo yum install php-xml

Discussion

If the DOM_Document class is missing, install PHP's XML module (and restart Apache) or set $wgParserConf['preprocessorClass'] = 'Preprocessor_Hash' (see <http://www.mediawiki.org/wiki/Manual:%24wgParserConf> for details)

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 <?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 errors entirely using this instead:

error_reporting( 0 );

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.

Installation Errors

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

You need to Grant permissions on wikidb.* - See Manual:Installation#MySQL

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

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

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:

# pkg --list | grep php5-mysql

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

# apt-get install php5-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.

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 maintenance/tables.sql so that the table causing the problem uses shorter keys. (Depending on MediaWiki version, there might be other tables.sql files you also need to change; for example, maintenance\mysql5\tables.sql 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 KEY (job_cmd, job_namespace, job_title) with something like KEY (job_cmd(160), job_namespace, job_title(160)).

(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 KEY (job_cmd, job_namespace, job_title) 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 tables.sql, 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 MediaWiki bug 4445.

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 “$wgDebugLogFile = "/tmp/wiki.log";” 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:

sudo ln -s /usr/share/mediawiki/skins/ /var/www/wiki/ .

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). For MySQL 5.0, the page is at http://dev.mysql.com/doc/refman/5.0/en/common-errors.html. Visit the page for links to documentation for other versions of MySQL.

See Also

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

Language:	English  • 日本語