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.

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.

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.

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.

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.

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.

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

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

E-mail can't be sent

You get the following error, or similar when trying to get authentication:

Rückmeldung des Mailservers: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '2.0/DST' instead

No solution for this - please refer to a solution?

ANSWER: This is a problem between MediaWiki and PHP. Localsettings.php has nothing to do with it. You have to edit php.ini with the appropiate timezone settings. In my case:

date.timezone = "America/Montevideo"

There is a list of available sites. Browse "timezone settings". Hope this is useful.

See http://php.net/manual/en/timezones.php

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  • 日本語