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

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

wp-config.php の編集

提供: WordPress Codex 日本語版
2016年5月22日 (日) 16:16時点におけるAkira Tachibana (トーク | 投稿記録)による版 (最新英語版を反映、和訳完了 en:Editing_wp-config.php 23:44, 21 May 2016‎ Keesiemeijer版)

移動先: 案内検索

wp-config.php ファイルは WordPress のインストールを行なう上で最も重要なファイルの一つです。このファイルは WordPress のファイルディレクトリのルート直下に置かれ、中には MySQL データベースへの接続情報などサイトの基礎となる詳細な構成情報が含まれます。

wp-config.php ファイルはダウンロード直後の WordPress には含まれません。WordPress をセットアップする過程で入力された情報をもとに wp-config.php ファイルが作られます。

wp-config.php ファイルは手動でも作成できます。インストールディレクトリのルートにあるサンプルファイル「wp-config-sample.php」を編集し、wp-config.php として保存してください。


編集時の注意
  1. 書き換え終わったら、もう一度見直しましょう!
    • 入力した値の前後に余計な空白が入っていませんか?
    • 値を囲む引用符 (') を消していませんか?
    • ファイルの先頭は <?php で始まり、最後の行は require_once(ABSPATH . 'wp-settings.php'); で終わり、その後ろに空行やスペースが入っていませんか? 末尾の ?> も必要ありません。(参照: 変更履歴 2.8)
  2. ファイルの保存時は UTF-8 BOMありで保存しないでください。
    • エラー「Warning: Cannot modify header information - headers already sent by ~」が出力されます。
    • Windows のメモ帳も UTF-8 BOMありで保存するため使用できません。(参照: テキストエディタ)


注意: wp-config-sample.phpファイルは完全に決められた順序で記述されています。順序は重要です。すでに wp-config.php ファイルが存在する場合、ファイルの記述順序を変更すると Web サイトにエラーが発生する場合があります。


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


目次


新規インストール時に wp-config.php を編集するには次の情報が必要です。

データベース名
WordPress が使用するデータベース名
データベースユーザ名
データベースへのアクセスに使用するユーザ名
データベースパスワード
データベースへのアクセスに使用するパスワード
データベースホスト
データベースサーバのホスト名。ポート番号、UNIX ソケットファイルパスまたはパイプが必要になる場合もあります。

ホスティングプロバイダ (レンタルサーバ) 側で WordPress をインストールした場合、必要な情報をプロバイダから取得してください。ウェブサーバやホスティングアカウントを管理し、データベースとユーザを作成した場合はすでに情報が手元にあるはずです。

データベース設定

重要: Microsoft Word のようなワープロソフトは WordPress ファイルの編集には 絶対に使わないでください! Windows のメモ帳 (Notepad) も使えません。(参照: 利用可能なテキストエディタ)

WordPress のルートディレクトリにある wp-config-sample.phpテキストエディタで開きます。

注意: Version 2.6以降は wp-config.php ファイルを WordPress インストールディレクトリの1つ上のディレクトリに移動できます。

デフォルトの wp-config-sample.php

以下はデフォルトの wp-config-sample.php の例です。値もすべて例として挙げられています。Codex 編集者へ。以下を編集して自分のパスワード等を入力しないでください。

// ** 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', '' );

/* */ の内側の文章は説明用のコメントです。

データベース名の設定

元々の database_name_here の部分をデータベース名で置き換えます。以下はデータベース名が「MyDatabaseName」の場合の例です。引用符 (') を消さないように注意してください。

define( 'DB_NAME', 'MyDatabaseName' );

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

元々の username_here の部分をデータベースのユーザ名で置き換えます。以下はデータベースのユーザ名が「MyUserName」の場合の例です。

define( 'DB_USER', 'MyUserName' );

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

元々の password_here の部分をデータベースのパスワードで置き換えます。以下はデータベースのパスワードが「MyPassWord」の場合の例です。

define( 'DB_PASSWORD', 'MyPassWord' );

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

元々の localhost の部分をデータベースのホスト名で置き換えます。以下はデータベースのホスト名が「MyDatabaseHost」の場合の例です。ポート番号や UNIX ソケットファイルパスが必要な場合もあります。

define( 'DB_HOST', 'MyDatabaseHost' );

注意: この部分は変更しなくてもよい可能性があります。分からなければデフォルトの 'localhost' でインストールし、動作するかどうか確認してください。インストールに失敗しているようであれば、Web ホスティングプロバイダ (レンタルサーバ) に問い合わせます。

DB_HOST 値の候補

ホスティング会社によって MySQL データベースのネットワーク設定は異なります。利用中のホスティングサービス名が以下の表にあれば DB_HOST の値はその右側の値、または似た値になります。念のため、ホスティングサービスのテクニカルサポートに連絡するか、オンライン説明書や FAQ のページを検索してください。

日本のホスティングサービス DB_HOST 値
XREA (無料サーバ) localhost
エックスサーバー mysqlnn.xserver.jpnn は数字)
さくら mysqlnn.db.sakura.ne.jpnn は数字)
freeweb (無料サーバ) localhost


海外のホスティング会社 DB_HOST 値
1and1 db12345678
A2 Hosting localhost
AN Hosting localhost
Aruba.it localhost またはアクティベーションメールに記載の IP アドレス
A Small Orange localhost
AT&T xxxxxxxx.carrierzone.com PHP MyAdmin で表示されるフルのサーバ名
BlueHost localhost
DreamHost mysql.example.com
GoDaddy - Shared and 4GH Hosting 「Database」メニューで「MySQL」を選択し、データベース名の右側の「Actions and Details」をクリックする。ウィンドウ末尾にホスト名が表示される。
GoDaddy - cPanel Hosting localhost
GoDaddy - Plesk Hosting Plesk の「Database」セクションに表示される IP アドレスを使用。「:3306」は含めない。
HostGator localhost
ICDSoft localhost:/tmp/mysql5.sock
Infomaniak Network mysql.yourdomain
InMotion Hosting localhost
iPage username.ipagemysql.com
IPower username.ipowermysql.com
Laughing Squid localhost
MediaTemple Grid internal-db.s00000.gridserver.com - ("00000" は実際のサイト番号で置き換え)
MediaTemple DV localhost
MegaHost localhost
NearlyFreeSpeech.Net username.db
NetworkSolutions mysqlv5
one.com example.com.mysql
pair Networks dbnnnx.pair.com
QTH.com localhost
Rackspace Cloud アンマネージドサーバーは localhost、Cloud Sites はmysqlXY-AB.wcN.dfQ.stabletransit.com のように可変。このとき X、Y、A、B、N、Q は変数
SysFix.eu Power Hosting datapower.sysfix.eu
Site5 localhost
Yahoo mysql
cPanel のホスト localhost
Plesk のホスト localhost
DirectAdmin のホスト localhost
Tophost.it sql.your-domain-name.it



MySQL 代替ポート

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

localhost の場合:

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

また場合によっては:

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

指定されたサーバー向け:

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

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

MySQL ソケットまたはパイプ

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

define( 'DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock' );
// または define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );
// または define( 'DB_HOST', 'example.tld:/var/run/mysqld/mysqld.sock' );

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

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

WordPress Version 2.2 から、 DB_CHARSET で MySQL データベーステーブルの定義に使われるデータベースキャラクタセット(文字コードセット。例: タイの TIS620 用 tis620)の指定ができるようになりました。

デフォルト値 utf8Unicode UTF-8)は、ほとんどの場合に適した設定です。UTF-8 はどの言語にも対応するため、通常 DB_CHARSET は utf8 のままにしておき、自分の言語に合う DB_COLLATE を使用してください。

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

define( 'DB_CHARSET', 'utf8' );
新規インストール実行時の注意
ほとんどの場合 DB_CHARSET のデフォルト値を変更する必要はありません。ブログで異なるキャラクタセットが必要な場合は「MySQL でサポートされる文字セットと照合順序」を参照してください。
アップグレード実行時の注意 特に 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 Version 2.2 から、DB_COLLATE で データベース照合順序(キャラクタセットのソート順)の指定ができるようになりました。ほとんどの場合、データベース照合順序は、DB_CHARSET で指定されたデータベースキャラクタセットに基づいて MySQL によって自動的に割り当てられるため、この値は空 (null) のままで良いはずです。DB_COLLATE には、ほとんどの欧米言語では「Unicode 文字セット」で定義された UTF-8 の値の一つを設定します。

WordPress の DB_COLLATE の初期値

define( 'DB_COLLATE', '' );

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

define( 'DB_COLLATE', 'utf8_general_ci' );

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

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


認証用ユニークキー

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

このキーを覚える必要はありません。オンラインジェネレータを使ってできるだけ長く、ランダムで複雑な組み合わせを作成してください。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%%' );

秘密鍵(シークレットキー) はパスワードにランダムな数値を付加することでサイトのハックや、不正アクセスを困難にします。

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


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

WordPress Version 4.0 からは言語を WordPress 管理画面で変更できます。

WordPress バージョン 4 以降

管理画面で言語を変更します。「設定」 > 「一般設定」にアクセスし、「サイトの言語」で選択してください。

WordPress バージョン 3.9.x 以前

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

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

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

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

WPLANG にセットできる他の言語コードを調べるには polyglots teams を参照してください。「WP Locale」列のコードが必要な値です。

WPLANGWordPress 4.0 で非推奨となりました。

高度なオプション

以下のセクションには高度な情報、サポートのない情報が含まれています。定期バックアップを確実に実行し、設定を試す前に復元方法を確認してください。

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

$table_prefix は、データベーステーブル名の先頭に付けられる値です。wp_ 以外のデータベース接頭辞を使用する場合にはこの値を変更してください。主に、同じデータベースで複数ブログのインストールを行う場合に変更します。

値には半角英数字とアンダースコア(_)のみ指定できます。

$table_prefix = 'wp_';

同じデータベースに2つめのブログをインストールするには、1つめと異なる接頭辞を指定します。

$table_prefix = 'y77_';

WordPress アドレス (URL)

WP_SITEURL は WordPress のアドレス (URL) を定義します。WordPress Version 2.2 で追加されました。ここで定義する値は WordPress のコアファイルが存在する URL です。http:// の部分は含め、末尾のスラッシュ "/" は含めないでください。wp-config.php でこの値を設定すると、wp_options テーブルoption_value siteurl の値よりも優先されます。

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

例えば、ドメイン名「example.com」のディレクトリ「wordpress」に WordPress をインストールした場合 WP_SITEURL は次のように定義します。

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

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

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

注意: HTTP_HOST はリクエストの HTTP HOST ヘッダ値から PHP によって動的に作成されているためファイル混入脆弱性の可能性があります。SERVER_NAME もまた動的に作成されますが、Apache を UseCanonicalName on として構成すると SERVER_NAME は動的でなく、サーバー構成によって設定されます。この場合 HTTP_HOST よりも SERVER_NAME を使用する方が安全です。 $_SERVER['SERVER_NAME'] を基に WP_SITEURL を動的に定義するには: define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress' );

ブログアドレス (URL)

WP_HOMEVersion 2.2 で追加された wp-config.php オプションです。WP_SITEURL と同じく、WP_HOME も wp_options テーブルhome の値よりも優先されますが、恒久的には変更しません。home はブログにアクセスするユーザーがブラウザに入力するアドレスです。http:// の部分は指定する必要があります、末尾のスラッシュ "/" は必要ありません。

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

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

define( 'WP_HOME', 'http://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' );

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

テーマディレクトリは wp-content ディレクトリの外に移動できません。これは WordPress 本体で以下のように定義されているためです。

$theme_root = WP_CONTENT_DIR . '/themes';

ただし register_theme_directory 関数を使用して追加のテーマディレクトリを登録できます。

wp-content ディレクトリの移動を参照してください。どのようにテーマディレクトリが決定されるかについての詳細は wp-includes/theme.php を参照してください。

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

UPLOADS フォルダーを media に設定します。

define( 'UPLOADS', 'wp-content/media' );

このパスは絶対パスではありません。ABSPATH からの相対パスです。従って先頭のスラッシュ (/) は必要ありません。define は次の行の直前に追加します。

 /** Sets up WordPress vars and included files. */
 require_once(ABSPATH . 'wp-settings.php');

自動保存間隔の変更

投稿を編集する際、WordPress は Ajax を使用して編集中の投稿の改訂履歴 (リビジョン) を自動保存します。自動保存の間隔を延ばすにはこの値を増やし、編集を確実に保存するにはこの値を減らします。初期値は 60秒です。

define( 'AUTOSAVE_INTERVAL', 160 ); // 秒数

投稿の改訂履歴

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

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

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

define( 'WP_POST_REVISIONS', false );

注意: 一部のユーザーでは、config.php の最初のブロックコメントの真下にコマンドを移動するまでこの機能が動作しませんでした。

改訂履歴の最大数の指定

改訂の保存版数の最大値を指定するには false35 などの数値に変更します。

define( 'WP_POST_REVISIONS', 3 );

注意: 一部のユーザーでは、config.php の最初のブロックコメントの真下にコマンドを移動するまでこの機能が動作しませんでした。

複雑なドメイン設定に対して WordPress cookie にドメインセットを指定できます。例えば静的コンテンツの提供にサブドメインを使用する場合などです。サブドメイン内の静的コンテンツへのリクエストのたびに WordPress Cookie が送信されるのを防ぐには非静的ドメインのみに cookie ドメインを指定します。

define( 'COOKIE_DOMAIN', 'www.askapache.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' );

デバッグ

Version 2.3.1 で追加された WP_DEBUG オプションを有効化すると、一部のエラーや警告のレポートを制御し WP_DEBUG_DISPLAYWP_DEBUG_LOG の設定を有効化します。デフォルト値は false です。

<p class="information">注意: 次の例で true および false に引用符 (') はありません。これは値がブール値のためです。

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

さらに、WordPress のビルトイン JavaScript や CSS を変更する場合、wp-config.php ファイルに以下のコードを追加してください。

define( 'SCRIPT_DEBUG', true );

これにより圧縮版の .min.css.min.js の代わりに、wp-includes/jswp-includes/csswp-admin/jswp-admin/css ディレクトリ下の非圧縮版 JavaScript ファイルおよび 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

Error Reporting 4339について

このカスタム値はサイトの動作に影響する問題のみをログに記録し、エラーではない通知等の事象は無視します。4339を2進数で表すと 1000011110011 です。各ビットの意味は 定義済み定数 を参照してください。例えば、左端の 1 は E_RECOVERABLE_ERROR をすべて記録します。その隣の 0 は E_STRICT を記録しません(動作はするものの不注意なコードが使用されると投げられます)。目的にあったカスタムエラー報告番号を作成し、4339 の代わりに設定してください。

恐らく開発環境には異なる設定が必要でしょう。開発用のコピーが同じサーバーにあるか、または php.ini にアクセスできない場合、デフォルトの実行時設定を上書きする必要があります。エラーをログファイルに記録するか、エラーをすぐに表示するか、その両方を行うかは、好みによります。次の例は、すべてのエラーをすぐに表示します。wp-config.php に追加してください。

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

wp-config.php は、どのページを表示する際にもキャッシュファイルからでなくディスクから読み込まれるため、インストールされた PHP を制御する php.ini の設定を変更する場所として最適です。php.ini ファイルにアクセスできない場合や、一時的に設定を変えたい場合に便利です。例外は 'error_reporting' です。WP_DEBUGtrue に設定すると、wp-config.php で何が指定されていても WordPress は 'error_reporting' に E_ALL を設定します。'error_reporting' を他の値に変更する場合は wp-settings.php が読み込まれた後、例えばプラグインファイルの中で設定します。

エラーロギングを有効にする場合、後で忘れずにログファイルを削除してください。一般に外部からアクセス可能な場所にログファイルが置かれることが多く、誰もがログにアクセスできます。

次の例は PHP の error_logging を有効化し、指定したファイルにログを出力します。WP_DEBUG が true の場合、そのデバッグメッセージもこのファイルに保存されます。wp-config.php ファイル内で任意の 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. */

二つ目のエラーロギングの例です。Mike Little が wp-hackers メーリングリスト で提案したものです:

/**
 * すべてのエラー、通知、警告をファイル「wp-content/debug.log」に出力します。
 * Apache に書き込み権限がない場合、先にファイルを作成し、666 等の適切な
 * パーミッションを設定してください。
 */

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);

その改良バージョン。Mike Little が マンチェスター WordPress ユーザーグループ で提案しました。

/**
 * WP_DEBUG が true である場合に限り、すべてのエラー、通知、警告をファイル
 * 「wp-content/debug.log」に出力します。
 * Apache に書き込み権限がない場合、先にファイルを作成し、666 等の適切な
 * パーミッションを設定してください。
 */

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

WordPress には似たような動作が期待される 3 つの定数「WP_DEBUG」「WP_DEBUG_LOG」「WP_DEBUG_DISPLAY」があるため混乱しますが、以下の点に注意してください。

  • まず WP_DEBUG が false の場合、WP_DEBUG を含む 3 つの DEBUG 定数は何の動作もしません。すべての PHP ディレクティブ ( 設定オプション ) の設定は有効です。例外は 'error_reporting' で、WP_DEBUG が false の場合、WordPress は 'error_reporting' に 4983 を設定します。
  • 2番目に、WP_DEBUGtrue に設定されても、WP_DEBUG_LOGWP_DEBUG_DISPLAY は true に設定された場合のみ動作します。false が設定されている場合、PHP ディレクティブの動作は変化しません。例えば php.ini ファイルに display_errors = On ディレクティブがあると、wp-config.php ファイルに文 define( 'WP_DEBUG_DISPLAY', false ); を指定して抑止したつもりでも、エラーが画面に表示されます。これは php.ini ファイルの設定が有効のためです。

このことから WP 定数を false に設定する場合、関連する PHP ディレクティブの適切な設定はとても重要です。安全のため明示的に両方とも設定または定義してください。WP 定数の詳細については「WordPressでのデバッグ」を参照してください。

本番用に公開する WordPress インストールでは、多少冗長な部分はありますが wp-config.php ファイルに以下を含めることを検討してください。

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

デフォルトのデバッグ用ログファイルは /wp-content/debug.log です。外部からアクセス可能な場所にエラーログを置くことはセキュリティリスクです。理想的にはサイトの公開用ルートディレクトリより上位の場所にログファイルを置くべきです。それができない場合は最低限、ログファイルのパーミッションを 600 に設定し、WordPress インストールのルートディレクトリの .htaccess ファイルに次のエントリーを追加してください。

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

これで HTTP 経由では誰もファイルにアクセスできません。一方、管理者はいつでも FTP を使用してサーバーからログファイルを取得し、参照できます。

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

Version 2.5から、WP_MEMORY_LIMIT オプションを使用して PHP が消費するメモリの最大値を設定できます。メッセージ「Allowed memory size of xxxxxx bytes exhausted」などが表示される場合に必要となる設定です。

この設定は WordPress 用の PHP メモリのみを増やし、他のアプリケーション用メモリは変更しません。デフォルトでは、WordPress は PHP のメモリを 40MB、マルチサイトでは64MB まで増やそうとします (/wp-includes/default-constants.php の冒頭にこのコードがあります)。このため wp-config.php での設定は 40MB 以上、もしくは64MB以上にする必要があります。

WordPress はこの関数を利用する前に、PHP が入力値よりも少ないメモリーを割り当てたかどうか確認します。たとえば PHP が 64MB を割り当てる場合、この値に 64MB を設定する必要はありません。必要であれば WordPress が自動的に 64MB すべてを使用するためです。

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

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

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

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

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

管理者タスクは一般の操作よりも多くのメモリを必要とします。WP_MAX_MEMORY_LIMIT を定義すると、管理画面での WP_MEMORY_LIMIT の値を増減できます。

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

注意: これは wp-settings.php インクルードの前に記述する必要があります。

キャッシュ

WP_CACHE に true を設定すると wp-settings.php 実行の際に wp-content/advanced-cache.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' );

'CUSTOM_USER_META_TABLE' を指定しても、各データベースには各インスタンスに対応する権限を使用した usermeta テーブルが作成されます。デフォルトで WordPress インストーラは最初のユーザー (ID #1) に権限を追加します。管理者はプラグインやカスタム関数を使用してサイトの権限を管理する必要があります。管理を怠ると、権限のエラーやログイン問題が発生します。

最初のセットアップ時に CUSTOM_USER_TABLE を使用するには、次の方法がもっとも簡単です。

  1. WordPress の最初のインスタンスをセットアップします。このインスタンスの wp-config.php 内の define 文では、現在ユーザーデータを格納するテーブル、デフォルトでは wp_users テーブルを指定します。
  2. この wp-config.php を2番目のインストール開始前のインスタンスへコピーします。このとき $table_prefix 変数の値を変更します。
  3. この時点で2番目のインスタンスに正常にインストールできます。ただし最初のインスタンスで使用されたメールアドレスは使用しないでください。別のメールアドレスを使用してください。
  4. セットアップを終えたら、自動生成された admin アカウントとパスワードでログインします。
  5. 管理に使用する個人アカウントに管理者権限を付与します。
  6. admin をログアウトします。
  7. 管理者権限を付与した個人アカウントでログインします。
  8. 自動生成された admin アカウントを削除し、必要に応じて他のユーザーアカウントに権限を付与します。


解析用クエリの保存

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 define 文はデフォルトのファイルパーミッションを上書きします。この2つの定数は、suEXEC で動作するホストでコアアップグレード機能が失敗する問題対応のために開発されました。すべのてユーザファイルに限定パーミッション(400 など)を使用するホストで、「グループ」または「その他」のパーミッションによるファイルアクセスが拒否される場合、この定義で問題を解決できます。注意: '0755' は8進数です。8進数は0で始まり、引用符 (') で囲みません。「ファイルパーミッションの変更」も参照してください。

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

setgid を指定する例:

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

WordPress 定数のアップグレード

問題解決に必要な最低限の定数のみを定義してください

定数の定義が必要なもっとも一般的なケースを挙げます。

  • シンボリックリンクを含む特殊なインストール設定で稼働しているホスト。パス関連の定数 FTP_BASE、FTP_CONTENT_DIR、FTP_PLUGIN_DIR の定義が必要な場合があります。多くの場合 FTP_BASE を設定すれば十分です。
  • 既存の FTP サーバーと非互換の PHP FTP 拡張モジュールがバンドルされた PHP インストール環境。このレアなケースでは FS_METHOD に 'ftpsockets' を定義する必要があります。

以下は WordPressのアップデートに有効な定数です。

  • FS_METHOD ファイルシステム方式の強制。有効な値は「direct」「ssh2」「ftpext」「ftpsockets」です。一般にアップデートで問題が発生する場合にのみ変更してください。変更してもうまく動作しない場合は元に戻すか削除してください。自動的に選択されたファイルシステム方式が動作しない場合、ほとんどの環境では「ftpsockets」に設定すると解決します。注意: ここでの選択はセキュリティ上重大な影響を与えます。よく分からない場合はまず管理者に問い合わせてください。
    • (最優先) "direct" PHP からダイレクトファイル I/O リクエストの使用を強制します。デフォルトではこのオプションが選択されます。
    • (2番目の優先度) "ssh2" インストールされていれば SSH PHP 拡張モジュールの使用を強制します。
    • (3番目の優先度) "ftpext" FTP アクセス用 FTP PHP 拡張モジュールの使用を強制します。
    • (4番目の優先度) "ftpsockets" FTPアクセス用 PHP ソケットクラスを使用します。
  • FTP_BASE WordPress インストールのベースフォルダ (ABSPATH) へのフルパス。
  • 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 ネットワークトランスポートが SSL 接続をサポートする場合、true。すべてのサーバーで利用可能ではありません。「Secure FTP」用であり 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 );

構成によってはプラグインや WordPress 本体を更新する際に 503 エラーの回避のため、FTP_HOST に localhost を設定する必要があります。

SSHアップグレードアクセスの有効化

SSH2 を使用した更新には2つの方法があります。

1番目は SSH SFTP アップデートサポートプラグイン を使用する方法、2番目は組み込みの SSH2 更新プログラムを使用する方法。後者は pecl SSH2 拡張モジュールのインストールが必要です。

pecl SSH2 拡張モジュールをインストールするには、次のようなコマンドを実行するか、ホスティング会社にインストールを相談してください。

pecl install ssh2

pecl ssh2 拡張モジュールのインストール後は、PHP の設定を変更し、自動的にこの拡張モジュールを読み込みます。

pecl はほとんどの linux ディストリビューションの pear パッケージで提供されます。Redhat/Fedora/CentOS で pecl をインストールするには、以下のコマンドを実行します。

yum -y install php-pear

Debian/Ubuntu で pecl をインストールするには、以下のコマンドを実行します。

apt-get install php-pear

秘密鍵は、パスフレーズの保護なしでの使用が推奨されます。パスフレーズで保護された秘密鍵が正常に動作しないと数多く報告されています。それでもパスフレーズで保護された秘密鍵を使用する場合、FTP_PASS として秘密鍵のパスフレーズを入力するか、アップデートをインスールする際に表示される認証フィールドの「パスワード」フィールドにパスフレーズを入力する必要があります。

代替 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);

