• 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。(詳細

このWikiはいつでも誰でも編集できます

「wp-config.php の編集」の版間の差分

提供: WordPress Codex 日本語版
移動先: 案内検索
(現在最新の9月26日分までの差分を追加しましたー。)
(Disable Cron and Cron Timeout: を翻訳してみました。)
790行目: 790行目:
 
  define('ALTERNATE_WP_CRON', true);
 
  define('ALTERNATE_WP_CRON', true);
  
=== Disable Cron and Cron Timeout ===
+
=== Cronの無効化と、Cronタイムアウト時間 ===
 +
<tt>DISABLE_WP_CRON</tt> を true に設定することにより、cron を完全に無効化することができます。
 +
 
 +
define('DISABLE_WP_CRON',true);
 +
 
 +
また、cron の処理は <tt>WP_CRON_LOCK_TIMEOUT</tt> で設定した期間(単位:秒)は連続して実行されないようになっていることに注意してください。
 +
 
 +
define('WP_CRON_LOCK_TIMEOUT',60);
 +
 
 +
<!--
 +
Disable Cron and Cron Timeout
 +
 
 
Disable the cron entirely by setting <tt>DISABLE_WP_CRON</tt> to true.   
 
Disable the cron entirely by setting <tt>DISABLE_WP_CRON</tt> to true.   
 
  define('DISABLE_WP_CRON',true);
 
  define('DISABLE_WP_CRON',true);
796行目: 807行目:
 
Make sure a cron process cannot run more than once every <tt>WP_CRON_LOCK_TIMEOUT</tt> seconds.
 
Make sure a cron process cannot run more than once every <tt>WP_CRON_LOCK_TIMEOUT</tt> seconds.
 
  define('WP_CRON_LOCK_TIMEOUT',60);
 
  define('WP_CRON_LOCK_TIMEOUT',60);
+
-->
 +
 
 
<div id="Additional_Defined_Constants">
 
<div id="Additional_Defined_Constants">
 +
 
=== 他の定義定数 ===
 
=== 他の定義定数 ===
 
</div>
 
</div>

2013年11月10日 (日) 16:26時点における版

このページを編集する際、自分の MySQL データベースのパスワード情報などを入力しないでください。

wp-config.php ファイルは、WordPressの環境設定を行なう重要なファイルです。WordPressがMySQLデータベースに接続するために必要な情報のほか、任意でその他の高度な設定を定義できます。

このファイルは通常、新規インストールスクリプトの実行中に自動的に生成されますが、上手くいかないときは下記の手順で作成してください。

アップグレード時の注意:
最新版にアップグレードする場合、このファイルを作り直す必要はありません。ただし、
  • セキュリティ向上のため、セキュリティ・キーが存在しない場合、これだけは追加してください。
  • wp-includes/wp-db.php に「SET NAMES 'utf8'」を挿入して運用していた場合、2.2 以降では本体ファイルの修正は不要です。DB_CHARSET 設定をお使いください。

注: Version 2.6 から、wp-config.php ファイルを WordPress ディレクトリの真上のディレクトリに移動できるようになりました(参照)。


用意するもの

重要: Microsoft Word のようなワープロソフトは、WordPress ファイルの編集には 絶対に使わないでくださいWordPress 日本語版をお使いの場合、Windows のメモ帳(Notepad)も使えません。(使えるテキストエディタ

目次

  • テキストエディタ
  • データベースへの接続情報
    新規インストール時に wp-config.php を編集するには、次の情報が必須です。
    • データベース名: WordPress が使うデータベース名
    • データベース・ユーザ名: データベースへのアクセスに使うユーザ名
    • データベース・パスワード: データベースへのアクセスに使うパスワード
    • データベース・ホスト: データベースサーバのホスト名。ポート番号、UNIX ソケットファイルパスまたはパイプが必要になる場合もあります。

ホスティング・プロバイダ(レンタルサーバ)側で WordPress をインストールしてくれたのであれば、接続情報はそちらから得られます。自分でウェブサーバやホスティング・アカウントを管理しているなら、データベースとユーザを作成したときにこの情報を得ているはずです。

注: wp-config-sample.php の内容は決まった順序に従って書かれています。ファイル内での順番を変更するとエラーが発生する場合もあるため、注意してください。

wp-config.php ファイルの編集手順

wp-config.php ファイルは、WordPress のダウンロードファイルの中には存在しません。同梱されている wp-config-sample.php ファイルを見本にして、自分で wp-config.php というファイルを新規作成してから編集を始めてください。高度な設定や例は以下の通りです。

  1. 自分の WordPress のルートディレクトリ(フォルダ)にある wp-config-sample.php ファイルを同じディレクトリ内に複製して、ファイル名を wp-config.php に変更します。
  2. wp-config.phpテキストエディタで開き、自分の環境に合わせてデータベース設定セキュリティ・キーの値を書き換えます(その他はオプション)。
  3. 書き換え終わったら、もう一度見直しましょう!
    • 入力した値の前後に余計な空白が入っていないか?
    • 値を囲むシングルクオート(')をうっかり消してしまっていないか?
    • ファイルの先頭は <?php、最後の行は require_once(ABSPATH . 'wp-settings.php'); で終わり、その後ろに空行やスペースを入れないようにします。また、末尾の ?> も必要ありません(変更履歴 2.8を参照)。
  4. ファイルを保存します。
    (注) UTF-8 BOMありで保存してはいけません[1]

データベース設定

デフォルトの wp-config-sample.php では次のようになっています。この初期値を、最初に用意した自分のデータベース設定で置き換えていきます。

// ** MySQL 設定 - この情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define('DB_NAME', 'database_name_here');

/** MySQL データベースのユーザー名 */
define('DB_USER', 'username_here');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'password_here');

/** MySQL のホスト名 */
define('DB_HOST', 'localhost');

/** データベースのテーブルを作成する際のデータベースの文字セット */
define('DB_CHARSET', 'utf8');

/** データベースの照合順序 (ほとんどの場合変更する必要はありません) */
define('DB_COLLATE', '');

/* */ の内側は、編集案内のためのコメントで、単に説明を追加しているだけです。

データベース名の設定

define('DB_NAME', 'putyourdbnamehere');

database_name_here の部分だけを消して、あなたのデータベース名を入力してください。シングルクォーテーションマーク(')を誤って消さないように注意!

この行は次のようになったはずです。

define('DB_NAME', '自分のデータベース名');

他の項目も同じように修正していきましょう。

データベース・ユーザ名の設定

username_here の部分をあなたのデータベース・ユーザ名で置き換えます。

define('DB_USER', '自分のデータベース・ユーザ名');

データベース・パスワードの設定

password_here の部分をあなたのデータベース・パスワードで置き換えます。

define('DB_PASSWORD', '自分のデータベース・パスワード');

データベース・ホストの設定

ここではあなたのデータベースのホストを定義します。ポート番号、UNIX ソケットファイルパスまたはパイプが必要になる場合もあります。

define('DB_HOST', 'localhost');

注:ここは、ホスティング側から指示がない限り、変更しなくて済む可能性が高いでしょう。下記の一覧に載っていなくて、ホスト名が分からないときは、初期値 'localhost' のままインストールしてみてください。インストールに失敗したら、ホスティングプロバイダ(レンタルサーバ)に問い合わせてください。

DB_HOST 値の候補

ホスティング会社によって MySQL データベースのネットワーク設定が異なります。利用中のホスティングサービス名が以下の表に載っていれば、その右側の値と同じか似たような値でしょう。念のため、ホスティングサービスのオンライン説明書や FAQ のページを見るか、テクニカルサポートに問い合わせてください。

日本のホスティングサービス DB_HOST 値
XREA (無料サーバ) localhost
エックスサーバー mysqlnn.xserver.jpnn は数字)
さくら mysqlnn.db.sakura.ne.jpnn は数字)
チカッパ! mysqlnn.chicappa.jpnn は数字。コントロールパネルの DB の「サーバー」)
freeweb (無料サーバ) localhost
海外のホスティングサービス DB_HOST 値
inetd dbn.inetd.co.jpn は数字)
1and1 db12345678 の形式
AN Hosting、A Small Orange、BlueHost、HostGator、HostICan、LaughingSquid、one.com localhost
cPanel または Plesk、DirectAdmin を使っているサーバー localhost
DreamHost mysql.example.com の形式
GoDaddy MySQL のデータベース編集画面でサーバー名を確認
ICDSoft localhost:/tmp/mysql5.sock の形式
MediaTemple (dv) localhost
MediaTemple GridServer internal-db.s44441.gridserver.com の形式
pair Networks dbnnnx.pair.com の形式
Rackspace Cloud mysql50-01.wc1.dfw1.stabletransit.com の形式
Yahoo mysql
Tophost.it sql.your-domain-name.it
MySQL 代替ポート

もし利用しているホスティングサービスがデータベース用に代替ポート番号を使っている場合、DB_HOST 値を変更する必要があります。

localhost の場合:

define( 'DB_HOST', 'localhost:3307' );

その他の場合:

define( 'DB_HOST', 'mysql.example.com:3307' );

3307 の数字を、ホスティングサービスが提示するポート番号に変更してください。

MySQL ソケットまたはパイプ

ホスティングサービスで Unix ソケットまたはパイプが使われている場合、wp-config.php ファイル内の DB_HOST の値を適宜変更してください。

define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );

/var/run/mysqld/mysqld.sock を、ホスティングサービスから提供された情報と入れ替えてください。

↑ 編集手順に戻る

データベース・キャラクタセット

WordPress バージョン 2.2 から、 DB_CHARSET で MySQL データベーステーブルの定義に使われるデータベースキャラクタセット(文字コードセット。例: タイの TIS620 用 tis620)の指定ができるようになりました。 デフォルト値 utf8Unicode UTF-8)は、ほとんどの場合に適した設定です。UTF-8 はどの言語にも対応しているので、通常、DB_CHARSET は utf8 のままにしておき、自分の言語に合う DB_COLLATE を使うべきです。

新規インストール実行時の注意
ほとんどの欧米言語では、DB_CHARSET の初期値を変更する理由はないはずです。ブログを他の文字コードセットにする必要があるなら、DB_CHARSET に正しい値を設定するために、MySQL でサポートされるキャラクタセットと照合順序(5.1)(4.1)をお読みください。
アップグレード実行時の注意 (特に 2.2 以前から設置しているブログの場合)
wp-config.php ファイルに DB_CHARSETDB_COLLATE の行が存在しない場合、DB 文字コードセットの変換を読んで理解しない限り、どちらの定義も wp-config.php ファイルに追加しないでください。既存ブログの wp-config.php ファイルに DB_CHARSETDB_COLLATE を追加すると、不具合が生じる可能性があります。
"SET NAMES 'utf8'" を挿入していた場合
2.1.3 以前に WordPress コアファイルに SET NAMES 'utf8' を挿入して運用していた場合は、その修正の替わりに DB_CHARSET 定義を使えるようになりました。SET NAMES 文は WordPress 2.2 で本体に組み込まれ、DB_CHARSET の値が使われます。

次の例は、WordPress の初期値 'utf8' の場合です。

define( 'DB_CHARSET', 'utf8' );

↑ 編集手順に戻る

データベース照合順序

WordPress バージョン 2.2 から、DB_COLLATE で データベース照合順序(キャラクタセットのソート順)の指定ができるようになりました。ほとんどの場合、データベース照合順序は、データベース・キャラクタセット(DB_CHARSET)に基づいて MySQL によって自動的に割り当てられるので、この値は空(null)のままでいいはずです。DB_COLLATE には、ほとんどの欧米言語では Unicode キャラクタセット(utf8 照合順序)に記載されている UTF-8 の値の一つを設定します。

新規インストール実行時の注意
通常は、DB_COLLATE の初期値を変更する理由はないはずです。値を空(null)のままにしておけば、データベース作成時に MySQL によって自動的に割り当てられた照合順序となります。
アップグレード実行時の注意 (特に 2.2 以前から設置しているブログの場合)
wp-config.php ファイルに DB_CHARSETDB_COLLATE の行が存在しない場合、DB 文字コードセットの変換を読んで理解しない限り、どちらの定義も wp-config.php ファイルに追加しないでください。既存ブログの wp-config.php ファイルに DB_CHARSETDB_COLLATE を追加すると、不具合が生じる可能性があります。

WordPress の DB_COLLATE の初期値:

define( 'DB_COLLATE', '' );

照合順序が UTF-8 Unicode General の場合

define( 'DB_COLLATE', 'utf8_general_ci' );

照合順序を UTF-8 Unicode Turkish にする必要がある場合の例(DB_CHARSET は utf8):

define( 'DB_COLLATE', 'utf8_turkish_ci' );

↑ 編集手順に戻る

認証用ユニークキー

Version 2.6 から、ユーザーの Cookie に格納される情報をより強固な暗号化によって守るため、AUTH_KEYSECURE_AUTH_KEYLOGGED_IN_KEY という3種の認証用ユニークキーが追加されました。さらに Version 2.7 からは、4つめのキー NONCE_KEY が加わりました。キーが追加された際に、対応するソルト AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT が追加されています。

define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');

このキーを覚えておく必要はありませんので、オンラインジェネレータを使ってできるだけ長く、ランダムで複雑な組み合わせを作ってください。Cookie をすべて無効化したい場合はこの値を変更できますが、すべてのユーザーが再度ログインする必要があることに注意してください。

例(この値は使用しないでください):

define('AUTH_KEY',         't`DK%X:>xy|e-Z(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@}IcnCa|');
define('SECURE_AUTH_KEY',  'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj');
define('LOGGED_IN_KEY',    'MGKi8Br(&{H*~&0s;{k0<S(O:+f#WM+q|npJ-+P;RDKT:~jrmgj#/-,[hOBk!ry^');
define('NONCE_KEY',        'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe');
define('AUTH_SALT',        '7T-!^i!0,w)L#JK@pc2{8XE[DenYI^BVf{L:jvF,hf}zBf883td6D;Vcy8,S)-&G');
define('SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F }F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #');
define('LOGGED_IN_SALT',   'w<$4c$Hmd%/*]`Oom>(hdXW|0M=X={we6;Mpvtg+V.o<$|#_}qG(GaVDEsn,~*4i');
define('NONCE_SALT',       'a|#h{c5|P &xWs4IZ20c2&%4!c(/uG}W:mAvy<I44`jAbup]t=]V<`}.py(wTP%%');

秘密鍵(シークレットキー) とは、パスワードにランダムな要素を加えることによってサイトへの不正アクセスや侵入・改竄を難しくする「ハッシュ用 salt」です。

簡単に言えば、秘密鍵はセキュリティの壁を破るのに必要なオプションを生成する難易度を高めるための要素を加えたパスワードです。「password」や「test」のようなパスワードは単純で簡単に破られてしまいます。「88a7da62429ba6ad3cb3c76a09641fc」のようにランダムで推測できないパスワードであれば、正しい組み合わせを見つけ出すまでには何年もかかるでしょう。

秘密鍵や堅牢なパスワードについての技術的な背景や分析について、詳しくは以下の資料をご覧ください。

↑ 編集手順に戻る

言語および言語ディレクトリ

WPLANG は、言語翻訳ファイル(.mo)の名前を定義します。プラグインやテーマの言語ファイル名の部分にも WPLANG の値が使われます。 LANGDIR は、WPLANG .mo ファイルが存在するディレクトリを定義するものです。LANGDIR が定義されていなければ、WordPress は wp-content/languageswp-includes/languages の順に .mo ファイルを 探します。詳しくは 言語ファイルのインストールをご覧ください。

define('WPLANG', 'de_DE');
define('LANGDIR', 'mylanguagedirectory');

WordPress 日本語版では、WPLANG の初期値は 'ja' です。

/**
 * ローカル言語 - このパッケージでは初期値として 'ja' (日本語 UTF-8) が設定されています。
 *
 * WordPress のローカル言語を設定します。設定した言語に対応する MO ファイルが 
 * wp-content/languages にインストールされている必要があります。例えば de.mo を 
 * wp-content/languages にインストールし WPLANG を 'de' に設定することでドイツ語がサポートされます。
 */
define ('WPLANG', 'ja');

↑ 編集手順に戻る

上級オプション

以下のセクションには上級/未対応の情報が含まれている可能性があります。いつものバックアップを確実に実行し、設定を試す前に復元方法を確認しておいてください。

$table_prefix : データベース・テーブル名の接頭辞

$table_prefix は、データベース・テーブル名の先頭に付ける値です。データベースの接頭辞を wp_ 以外にしたい場合、この値を変更してください。主に、同じデータベースで複数の WordPress ブログを設置/en するときに変更します。

値には半角英数字とアンダースコア(_)のみ使えます。

$table_prefix = 'wp_';

WordPress 日本語版

/**
 * WordPress データベーステーブルの接頭辞
 *
 * それぞれにユニーク (一意) な接頭辞を与えることで一つのデータベースに複数の WordPress を
 * インストールすることができます。半角英数字と下線のみを使用してください。
 */
$table_prefix = 'wp_';

同じデータベースに2つめのブログをインストールするには、1つめとは異なる接頭辞を用いるだけです。

$table_prefix = 'y77_';  // 半角英数字またはアンダースコアのみ

WordPress アドレス (URL)

WP_SITEURL は、「WordPress アドレス (URL)」を定義できるオプションであり、バージョン 2.2 で追加されました。ここで定義する値は、WordPress のコアファイルが存在する URL です。http:// の部分は記入し、末尾にスラッシュ "/" は入れないでください。wp-config.php でこの値を設定すると、wp_options テーブルoption_value siteurl の値よりも優先され、管理パネル > 設定 > 一般設定画面の「WordPress アドレス (URL)」欄は無効となります。

注: wp-config.php からこの行を削除すると、URL は元のデータベースの値に戻ります。データベースの値は変わりません。データベースの siteurl 値を書き換えるには RELOCATE 定数を使います/en

例えば、"example.com" というドメイン名の "wordpress" というディレクトリの中に WordPress を設置した場合、WP_SITEURL は次のように定義します。

define('WP_SITEURL', 'http://www.example.com/wordpress'); 

$_SERVER['HTTP_HOST'] を基に WP_SITEURL を動的に定義するには:

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress');

注: 一部の設置の場合により安全な方法は、PHP またはユーザー側が生成した HTTP_HOST を使う代わりに、サーバーが生成した SERVER_NAME を使うことです。 HTTP_HOST は リクエストヘッダ内の値から PHP によって動的に生成されているため、ファイル混入脆弱性の可能性があります。SERVER_NAME はサーバー設定によって決定する静的な値です。

$_SERVER['SERVER_NAME'] を基に WP_SITEURL を動的に定義するには:

define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress');

ブログアドレス (URL)

WP_HOMEバージョン 2.2 で追加された wp-config.php オプションです。WP_SITEURL と同じく、WP_HOME も wp_options テーブルhome の値よりも優先されますが、恒久的に変更する訳ではなく、ここに定義している間だけ切り替えるものです。home は、あなたの WordPress ブログに訪れる人がブラウザに入力するアドレス(URL)です。http:// の部分は記入し、末尾にスラッシュ "/" を入れてはいけません。

define('WP_HOME', 'http://www.example.com/wordpress'); 

WordPress を専用ディレクトリに配置する設定を行なっている場合は、次の例のようになります。ドキュメントルートディレクトリに index.php を置くことも忘れないでください。

define('WP_HOME', 'http://www.example.com'); 

$_SERVER['HTTP_HOST'] を基に WP_HOME を動的に定義するには:

define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress');

wp-content ディレクトリの移動

Version 2.6 以降では、テーマやプラグイン、アップロードファイルなどがある wp-content ディレクトリを WordPress アプリケーションディレクトリの外に移動できます。

WP_CONTENT_DIR にこのディレクトリのフル「ローカルパス」を指定する例(末尾のスラッシュ(/)なし)

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/blog/wp-content' );

WP_CONTENT_URL にこのディレクトリのフル「URL」を指定する例(末尾のスラッシュ(/)なし)

define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');

プラグインディレクトリの移動

WP_PLUGIN_DIR にこのディレクトリのフル「ローカルパス」を指定する例(末尾のスラッシュ(/)なし)

define( 'WP_PLUGIN_DIR', dirname(__FILE__)  . '/blog/wp-content/plugins' );

WP_PLUGIN_URL にこのディレクトリのフル「URL」を指定する例(末尾のスラッシュ(/)なし)

define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins');

プラグインとの互換性に問題がある場合、PLUGINDIR にこのディレクトリのフル「ローカルパス」を指定する例(末尾のスラッシュ(/)なし)

define( 'PLUGINDIR', dirname(__FILE__)  . '/blog/wp-content/plugins' );

テーマディレクトリの移動

UPLOADS を下記のように指定します。

define( 'UPLOADS', '/blog/wp-content/uploads' );

パスは絶対パスにはできません。ABSPATH に対する相対パスで指定してください。

アップロードディレクトリの移動

UPLOADS を下記のように指定します。

define( 'UPLOADS', '/blog/wp-content/uploads' );

このパスは絶対パスにはできません。ABSPATH からの相対パスになります。

自動保存間隔の変更

投稿を編集する際、WordPress は Ajax を使って編集中の状態を自動保存します。自動保存の間隔を延ばすにはこの値を増やし、編集を確実に保存するにはこの値を減らします。初期値は 60秒です。

define('AUTOSAVE_INTERVAL', 160 );  // seconds

投稿の改訂履歴

WordPress の初期設定では、投稿やページの編集毎に複製が保存され、その投稿・ページを旧バージョンの版に戻せるようになっています。この改訂履歴の保存機能は無効にしたり、保存する版数を指定したりできます。

投稿の改訂履歴保存の無効化

WP_POST_REVISIONS を設定していない場合は、デフォルトで true(投稿の改訂履歴機能が有効)になっています。この機能を無効にするには、次のように設定します。

define('WP_POST_REVISIONS', false );

注: 一部のユーザーには config.php の最初のブロックコメントの真下にコマンドを移動するまでこの関数が見つからない場合があります。

改訂履歴の最大数の指定

改訂の保存版数の最大値を指定したい場合、false を整数(数字。例えば 35)に変更します。

define('WP_POST_REVISIONS', 3);

注: 一部のユーザーには config.php の最初のブロックコメントの真下にコマンドを移動するまでこの関数が見つからない場合があります。

一般的でないドメイン設定をしている場合、Cookie 内で WordPress の使うドメインを指定することもできます。例えば静的コンテンツを提供するためのサブドメインを設定している場合などです。WordPress Cookie がサブドメイン内の静的コンテンツへのリクエストの度に送信されるのを防ぐには、Cookie ドメインを非静的ドメインのみに指定します。

define('COOKIE_DOMAIN', 'www.example.com');

マルチサイト/ネットワークの有効化

WP_ALLOW_MULTISITE は、WordPress Version 3.0 で導入されたマルチサイト機能を有効にする機能です。以前は WordPress MU が提供されていました。この設定が wp-config.php に無い場合は、 false とみなされます。

define('WP_ALLOW_MULTISITE', true);

存在しないブログをリダイレクトする

NOBLOGREDIRECT を使用して、存在しないブログ、例えば http://nonexistent.example.comhttp://example.com/nonexistent/ にアクセスした訪問者をリダイレクトすることができます。

define('NOBLOGREDIRECT', 'http://example.com');

デバッグ

バージョン 2.3.1 で追加された WP_DEBUG オプションを有効化すると、一部のエラーや警告のレポートを制御し WP_DEBUG_DISPLAYWP_DEBUG_LOG の設定が使えるようになります。デフォルト値は false になっています。

注: 以下の例では true/false の値はアポストロフィ(')なしで書かれています。これは、この値が論理値だからです。

define('WP_DEBUG', true);
define('WP_DEBUG', false);

さらに、WordPress のビルトイン JavaScript/CSS を変更するつもりの場合は、設定ファイルに以下のコードを追加すべきです。

define('SCRIPT_DEBUG', true);

これにより、wp-includes/js および wp-admin/js ディレクトリの scriptname.dev.js ファイル、wp-includes/css および wp-admin/css ディレクトリの filename.dev.css を編集できます。

古いバージョンではデータベースエラーが常に表示されていましたが、バージョン2.3.2以降、WP_DEBUG が true の場合のみ表示されます(データベースエラーは wpdb Class によって処理され、PHP のエラー設定には影響を受けません)。

バージョン2.5以降、WP_DEBUG を true にした場合、エラー出力レベル も E_ALL に上げられ、非推奨関数やファイルを使った時に警告を出力します。false の場合は、WordPress はエラー出力レベルを E_ALL ^ E_NOTICE ^ E_USER_NOTICE に設定します。

JavaScript 連結の無効化

管理画面のスピードアップのため、JavaScript ファイルはすべてひとつの URL に連結されます。管理画面で JavaScript がうまく動作しない場合、この機能を以下のようにして無効化できます。

define('CONCATENATE_SCRIPTS', false);

エラーログ取得の設定

エラーログ取得の設定には少し注意が必要です。まず、デフォルトの PHP エラーログおよび表示設定は php.ini ファイルで定義されています。このファイルにはアクセスできる場合とできない場合があります。アクセスできる場合は、公開する PHP ページ向けの設定を記入しておいてください。公開ページにはエラーメッセージを表示せず、エラーログに保存することを強く推奨します。さらに、エラーログはサーバー内の公的にアクセスできない位置に保存しましょう。php.ini エラー設定のサンプルは以下の通りです。

error_reporting = 4339
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /home/example.com/logs/php_error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
html_errors = Off

About Error Reporting 4339

This is a custom value that only logs issues that affect the functioning of your site, and ignores things like notices that may not even be errors. See Error Constants for the meaning of each binary position for 1000011110011, which is the binary number equal to 4339. The far left 1 means report any E_RECOVERABLE_ERROR. The next 0 means do not report E_STRICT, (which is thrown when sloppy but functional coding is used) and so on. Feel free to determine your own custom error reporting number to use in place of 4339.

Obviously, you will want different settings for your development environment. If your staging copy is on the same server, or you don't have access to php.ini, you will need to override the default settings at run time. It's a matter of personal preference whether you prefer errors to go to a log file, or you prefer to be notified immediately of any error, or perhaps both. Here's an example that reports all errors immediately that you could insert into your wp-config.php file:

@ini_set('log_errors','Off');
@ini_set('display_errors','On');
@ini_set('error_reporting', E_ALL );
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', true);

wp-config.php はキャッシュファイル以外のページ表示の際に必ず読み込まれるため、インストールした PHP の php.ini 設定をするのに向いている場所といえます。php.ini ファイルにアクセス権がなかったり、いくつかの設定をその場で変更したい時などに便利です。

If you turn on error logging, remember to delete the file afterwards, as it will often be in a publicly accessible location, where anyone could gain access to your log.

PHP の error_logging を有効化し、特定のファイルにログを残す例です。WP_DEBUG が true の場合もこのファイルにエラーを保存します。require_once または include 命令より上にこのように付け加えるだけです。

@ini_set('log_errors','On');
@ini_set('display_errors','Off');
@ini_set('error_log','/home/example.com/logs/php_error.log');
/* That's all, stop editing! Happy blogging. */

Another example of logging errors, as suggested by Mike Little on the wp-hackers email list:

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content (if Apache does not have write permission, you may need to create
 * the file first and set the appropriate permissions (i.e. use 666) ) 
 */
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);

A refined version from Mike Little on the Manchester WordPress User Group:

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content only when WP_DEBUG is true. if Apache does not have write permission, 
 * you may need to create the file first and set the appropriate permissions (i.e. use 666).
 */

define('WP_DEBUG', true); // Or false
if (WP_DEBUG) {
  define('WP_DEBUG_LOG', true);
  define('WP_DEBUG_DISPLAY', false);
  @ini_set('display_errors',0);
}

Confusing the issue is that WordPress has 3 constants that look like they could do the same thing. First off, remember that if WP_DEBUG is false, it and the other two WordPress DEBUG constants do not do anything. The PHP directives, whatever they are, will prevail. Second, even if WP_DEBUG is true, the other constants only do something if they too are set to true. If they are set to false, the PHP directives remain unchanged. For example, if your php.ini file has the directive display_errors = On, but you have the statement define('WP_DEBUG_DISPLAY', false); in your wp-config.php file, errors will still be displayed on screen even though you tried to prevent it by setting WP_DEBUG_DISPLAY to false because that is the php configured behavior. This is why it's very important to set the PHP directives to what you need in case any of the related WP constants are set to false. To be safe, explicitly set/define both types. More detailed descriptions of the WP constants is available at Debugging in WordPress.

For your public, production WordPress installation, you might consider placing the following in your wp-config.php file, even though it may be partly redundant:

@ini_set('log_errors','On');
@ini_set('display_errors','Off');
@ini_set('error_reporting', 4339 ); //Only log errors you will want to know about
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

The default debug log file is /wp-content/debug.log. Placing error logs in publicly accessible locations is a security risk. Ideally, your log files should be placed above you site's public root directory. If you can't do this, at the very least, set the log file permissions to 600 and add this entry to the .htaccess file in the root directory of your WP installation:

<Files debug.log>
   Order allow,deny
   Deny from all
</Files>

This prevents anyone from accessing the file via HTTP. You can always view the log file by retrieving it from your server via FTP.


PHP への割り当てメモリ増加

バージョン 2.5から、WP_MEMORY_LIMIT オプションで PHP が消費するメモリの最大値を設定できるようになりました。"Allowed memory size of xxxxxx bytes exhausted" といったメッセージが表示される場合などにおそらく必要な設定です。

この設定は WordPress のみでの PHP メモリを変更するので、他のアプリケーションは影響を受けません。デフォルトでは、WordPress は PHP のメモリを 40MB まで増加する試みを行います(wp-settings.php の冒頭にこのコードがあります)。このため、wp-config.php での設定は 40MB 以上にする必要があります。

WordPress will automatically check if PHP has been allocated less memory than the entered value before utilizing this function. For example, if PHP has been allocated 64MB, there is no need to set this value to 64M as WordPress will automatically use all 64MB if need be.

ホスティングプロバイダが PHP メモリの上限を設定している場合、この設定は無視される場合があります。その場合は上限を上げてもらえるかホストに問い合わせてみてください。多くのホストは 8MB を上限にしています。

PHP メモリーを 64MB に増加:

define('WP_MEMORY_LIMIT', '64M');

PHP メモリーを 96M に増加:

define('WP_MEMORY_LIMIT', '96M');

WP_MAX_MEMORY_LIMIT を定義すると、管理画面での WP_MEMORY_LIMIT の値を増減させることができます。

define('WP_MAX_MEMORY_LIMIT', '256M');

キャッシュ

The WP_CACHE setting, if true, includes the wp-content/advanced-cache.php script, when executing wp-settings.php.

define('WP_CACHE', true);

カスタム User・Usermeta テーブル

CUSTOM_USER_TABLE および CUSTOM_USER_META_TABLE は、通常 WordPress が利用する user および usermeta テーブルを使わない場合に代わりのテーブルを指定するために定義します。

define('CUSTOM_USER_TABLE', $table_prefix.'my_users');
define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');

Please note that permissions in the user_meta tables are stored with the table prefix of the site. So in the CUSTOM_USER_META_TABLE one must have entries for each site using that table.

At the very least for the administrator, to avoid the "you do not have permissions error" you should have:

prefix1_capabilities = a:1:{s:13:"administrator";b:1;} and prefix2_capabilities = a:1:{s:13:"administrator";b:1;} etc

When using CUSTOM_USER_TABLE during initial setup it is easiest to: Setup your first instance of wordpress. The define statements of the wp-config.php on the first instance pointing to where you currently store user data wp_user by default, and then coping that working wp-config.php to your next instance which will only require you to change the $table_prefix = variable as previously stated. At this point the install will run as expected; however, do not use an e-mail address that is already in use by your original install. Use a different e-mail address. Once you have finished the setup process log in with the auto generated admin account and password. Then promote your normal account to the administrator level. Log out of admin. Log in as yourself. Delete the admin account and promote the other user accounts as is needed.

Language and Language Directory

WPLANG defines the name of the language translation (.mo) file. WP_LANG_DIR defines what directory the WPLANG .mo file resides. If WP_LANG_DIR is not defined WordPress looks first to wp-content/languages and then wp-includes/languages for the .mo defined by WPLANG file.

define('WPLANG', 'de_DE');
define('WP_LANG_DIR', dirname(__FILE__) . 'wordpress/languages');

To find out the WPLANG language code, please refer to WordPress in Your Language. The code in parentheses after each language heading is what you need.

解析用クエリの保存

SAVEQUERIES を定義すると、分析用にデータベースクエリを配列に保存し、表示できます。保存されるのは各クエリ、呼び出された関数、クエリ実行にかかった時間の情報です。

注: サイトのパフォーマンスに影響が出ます。デバッグ中以外は無効化しておきましょう。

まず、wp-config.php に以下を追加します。

define('SAVEQUERIES', true);

それからテーマの footer.php に以下を追加します。

<?php
if (current_user_can('administrator')){
    global $wpdb;
    echo "<pre>";
    print_r($wpdb->queries);
    echo "</pre>";
}
?>

デフォルトファイルパーミッションの上書き

FS_CHMOD_DIR および FS_CHMOD_FILE でデフォルトのファイルパーミッションを上書きして再定義できます。この2つの定数は、suEXEC で動作するホスト(一部のイタリアのホストなど)でコアアップグレード機能が失敗する問題に対応すべく開発されました。ユーザファイル全てに限定パーミッション(400 など)を用いるホストで、グループおよびその他のクラスがファイルにアクセスできるようにするパーミッション設定を拒否される場合、この定義で解決できます。値は 0755 のように八進数で記入し、シングルクォート(')で囲んではいけません。ファイルパーミッションの変更を参照のこと。

define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));

setgid を指定する例:

define('FS_CHMOD_DIR', (02755 & ~umask()));

WordPress Upgrade Constants

You should define as few of the below constants needed to correct your update issues.

The most common causes of needing to define these are:

  • Host running with a special installation setup involving Symlinks, You may need to define the path-related constants (FTP_BASE, FTP_CONTENT_DIR, and FTP_PLUGIN_DIR), Often defining simply the base will be enough.
  • Certain PHP installations shiped with a PHP FTP Extension which is incompatible with certain FTP Servers, under these rare situations, you may need to define FS_METHOD to 'ftpsockets'

The following are valid constants for WordPress updates:

  • FS_METHOD forces the filesystem method. It should only be "direct", "ssh2", "ftpext", or "ftpsockets". Generally, You should only change this if you are experiencing update problems, If you change it, and it doesnt help change it back/remove it, Under most circumstances, setting it to 'ftpsockets' will work if the automatically chosen method does not.
    • (Primary Preference) "direct" forces it to use Direct File I/O requests from within PHP, this is fraught with opening up security issues on poorly configured hosts, This is chosen automatically when appropriate.
    • (Secondary Preference) "ssh2" is to force the usage of the SSH PHP Extension if installed
    • (3rd Preference) "ftpext" is to force the usage of the FTP PHP Extension for FTP Access, and finally
    • (4th Preference) "ftpsockets" utilises the PHP Sockets Class for FTP Access.
  • FTP_BASE is the full path to the "base"(ABSPATH) folder of the WordPress installation.
  • FTP_CONTENT_DIR is the full path to the wp-content folder of the WordPress installation.
  • FTP_PLUGIN_DIR is the full path to the plugins folder of the WordPress installation.
  • FTP_PUBKEY is the full path to your SSH public key.
  • FTP_PRIKEY is the full path to your SSH private key.
  • FTP_USER is either user FTP or SSH username. Most likely these are the same, but use the appropriate one for the type of update you wish to do.
  • FTP_PASS is the password for the username entered for FTP_USER. If you are using SSH public key authentication this can be omitted.
  • FTP_HOST is the hostname:port combination for your SSH/FTP server. The default FTP port is 21 and the default SSH port is 22, These do not need to be mentioned.
  • FTP_SSL TRUE for SSL-connection if supported by the underlying transport, Not available on all servers. This is for "Secure FTP" not for SSH SFTP.
define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/path/to/wordpress/');
define('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/');
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'ftp.example.org');
define('FTP_SSL', false);

Some configurations should set FTP_HOST to localhost to avoid 503 problems when trying to update plugins or WP itself.

FTP・SSH 定数

アップグレードオプションとして SSH2 を有効化するには、pecl SSH2 拡張をインストールする必要があります。このライブラリをインストールするには、以下のようなコマンドを発行するか、ホスティングサービスに相談してインストールしてもらいます。installed:

pecl install ssh2

pecl ssh2 拡張をインストールしたら、ライブラリが自動的に読み込まれるよう PHP の設定を修正する必要があります。

pecl is provided by the pear package in most linux distributions. To install pecl in Redhat/Fedora/CentOS:

yum -y install php-pear

Debian/Ubuntu に pecl をインストールするには、以下をを使います。

apt-get install php-pear

これらの WordPress 本体・プラグイン・テーマアップグレード方法では PHP を使って WordPress のパスを判断しようとしますが、シンボリックリンクによっておかしくなってしまうことがあります。FTP ユーザとしてサーバ上にある各フォルダへのパスが分かっていれば、手動でそのパスをwp-config.php ファイルに定義できます。

FTP/SSH 更新に関する定数は以下の通りです。

  • FS_METHOD: ファイルシステムメソッドの指定。"direct"、"ssh"、"ftpext"、"ftpsockets" のいずれか。
  • FTP_BASE: インストールした WordPress のベースフォルダへのフルパス。
  • FTP_CONTENT_DIR: インストールした WordPress の wp-content フォルダへのフルパス。
  • FTP_PLUGIN_DIR: インストールした WordPress の plugins フォルダへのフルパス。
  • FTP_PUBKEY': SSH 公開鍵へのフルパス。
  • FTP_PRIKEY: SSH 秘密鍵へのフルパス。
  • FTP_USER: FTP または SSH のユーザー名。同一の場合がほとんどだが、利用したい更新タイプのユーザーに一致させること。
  • FTP_PASS: FTP_USER で入力したユーザーのパスワード。SSH 公開鍵での認証を使っている場合は省略可能。
  • FTP_HOST: SSH/FTP サーバーのホスト名:ポート番号の組み合わせ。FTP ポートは通常21で、SSH ポートは22。
  • FTP_SSL SLL 接続を使う。.
define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/path/to/wordpress/');
define('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/');
define('FTP_PLUGIN_DIR', '/path/to/wordpress/wp-content/plugins/');
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'ftp.example.org:21');
define('FTP_SSL', false);

秘密鍵はパスフレーズで保護しないことをおすすめします。パスフレーズで保護した秘密鍵はうまく動作しないと言う報告が数々あります。もし使う場合は、FTP_PASS としてパスフレーズを入力する必要があります。

WordPresss やプラグインのアップグレード・インストールでの SSH の使い方がまだよく分からない場合は、このチュートリアル(リンク先は英語)をご覧ください。

代替 Cron

予約済み投稿の公開がうまくいかない場合などに使います。Otto がフォーラムで説明したところによると、「この代替メソッドではリダイレクト手法を使う。Cron が走る前にユーザーのブラウザがリダイレクトされるので、直前に投げた接続で Cron が走り続けている間、サイトにすぐ戻ってくることができる。このメソッドは時々不安定なため、デフォルトにはしていない」とのこと。

define('ALTERNATE_WP_CRON', true);

Cronの無効化と、Cronタイムアウト時間

DISABLE_WP_CRON を true に設定することにより、cron を完全に無効化することができます。

define('DISABLE_WP_CRON',true);

また、cron の処理は WP_CRON_LOCK_TIMEOUT で設定した期間(単位:秒)は連続して実行されないようになっていることに注意してください。

define('WP_CRON_LOCK_TIMEOUT',60);


他の定義定数

さらに定義が可能な定数は以下の通りですが、定義しなくていい場合がほとんどです。Cookie 定数は、独特なドメインの設定をしている場合特に便利でしょう。

define('COOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('home') . '/' ) );
define('SITECOOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('siteurl') . '/' ) );
define('ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' );
define('PLUGINS_COOKIE_PATH', preg_replace('|https?://[^/]+|i', '', WP_PLUGIN_URL )  );
define('TEMPLATEPATH', get_template_directory());
define('STYLESHEETPATH', get_stylesheet_directory());
define('DISABLE_WP_CRON', true);

ゴミ箱を空にする

バージョン 2.9で追加されたこの定数は、WordPress がゴミ箱に入っている投稿、固定ページ、添付ファイル、コメントを永久に削除するまでの日数をコントロールします。デフォルトは30日間です。

define('EMPTY_TRASH_DAYS', 30 ); // 30日

ゴミ箱機能を無効化するには、この数字を0にします。この設定の場合、何かを削除しようとした場合に確認ダイアログが出ず、即座に削除されるのでご注意ください。

define('EMPTY_TRASH_DAYS', 0 ); // 0日

すべての定義済み定数を表示

PHP には現在定義されている定数とその値を配列にして返す関数があります。

print_r(@get_defined_constants());

自動データベース最適化

バージョン 2.9 から自動データベース最適化対応が含まれるようになりました。もし必要な場合のみ、以下の定義を wp-config.php ファイルに記入することで有効化できます。

 define('WP_ALLOW_REPAIR', true);

このスクリプトは、{$your_site}/wp-admin/maint/repair.php にあります。

注: この定義はあくまでも機能を有効化するだけです。定義をすると、ユーザーはログインしなくてもこの機能にアクセスできます。これは、データベースが破損している場合ユーザーがログインできなくても修理を行えるようにです。

Do not upgrade global tables

A DO_NOT_UPGRADE_GLOBAL_TABLES define prevents dbDelta() and the upgrade functions from doing expensive queries against global tables.

Sites that have large global tables (particularly users and usermeta), as well as sites that share user tables with bbPress and other WordPress installs, can prevent the upgrade from changing those tables during upgrade by defining DO_NOT_UPGRADE_GLOBAL_TABLES. Since an ALTER, or an unbounded DELETE or UPDATE, can take a long time to complete, large sites usually want to avoid these being run as part of the upgrade so they can handle it themselves. Further, if installations are sharing user tables between multiple bbPress and WordPress installs it maybe necessary to want one site to be the upgrade master.

define('DO_NOT_UPGRADE_GLOBAL_TABLES', true);

View All Defined Constants

Php has a function that returns an array of all the currently defined constants with their values.

 print_r(@get_defined_constants());

プラグイン/テーマエディタを無効にする

重要なファイルをいじってしまってサイトが動作しなくなる、ということを避けるため、プラグイン/テーマエディタを無効にしたい場合があるでしょう。これらを無効にすると、攻撃者がユーザーアカウントを乗っ取った場合に備えて防御壁を増やします。

define('DISALLOW_FILE_EDIT',true);

注意: current_user_can('edit_plugins') を使用しているプラグインが影響を受けるかもしれません。プラグイン作者はこの権限をチェックすべきではありません。少なくとも、この定数が定義されているか調べ、適切なエラーメッセージを表示するようにすべきです。プラグインが動作しない場合、これが原因の可能性があります。

プラグイン/テーマの更新/インストールを無効にする

プラグイン/テーマの更新/インストールを無効にします。この定数を設定すると、プラグイン/テーマエディタも無効にします。(つまり、DISALLOW_FILE_MODS と DISALLOW_FILE_EDIT の両方を設定する必要はありません。DISALLOW_FILE_MODS を設定すれば同じ効果があります。)

   define('DISALLOW_FILE_MODS',true);

Require SSL for Admin and Logins

FORCE_SSL_LOGIN is for when you want to secure logins so that passwords are not sent in the clear, but you still want to allow non-SSL admin sessions (since SSL can be slow).

   define('FORCE_SSL_LOGIN',true);

FORCE_SSL_ADMIN is for when you want to secure logins and the admin area so that both passwords and cookies are never sent in the clear. This is the most secure option. Administration_Over_SSL

   define('FORCE_SSL_ADMIN',true);

Block External URL Requests

Block external URL requests by defining WP_HTTP_BLOCK_EXTERNAL as true and this will only allow localhost and your blog to make requests. The constant WP_ACCESSIBLE_HOSTS will allow additional hosts to go through for requests. The format of the WP_ACCESSIBLE_HOSTS constant is a comma separated list of hostnames to allow, wildcard domains are supported, eg *.wordpress.org will allow for all subdomains of wordpress.org to be contacted.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );


外部リソース

関連ページ

変更履歴

最新英語版: WordPress Codex » Editing wp-config.php最新版との差分

この項目「wp-config.php の編集」は、翻訳チェック待ちの項目です。加筆、訂正などを通して、Codex ドキュメンテーションにご協力下さい。

脚注

  1. 「Warning: Cannot modify header information - headers already sent by ~」というエラーが出ます。Windows のメモ帳も UTF-8 BOMありで保存されるため使えません。(参考