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 LocalSettings.php file, underneath the &lt;?php:


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

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";</tt>


 * 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</tt> or /usr/local/bin/convert --version</tt> 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.

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</tt> 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</tt> switches were, and add --with-jpeg-dir</tt> before --with-gd</tt>.

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</tt> then service apache start</tt> ). 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.
 * After making changes restart Apache:
 * /etc/init.d/httpd restart
 * If you use memcached and enable $wgSessionInMemcached, 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.
 * 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.

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)

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

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
 * NOTE: Replace 192.168.0.x with your Webserver's IP
 * NOTE: Replace 192.168.0.x with your Webserver's IP

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.

Warning: getrusage is not supported in this PHP build
Text needed

Internal Error
If your webserver produces a "500 Internal Error" at the beginning of the install process, you may need to change the permissions on the config folder 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</tt> so that the table causing the problem uses shorter keys. (Depending on MediaWiki version, there might be other tables.sql</tt> files you also need to change; for example, maintenance\mysql5\tables.sql</tt> 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)</tt> with something like KEY (job_cmd(160), job_namespace, job_title(160))</tt>.

(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)</tt> 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 <tt>tables.sql</tt>, 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.

A MySQL installation of MediaWiki 1.8.2 on a shared host failed to display the database table prefix input box. The form field was generated in the configuration page with no-display attributes. If you experience this problem, the addition of the <tt>//</tt> characters to <tt>config/index.php</tt> as shown below will cause this field to re-materialize. This input box is not needed unless more than one MediaWiki instance is being installed into a single database, so most installations will not need to do this, whether the field is present or not. <?php // database_switcher('mysql'); ?> <?php aField( $conf, "DBprefix", "Database table prefix:" ); ?>

The problem persists in MediaWiki 1.9.3. Subsequent experience suggests that the optional database portion of the installation form (which comes up with a yellow background for MySQL options, and blue for Postgres options) can be activated--if it does not appear on its own--with extra clicks on the database selection radio buttons (observed to work under Firefox 1.5)

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: