Manual:Common errors and symptoms - MediaWiki

Manual:Common errors and symptoms - MediaWiki
Jump to content
From mediawiki.org
Translate this page
Languages:
Nederlands
Türkçe
Yorùbá
català
magyar
polski
português
suomi
čeština
русский
עברית
فارسی
کوردی
বাংলা
中文
Install MediaWiki
Requirements
Extract
Upload
Set up database
Install
Configure
Upgrade
FAQ
Common issues
Get help and support
Local development quickstart
See also:
Manual:How to debug
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
error_reporting
E_ALL
);
ini_set
'display_errors'
);
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.
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.
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.
If you can see the page contents briefly, and suddenly the entire page goes blank, most likely the problem is caused by the presence of a
document.write
document.writeln
, or
document.open
JavaScript instruction in one of the scripts of the wiki.
You can check if that's the case if you open your browser console (hit F12) and reload the page.
If the network tab returns a HTTP 200 status, and the transfer is of several kilobytes, it's very likely this is the problem.
These are legacy methods of the
Document
interface that cause the entire page to become blank if it's used outside of the page HTML, and it may be present on the
wiki's JavaScript pages
Their usage is strongly discouraged, as indicated by the
HTML specification itself
You can disable JavaScript on your browser, or set
$wgUseSiteJs
and
$wgAllowUserJs
to
false
to disable those scripts until you fix the broken scripts.
MediaWiki Errors
Image Thumbnails not working and/or appearing
This section lists problems and solutions relating to thumbnails not rendering or displaying.
Error creating thumbnail: File missing:
This might happen due to wrong values of global variables as explained in:
Manual:$wgUploadDirectory
Manual:$wgUploadPath
Manual:$wgScriptPath
Decimal-point in srcset locale bug
If image thumbnails simply don't appear, and there's no error visible on those pages, look at the HTML source of the page and search for "
srcset
".
If you find something like

, where it appears
1,5x
instead of
1.5x
, the problem is caused by
T181987
, and you should add this to LocalSettings.php:
setlocale
LC_NUMERIC
"C"
);
SVG
See also:
Manual:Image administration
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
This page is
outdated
It was written for an older version of MediaWiki and may not apply to the most recent version. If you have checked or updated this page and found the content to be suitable, please remove this notice. See the
talk page
for a possible discussion on this.
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
according to this.
When using IIS/FastCGI on Windows, the guest account that is used also needs execute permission on C:\Windows\System32\cmd.exe otherwise you will receive an "Unable to Fork" error.
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
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 libjpeg is detected but not enabled during the
./configure
step; this is fairly prevalent on Red Hat/RHEL/CentOS systems.
If you don't want to use ImageMagick, the fix for this 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)
Unable to save thumbnail to destination
If you get the error "Error generating thumbnail / Error creating thumbnail: Unable to save thumbnail to destination" and the
$wgUploadDirectory
directory has the correct permissions (at all levels), check that
$wgTmpDirectory
actually exists.
(Unlike some path variables such as
$wgCacheDirectory
, $wgTmpDirectory is not created at runtime.)
A more detailed error message may be available if you turn on logging with
$wgDebugLogFile
This error can also occur when read only mode (
$wgReadOnly
) has been set in
LocalSettings.php
You can try to remove
$wgReadOnly
to see if that solves the issue for you.
Error creating thumbnail Error code: 25
If you get "Error creating thumbnail Error code: 25" with ImageMagick, try increasing
$wgMaxShellFileSize
Manually adding thumbnail files
In situations in which it's not feasible to create the thumbnails dynamically on request (e.g. for very large images, "Error creating thumbnail: unable to extend cache", "Error creating thumbnail: convert: no images defined", and similar), it is possible to manually add the thumbnail files.
This involves creating the smaller images in the desired sizes and uploading them to the
thumb/
directory in
$wgUploadDirectory
For example, a file that has uploaded to:
images/f/f8/Foo.png
should have its thumbnails at:
images/thumb/f/f8/Foo.png/100px-Foo.png
images/thumb/f/f8/Foo.png/600px-Foo.png
The pixel size is the horizontal dimension.
An example Bash script for creating thumbnails is available at
Phabricator:P7049
Error creating thumbnail: Error code: -1 on OVH mutualized hosting
For unidentified reason, creation of thumbnails on some mutualized OVH hosting are failing with this error, even if running the command in SSH shell works.
Solution is to specifically prevent from using ImageMagick by setting
$wgUseImageMagick
to
false
in LocalSettings.php:
$wgUseImageMagick
false
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.
Main page:
Manual:How to debug/Login problems
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
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 ← users will get prompted and have to enter domain credentials, same as BASIC mode
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)
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 CSS styles applied (no colors, no backgrounds, no images, very minimal formatting, etc) if you access it from other machines (or some of them), the most probable cause is that the server is having problems with determining 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
Don't forget the port number if you are using a non-standard port as may by the case if your ISP has blocked port 80 (Example:
$wgServer
"http://example.domain.com:8080"
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 so, it may be a problem with the web server's
.htaccess
file.
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 are 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.
This can also happen if you have APC enabled, setting
apc.serializer=php
in php.ini might help.
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
pcre.backtrack_limit
set up on some distributions like FreeBSD.
It's known to have problems with values of 10,000.
Increase that value to 100,000, or the current default of 1,000,000.
Since MediaWiki 1.26, some skins, and specially Vector, may have this problem.
If you see the error
Internal error Problematic modules: {"startup":"error"}
in the error console of your browser, most likely cause is the lack of permissions of MediaWiki to write to the default temp folder, either because PHP has no permissions to write to
/tmp
C:\WINDOWS\TEMP
on Windows), or because there's an
open_basedir
restriction and that path isn't included on it.
See
T119934
You can also set
$wgTmpDirectory
if you are unable to change permissions on the system's default temp directory.
Error: invalid magic word 'speciale'
MediaWiki version:
1.20
If you get that error message after upgrading, you must run the
rebuildLocalisationCache.php
maintenance script with the
--force
option:
php rebuildLocalisationCache.php --force
Localised strings show their message ID instead of a localized result
If you are seeing this, try running the
rebuildLocalisationCache.php
maintenance script with the
--force
option:
php rebuildLocalisationCache.php --force
This will force MediaWiki to rebuild the localisation cache.
Missing edit toolbar, JavaScript not working
Since
MediaWiki 1.32
, MediaWiki no longer has a "JavaScript-powered" wikitext toolbar built in. The old "bulletin board style toolbar", known as "the 2006 wikitext editor", has been removed, and instead sysadmins will be required to choose one (or more) of the several extensions available for this purpose if they need the functionality. The MediaWiki "tarball" releases have included the replacement extension for this, the
WikiEditor
extension aka "the 2010 wikitext editor", for many years now. Be sure this extension has been installed.
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 (usually by hitting
F12
), reload the page and see if any error message appears there.
If it displays an error, usually, setting
$wgShowExceptionDetails
would give you more information.
Sometimes the problem is that the system's temp directory is not writable.
In that case, you can also set
$wgTmpDirectory
if you are unable to change permissions on the system's default temp directory.
If you get errors like
Uncaught SyntaxError: Unexpected token <
or
Error: SyntaxError: syntax error (...) Source Code: