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

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

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

提供: WordPress Codex 日本語版
移動先: 案内検索
(WordPress アドレス (URL): 同様です。 => 同様の危険があります。)
(WordPress アドレス (URL): 「SERVER_NAME は」を追加)
420行目: 420行目:
 
  define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress');
 
  define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress');
  
注: HTTP_HOST は リクエストヘッダ内の値から PHP によって動的に生成されているため、ファイル混入脆弱性の可能性があります。SERVER_NAME も同様の危険があります。ただし、Apache の設定で UseCanonicalName を on にした場合は、サーバー設定によって決定する静的な値が返ります。
+
注: HTTP_HOST は リクエストヘッダ内の値から PHP によって動的に生成されているため、ファイル混入脆弱性の可能性があります。SERVER_NAME も同様の危険があります。ただし、Apache の設定で UseCanonicalName を on にした場合は、SERVER_NAME はサーバー設定によって決定する静的な値です。
  
 
$_SERVER['SERVER_NAME'] を基に WP_SITEURL を動的に定義するには:
 
$_SERVER['SERVER_NAME'] を基に WP_SITEURL を動的に定義するには:

2015年11月13日 (金) 11:49時点における版


wp-config.php ファイルは、WordPressのインストールを行なう上で最も重要なファイルの一つです。このファイルは、WordPressのファイルディレクトリのルート直下に置かれるもので、その中にはWordPressサイトの基礎となる環境設定の詳細、例えばMySQLデータベースへの接続情報といったものを含んでいます。

WordPressをダウンロードしたばかりの時には、wp-config.phpファイルは含まれていません。WordPressをセットアップする過程で、作業者が入力した情報をもとに、 wp-config.phpファイルが作られます。

wp-config.phpファイルは、インストールディレクトリのルートにある"wp-config-sample.php"というサンプルファイルを使って、手打ちでも作成できます。"wp-config-sample.php"を必要とされる通りに編集して、wp-config.phpとして保存します。

注意:wp-config-sample.phpファイルは極めて特有の順序で記述されています。順序が重要です。ファイル内での記述順序を変更するとエラーが発生する場合もあるため、注意してください。

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

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

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

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


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



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

目次

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

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 値
1and1 db12345678
A2 Hosting localhost
AN Hosting localhost
Aruba.it localhost or real IP provided with activation mail.
A Small Orange localhost
AT&T xxxxxxxx.carrierzone.com full server name found in PHP MyAdmin.
BlueHost localhost
DreamHost mysql.example.com
GoDaddy - Shared and 4GH Hosting In the Databases menu go to MySQL. To the right of the database name click on Actions and Details. The hostname is at the bottom of the window.
GoDaddy - cPanel Hosting localhost
GoDaddy - Plesk Hosting Use the IP address shown in the Databases Section in Plesk. Do not include :3306
HostGator localhost
HostICan localhost
ICDSoft localhost:/tmp/mysql5.sock
Infomaniak Network mysql.yourdomain
InMotion Hosting localhost
iPage username.ipagemysql.com
IPower username.ipowermysql.com
LaughingSquid localhost
MediaTemple Grid internal-db.s00000.gridserver.com - (Replace "00000" with the actual site number)
MediaTemple DV localhost
MegnaHost localhost
NearlyFreeSpeech.Net username.db
NetworkSolutions mysqlv5
one.com example.com.mysql
pair Networks dbnnnx.pair.com
QTH.com localhost
Rackspace Cloud localhost for unmanaged servers, variable for Cloud Sites like mysqlXY-AB.wcN.dfQ.stabletransit.com where X,Y,A,B,N,Q are variables
SysFix.eu Power Hosting datapower.sysfix.eu Site5 localhost
Yahoo mysql
Hosts with cPanel localhost
Hosts with Plesk localhost
Hosts with DirectAdmin localhost
Tophost.it sql.your-domain-name.it



MySQL 代替ポート

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

localhost の場合:

define( 'DB_HOST', 'localhost: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' );
// or define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );
// or define( 'DB_HOST', 'example.tld:/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」のようにランダムで推測できないパスワードであれば、正しい組み合わせを見つけ出すまでには何年もかかるでしょう。

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

↑ 編集手順に戻る

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

WordPress 4.0 から、言語を WordPress 管理画面で変更できるようになりました。

WordPress バージョン 4 以降

管理画面で言語を変更します。メニューの 設定 » 一般 » サイトの言語 です。

WordPress バージョン 3.9.x 以前

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');

WPLANG にセットできる他の言語コードを調べるには、WordPress in Your Language (revision 141781) を参照してください。各言語の見出しにある括弧内のコードがそれです。

↑ 編集手順に戻る

上級オプション

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

$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');

注: HTTP_HOST は リクエストヘッダ内の値から PHP によって動的に生成されているため、ファイル混入脆弱性の可能性があります。SERVER_NAME も同様の危険があります。ただし、Apache の設定で UseCanonicalName を on にした場合は、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' );

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

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

$theme_root = WP_CONTENT_DIR . '/themes';

ただし、 register_theme_directory/en 関数を使用することで、テーマディレクトリを追加することは可能です。

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

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

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

Error Reporting 4339について

このカスタム値は、サイトの動作に影響する事象をログに記録する一方で、エラーではない通知のような事象を無視する設定です。4339を二進数で表すと 1000011110011 であり、各ビットの意味は 定義済み定数 を参照してください。例えば、左端の 1 は E_RECOVERABLE_ERROR をすべて記録します。その隣の 0 は E_STRICT を記録しません(動作するけれどいい加減なコードが使われていると発生します)。こんな感じで、自分の目的にあったカスタム値を error_reporting に設定して構いません。

きっと、開発環境では(公開用と)異なる設定が欲しくなるでしょう。開発用のコピーが同じサーバーにあるか、または 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 にすると、'error_reporting' は(wp-config.php で何がセットされていようと)WordPress によって E_ALL がセットされます。'error_reporting' を他の値にする必要があるなら、wp-settings.php が読み込まれた後、例えばプラグインファイルの中で実施しなければなりません。

一度エラーロギングを有効にしたら、ログファイルを後で削除するのを忘れないように。公にアクセスできる場所にファイルがあることが多いので、誰でもあなたのログにアクセスできてしまうかもしれません。

次の例は PHP の error_logging を有効化し、特定のファイルにログを残します。WP_DEBUG が true の場合、そのデバッグメッセージもこのファイルに記録されます。これを、どの require_onceinclude 命令よりも上に書き込みます。

@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 メーリングリスト で提案してくれました:

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

同じく Mike Little による、マンチェスター WordPress ユーザーグループ での洗練されたバージョン:

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

わかりにくい点は、同じことをするように見える 3 つの定数が WordPress にあることです。

  • 最初に、WP_DEBUG が false なら、それと他 2 つの DEBUG 定数は何の働きもしないことを覚えておきましょう。その場合 PHP ディレクティブ(設定オプション)は何であれ普通に働きます。'error_reporting' だけは違って、WP_DEBUG が false なら 4983 がセットされます。
  • 第二に、WP_DEBUGtrue であっても、他 2 つは true にセットされた場合のみ働きます。false なら、PHP ディレクティブの働きは変わりません。例えば php.ini ファイルに display_errors = On というディレクティブがある一方で、wp-config.php ファイルに define( 'WP_DEBUG_DISPLAY', false ); という文があると、WP_DEBUG_DISPLAYfalse でありながらエラーは画面に表示されます。これは PHP がそのように作られているためです。

以上が、関連する WP 定数を false にした場合に PHP ディレクティブを自分の希望どおりにセットすることが重要な理由です。安全を確保するには、両方のタイプを明確にセット/定義しましょう(デフォルトに頼らないように)。WordPress の定数の詳しい説明は Debugging in WordPress/en にあります。

あなたが本番用に公開する 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 への割り当てメモリ増加

バージョン 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が64MBに割り当てられてるなら wordpressは必要なら自動的に全てを64MBにするので この値を64MB割り当てる必要はありません。

ホスティングプロバイダが 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');

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

キャッシュ

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' );

user_meta テーブル内の権限情報は、サイトのテーブル prefix を付けて格納されていることに注意してください。従って、CUSTOM_USER_META_TABLE の中に、このテーブルを使用するサイトそれぞれ用のエントリーが存在しなければなりません。 少なくとも管理者について「あなたには権限がありません」エラーを回避するために、次のエントリーを用意すべきです:

prefix1_capabilities = a:1:{s:13:"administrator";b:1;}
と
prefix2_capabilities = a:1:{s:13:"administrator";b:1;}
など

CUSTOM_USER_TABLE を使用するには初期セットアップ時にそうするのが一番簡単です。

  1. WordPress の最初のインスタンスをセットアップします。このインスタンスの wp-config.php 内の define 文は、デフォルトで wp_user テーブルへユーザー情報を格納するよう指定します。
  2. その wp-config.php を二番目のインスタンス(インストール作業の開始前)へコピーします。ここで必要な作業は、先ほど説明したように $table_prefix 変数の値を変更することだけです。
  3. 二番目のインスタンスのインストールを普通に進めます。ただし、最初のインスタンスで使ったメールアドレスを使ってはいけません。別のメールアドレスを使ってください。
  4. セットアップ作業を終えたら、自動生成された admin アカウントとパスワードでログインします。
  5. そして自分用に一般アカウントを作成し、それを管理者権限に変更します。
  6. admin をログアウトします。
  7. 自分のアカウント(先ほど管理者権限に変更したもの)でログインします。
  8. 自動生成された admin アカウント(先ほどログアウトしたもの)を削除し、必要に応じて他のユーザーアカウントを作成します。

Language and Language Directory

WordPress 4.0 allows you to change the language in your WordPress admin area.

WordPress v4 and above

Change the language in the admin settings screen. Settings > General > Site Language.

WordPress v3.9.6 and below

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.


↑ 言語および言語ディレクトリ へ移動

解析用クエリの保存

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 定数のアップグレード

以下のいくつかの定数を定義すべきです 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'

以下、WordPressのアップデートのための有効な定数:

  • 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" はFTPアクセス用のPHPソケットクラスを利用します。
  • FTP_BASE WordPress インストールの "base"(ABSPATH) フォルダへのフルパス。
  • FTP_CONTENT_DIR WordPress インストールのwp-content フォルダへのフルパス。
  • FTP_PLUGIN_DIR WordPress インストールの plugins フォルダへのフルパス。
  • FTP_PUBKEY SSH 公開鍵のフルパス。
  • FTP_PRIKEY SSH 秘密鍵のフルパス。
  • FTP_USER FTPもしくはSSHのユーザー名のいずれか。 Most likely these are the same, but use the appropriate one for the type of update you wish to do.
  • FTP_PASS 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);

WP自身か、プラグインを更新する時構成は503問題を避けるためにlocalhostに FTP_HOSTをセットします。

FTP・SSH 定数

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

pecl install ssh2

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

peclはほとんどlinuxの配布によりpear packageにより供給されています。 Redhat/Fedora/CentOSの中にpeclをインストールするためのコマンドは以下のようになります。:

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"、"ssh2"、"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 としてパスフレーズを入力する必要があります。

代替 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の定義はdbDelta()関数とアップグレード機能が グローバルテーブルに対する高価なクエリーの実行から防止します。 大きなグローバルテーブルを持ったサイト(特にユーザーとusermeta), 同様にbbPressとか、他のWordPressのインストールと共有するサイトは DO_NOT_UPGRADE_GLOBAL_TABLESを定義することによってアップグレードの 間アップグレードがそれらのテーブルを変えることから防ぐことがでます。 ALTERや無制限DELETEまたはUPDATEは完了するのに時間がかかってしまい、 大きなサイトはたいていこれらの動作はさけたがるので一部のアップグレードとして取り扱います。 さらにもしインストールが複数のbbPressやWordPressのインストールでuser tableを共有したないなら アップグレード元となるひとつのサイトが必要となるかもしれない。

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_MODS と DISALLOW_FILE_EDIT の両方を設定する必要はありません。DISALLOW_FILE_MODS を設定すれば同じ効果があります。)

   define('DISALLOW_FILE_MODS',true);

アドミンとログインにSSLを要求する

FORCE_SSL_LOGIN はパスワードが危険から避けて、安全にログインしたい時に賛成です。 しかし、(SSLは遅くなるため)まだ、非SSL管理を許可したいです。

   define('FORCE_SSL_LOGIN',true);

FORCE_SSL_ADMINもパスワードが危険から避けて、安全にログインしたい時に賛成してます。 これは最も安全なオプションです。 Administration_Over_SSL

   define('FORCE_SSL_ADMIN',true);

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

外部URLブロックは真として、 WP_HTTP_BLOCK_EXTERNALを定義することにより要求される。 これは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の自動更新を無効にする

 # Disable all automatic updates:
 define( 'AUTOMATIC_UPDATER_DISABLED', true );

WordPress Core アップデートの無効化

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

 # Disable all core updates:
 define( 'WP_AUTO_UPDATE_CORE', false );

 # Enable all core updates, including minor and major:
 define( 'WP_AUTO_UPDATE_CORE', true );

 # Enable core updates for minor releases (default):
 define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Reference: Disabling Auto Updates in WordPress 3.7

Cleanup Image Edits

By default, WordPress creates a new set of images every time you edit an image and when you restore the original, it leaves all the edits on the server. Defining IMAGE_EDIT_OVERWRITE as true changes this behaviour. Only one set of image edits are ever created and when you restore the original, the edits are removed from the server.

 define( 'IMAGE_EDIT_OVERWRITE', true );


外部リソース

関連ページ

変更履歴


脚注

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


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

このページ「wp-config.php の編集」は一部未翻訳です。和訳や日本語情報を加筆してくださる協力者を求めています

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