ゴミ箱を空にする

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

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

ゴミ箱機能を無効化するには、この数字を0にします。注意: 「完全に削除する」をクリックしても WordPress は確認ダイアログを表示しません。

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

自動データベース最適化

Version 2.9 から自動データベース最適化がサポートされました。機能が必要な場合のみ、wp-config.php ファイルに次の定義を追加して有効化できます。

 define('WP_ALLOW_REPAIR', true);

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

注意: この定義だけで機能は有効化されます定義を設定すれば、ユーザーがログインして機能にアクセスする必要はありません。この定数の目的は壊れたデータベースの修復を主眼としているためです。多くの場合、データベースが壊れるとユーザーはログインさえできません。

グローバルテーブルをアップグレードしない

DO_NOT_UPGRADE_GLOBAL_TABLES 定義は dbDelta() およびアップグレード機能のグローバルテーブルに対する高価なクエリの実行を止めます。

大きなグローバルテーブル、特に大きな users や usermeta テーブルを持つサイトや、bbPress や他の WordPress インストールとユーザーテーブルを共有するサイトでは、DO_NOT_UPGRADE_GLOBAL_TABLES を定義することで、アップグレードの際のこれらのテーブルの変更を防止できます。ALTER やバインドされていない DELETE や UPDATE は完了までに相当の時間が必要です。大きなサイトでは通常、アップグレードの一部でこのような操作は実行せず、個別に処理します。さらにインストールが複数の bbPress や WordPress とユーザーテーブルを共有している場合、1つのサイトだけがマスターテーブルをアップグレードする必要があります。

define('DO_NOT_UPGRADE_GLOBAL_TABLES', true);

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

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

print_r(@get_defined_constants());

プラグインエディタ、テーマエディタの無効化

熱心なユーザーが重要なファイルを編集し、最悪サイトをクラッシュさせるのを防ぐため、プラグインエディタやテーマエディタを無効化できます。これらエディタの無効化は、ハッカーが権限の高いユーザーアカウントを乗っ取った場合に備える、追加のセキュリティレイヤにもなります。

define('DISALLOW_FILE_EDIT',true);

注意: プラグインのコード内部で current_user_can('edit_plugins') を使用する場合、DISALLOW_FILE_EDIT の影響を受ける場合があります。プラグイン作成者はエディタ機能の確認を避けるか、少なくともこの定数の設定の有無を確認し、適切なエラーメッセージを表示してください。プラグインが動作しない場合、この定数が原因の場合があります。


プラグインやテーマの更新とインストールの無効化

この定数は WordPress 管理画面でのプラグインやテーマのインストールおよび更新機能の使用を無効化します。この定数の設定はプラグインエディタやテーマエディタも無効化します(したがって DISALLOW_FILE_MODS と DISALLOW_FILE_EDIT の両方を設定する必要はありません。DISALLOW_FILE_MODS を設定すれば同じ効果があります)。

