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 20 MB replace the existing text with " ". Make sure to restart your Apache server 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.

SVG

 * See also: Manual:Image Administration SVG


 * Ensure that your $wgImageMagickConvertCommand variable is valid. Common settings are:
 * $wgImageMagickConvertCommand = "/usr/bin/convert";
 * $wgImageMagickConvertCommand = "/usr/local/bin/convert";

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</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 = 32M      ; Maximum amount of memory a script may consume (32MB)
 * Raise PHP's memory limit in LocalSettings.php: ini_set( 'memory_limit', '32M' );

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

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 (...)
I've installed the Mediawiki on a Windows-XP-Server with XAMPP an the Wiki runs and it works fine. But when i install an extension, i get this error:
 * Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\htdocs\MinjusWiki\LocalSettings.php:1) in C:\xampp\htdocs\MinjusWiki\includes\WebResponse.php on line 10

it doesn't matter which Extension, i get it always. Version: MediaWiki 1.13.2 PHP 5.2.2 (apache2handler) MySQL 5.0.41-community-nt --JimHawk 07:54, 1 December 2008 (UTC)


 * "output started at C:\xampp\htdocs\MinjusWiki\LocalSettings.php:1" means that your LocalSettings file is generating output, which it shouldn't. there's either a blank line at the start of the file, or, more likely, an invisible BOM at the very start of the file. Especially Windows Notepad is prone to add that stuff, and PHP chokes on it. I think NOtepad can be set to not write a BOM, but using a decent editor (read: anything else) would help in any case. -- Duesentrieb ⇌ 09:03, 1 December 2008 (UTC)
 * Thank you! It works for me. Saved file as "Unicode (UTF-8 Without signature) - Codepage 65001" --Volodymyr Obrizan 14:44, 22 October 2009 (UTC)

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 you're 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 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> characters to 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.