Manual:Common errors and symptoms/ja

空白のページが表示される

 * PHPエラーを示す空白のページを、スクリーンに表示させない. これを強制するためには、次の行をLocalSettings.phpの&lt;?phpの下部に追加して下さい:


 * error_logの値をPHP.iniに設定して何が起きているのかを理解するためにPHPエラーログを見ることが出来ます. PHPエラーはウェブサーバエラーログにも記録されることがあります.


 * 多くの人は最近のバージョンのwikiに記事を投稿した後に空白ページを報告します. よくある原因はPHPのメモリ制限です(通常は8MBに設定されています). PHPとApacheエラーログを確認するようお願いします. この設定を修正するために を編集して"memory_limit"で設定されているメモリー量を増やして下さい. 20MBに増やしたい場合、" "とします. この値を変更した後にApacheサーバを再起動して下さい.


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


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


 * 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  entry in the php.ini file.

SVG

 * See also: Manual:Image Administration SVG

First, determine your $wgSVGConverter setting. By default, it is set to use ImageMagick for conversion.

ImageMagick の使用

 * You need at least ImageMagick 6.x.x.
 * Ensure that your $wgImageMagickConvertCommand variable is valid. Common settings are:
 * $wgImageMagickConvertCommand = "/usr/bin/convert";</tt>
 * $wgImageMagickConvertCommand = "/usr/local/bin/convert";</tt>
 * If it does not work, try setting $wgSVGConverterPath.
 * $wgSVGConverterPath = "/usr/bin";</tt>
 * $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.


 * 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</tt>
 * when it's not available run locale-gen en_US.utf8</tt> or put in the locales with UTF-8 for your country and change the value for $wgShellLocale accoring to this

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.

rsvg の使用
On some Linux and BSD installations rsvg is renamed:

Instead of setting (default) you would like to set

JPEG (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.
 * 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.
 * You may be attaching to an old, stale session. If you see old session files in your session.save_path directory delete them.

内容の制限

 * ApacheサーバがHardened PHP patchを使用しており、Wikiが大容量のページを持つことが出来るようにしたい場合、/etc/php.iniファイルにあるいくつかの変数を編集する必要があることがあります. とりわけ、varfilter.max_value_length、hphp.post.max_value_lengthとhphp.request.max_value_lengthの設定を考えて下さい. デフォルトの設定は10Kもしくは64k以下にページサイズを制限している可能性があります.
 * 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.

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.

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  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 should see a comment similar to.

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  option:

php rebuildLocalisationCache.php --force

This can happen at least upgrading to 1.20.

Missing edit toolbar, JavaScript not working
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, reload the page and see if any error message appears there.

If you get errors like  or , the cause is usually a hosting provider that is automatically injecting HTML code for tracking or advertising inside the load.php script, which is used by ResourceLoader to load the scripts and CSS used by MediaWiki. Open a support ticket with your hosting provider asking them to disable that injection. If that's not possible, you should migrate your site to another hosting provider. That usually happens on free hosting providers.

Fatal error: Allowed memory size of nnnnnnn bytes exhausted (tried to allocate nnnnnnnn bytes)

 * php.iniにあるPHPのメモリ制限を上げて下さい: memory_limit = 64M      ; スクリプトが消費するメモリの最大量です(32MB)

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

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

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

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  configuration variable of PHP is set to , 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  function exists, replace it with:

You can turn off PHP errors entirely using this instead:

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 " " and verify there's nothing (even whitespace) before " ".

Fatal Error: Cannot redeclare wfprofilein
This could happen if you upgraded and you have a  file in the root MediaWiki installation directory, probably because you enabled profiling in an old installation. To solve the issue simply remove that file.

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

 * wikidb.*にパーミッションを与える必要があります - Manual:Installation/jaをご覧下さい
 * もしくはウェブサーバがDBサーバとは異なるボックス上にある場合 - MySQLにリモートアクセスをする権限を設定しなければなりません
 * 注意: 192.168.0.xをあなたのウェブサーバのIPアドレスに書き換えてください
 * 注意: 192.168.0.xをあなたのウェブサーバのIPアドレスに書き換えてください
 * 注意: 192.168.0.xをあなたのウェブサーバの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サポートがインストールされていない/有効になっていません -　http://www.php.net/manual/ja/ref.mysql.php をご覧下さい

ファイル名の大文字小文字の違いによるエラー
ファイルをサーバにアップロードするためにFileZillaよりも異なるFTPクライアントを使用する場合、大文字、小文字のファイル名を強制しないようにクライアントを設定して下さい. MediaWikiのファイル名は大文字と小文字を区別します.

不完全なアップロードエラー
MediaWikiパッケージは数十のディレクトリまで広がる多くのパッケージを含んでいます. アップロードをするときに注意して下さい. 転送が中断されたとき、転送されたファイルが失われるもしくは不完全であることがあります. 信頼できない接続がある場合、何回かアップロードをリトライしなければならない場合があります.

シンボリックリンクによる403 Forbidden
ウェブサーバが"403 Forbidden error"を出力してシンボリックリンクを使用している場合、Apacheのhttpd.confファイルがシンボリックリンクを許可するためにOptions FollowSymLinksを設定をしていて、リンクをされたディレクトリを下準備しているそれぞれのディレクトリがユーザが動作させるhttpdのために+xパーミッションを持っていることを確認して下さい.

内部エラー
インストール作業の始めにウェブサーバが"500 Internal Error"を返す場合、configフォルダのパーミッションを755に変更する必要があることがあります. configディレクトリのためにパーミッションを変更した場合、まだ書き込みできないエラーを得る場合、所有者をapacheに変更してみて下さい. chown -R apache:apache /var/www/html/mediawiki/*

SELinux
SELinux('Security Extensions')をサポートするLinuxディストリビューションはより広まっています. それらのシステム上では、PHPスクリプトは通常のファイルパーミッションを設定した後で、configディレクトリに書き込むことはできません. SELinuxファイルタイプを変更するために'chcon'コマンドも使用する必要があります. SELinuxをご覧下さい.

ホスティングされたサイトで広告を要求される
MediaWiki ソフトウェアをバナーの設置または広告の前置を要求する無料サイト上で動作させる場合、このことが原因で MediaWiki が動作せず、バナー広告を越えて空のページだけを生成することがあります. このことに対する修正は将来なされます. それまでの間、唯一の選択は有料ホスティングサイトを見つけることです. これはバグとも考えられ、報告されます.

Debian、Apache2、と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: If you need to install the php5-mysql module enter: Then restart Apache2:
 * 1) pkg --list | grep php5-mysql
 * 1) apt-get install php5-mysql
 * 1) /etc/init.d/apache2 restart

'user_password' can't have a default value
MySQLがstrict modeで動いていないことを確認して下さい.

指定したキーが長すぎる
"experimental UTF-8"を選択した場合、"specified key was too long"のタイプのMySQLが起こることがあります. 解決する方法の一つはmaintenance/tables.sql</tt>を編集して、問題を起こしているテーブルがより短いキーを使用するようにします. (MediaWikiのバージョンによって、<tt>tables.sql</tt>も編集する必要があります; 例えば、MySQL 5で1.6.10を使用する場合、<tt>maintenance\mysql5\tables.sql</tt>です. )

例えば、次のようなエラーメッセージを見る場合です: 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)".

tables.sqlで"job"テーブルを見つけ、<tt>KEY (job_cmd, job_namespace, job_title)</tt>を<tt>KEY (job_cmd(160), job_namespace, job_title(160))</tt>のようなもので置き換えます.

(ポイントはvarcharフィールドを3倍にするときでも(UTF-8の文字は3バイト使用するので)、すべてのKEY宣言のすべてのフィールドの全体の長さはエラーメッセージで述べられた最大のキーサイズよりも小さくすることです. )例えば、job_cmdがvarchar(255)、job_namespaceがint、job_titleがvarchar(255)であるとすると、<tt>KEY (job_cmd, job_namespace, job_title)</tt>の全体のキーの長さは3*255 + 4 + 3*255 = 1534で、1024より大きいので、3*160 + 4 + 3*160 = 964に置き換えればOKです. ) <tt>tables.sql</tt>を修正した後で、前に作成したすべてのテーブルをドロップして、インストールスクリプトを再実行しなければなりません(エラーメッセージのページをリロードします. この方法ではすべてを再入力する必要はありません). いくつかのテーブルでこのエラーを得た場合 - jobとpage_restrictionsは影響受ける可能性があるものです.

MediaWiki bug 4445もご覧下さい.

テーブルの接頭辞(table prefix)が見つからない
ホスティングサービスを利用している場合、データベース名とデータベースユーザ名は余分な接頭辞を持つことがあります(通常はホスティングプロバイダによるユーザidです). 例えば、データベース名がdb01でユーザidがocomの場合(ホスティングプロバイダによって与えられたもの)、データベース名とユーザ名はそれぞれocom_db01とocom_u01を入力します.

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:

.

MySQL の接続がエラー [2013] または [2002] で失敗する
If you are getting the error: or , 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.

関連項目

 * Manual:Config script/ja
 * Manual:How to debug/ja