define('DISALLOW_FILE_MODS',true);

管理画面とログイン画面にSSLを要求する

注意: FORCE_SSL_LOGIN は WordPress Version 4.0 で廃止されました。FORCE_SSL_ADMIN を使用してください。

FORCE_SSL_ADMIN はログイン画面および管理画面のアクセスを保護します。平文でなく、暗号化されたパスワードとクッキーが送信されます。詳細については「管理画面での SSL 通信」を使用してください。

define('FORCE_SSL_ADMIN',true);

外部URLリクエストのブロック

WP_HTTP_BLOCK_EXTERNA に true を定義すると外部 URL リクエストをブロックし、localhost とブログのサイトだけがリクエストできます。リクエストを許可するホストを追加するには定数 WP_ACCESSIBLE_HOSTS を使用します。WP_ACCESSIBLE_HOSTS 定数には、許可するホスト名をコンマ区切りリストの形式で指定します。ドメイン名のワイルドカードがサポートされます。例えば *.wordpress.org は wordpress.org のすべてのサブドメインからのリクエストを許可します。

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

WordPressの自動更新の無効化

 # すべての自動更新を無効化:
 define( 'AUTOMATIC_UPDATER_DISABLED', true );

WordPress Core 更新の無効化

コアの更新を操作する最も簡単な方法は、WP_AUTO_UPDATE_CORE 定数です。

 # すべてのコア更新を無効化:
 define( 'WP_AUTO_UPDATE_CORE', false );

 # マイナーリリース、メジャーリリースを含むすべてのコア更新を有効化:
 define( 'WP_AUTO_UPDATE_CORE', true );

 # マイナーリリースのコア更新を有効化 (デフォルト):
 define( 'WP_AUTO_UPDATE_CORE', 'minor' );

参照: WordPress 3.7 における自動更新の無効化(英文)

デフォルトでは WordPress は画像の編集のたびに一組の新しい画像を作成し、オリジナルの画像に戻してもすべての編集途中の画像がサーバー上に残されます。IMAGE_EDIT_OVERWRITE に true を定義するとこの動作が変わります。一組の画像だけが作成され、オリジナルの画像に戻すと、編集途中の画像はサーバーから削除されます。

 define( 'IMAGE_EDIT_OVERWRITE', true );

保存の前の再確認

入力した値の前後に空白文字がないこと、引用符を削除しないことを確認してください。

ファイルを保存するには、ファイル > 名前を付けて保存 > wp-config.php を選択し、WordPress インストールのルートにファイルを保存してください。Web サーバーにファイルをアップロードすれば、WordPress インストールの準備完了です!

外部リソース

関連ページ

変更履歴

  • 4.0 :
    • 言語が管理画面の「一般設定」画面で変更できるようになり、WPLANG が非推奨となりました。
  • 3.0 :
    • WP_ALLOW_MULTISITE が定義されている場合、マルチサイト / ネットワークが有効です。
  • 2.9 :
  • 2.8 : wp-config-sample.php ファイルの末尾から「?>」を取り除きました。ファイル編集に伴なうトラブルを予防するものであって、機能に変更ありません。
  • 2.7.1 : セキュリティキー生成サイトの URL が変わりました。
  • 2.7 :
  • 2.6 :
    • SECRET_KEY に替わり、AUTH_KEY および SECURE_AUTH_KEYLOGGED_IN_KEY という 3つのセキュリティキーを設定することになりました。
    • セキュリティキー生成サイトの URL が変わりました。
    • wp-content ディレクトリの場所を変更できるようになりました。
    • wp-config.php ファイルの設置場所を変更できるようになりました。
    • WP_LANG_DIR が導入され、LANGDIR が非推奨となりました。
  • 2.5.1 : SECRET KEY 生成サイトの URL が変わりました。
  • 2.5 : SECRET_KEY, WP_MEMORY_LIMIT が設定可能になりました。
  • 2.3.1 : WP_DEBUG が設定可能になりました。
  • 2.2 : DB_CHARSET, DB_COLLATE, WP_SITEURL, WP_HOME が設定可能になりました。


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