wp-config.php の編集

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

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

wp-config.php ファイルは、インストールディレクトリのルートにある wp-config-sample.php を必要に応じて編集し、wp-config.php という名前で保存することで手動で作成することもできます。

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

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

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

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

データベース設定

重要: WordPress ファイルの編集に、 Microsoft Word のようなワープロアプリは絶対に使わないでください。

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

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

注: これはデフォルトの 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' );

注: /* */ の内側の文章は、情報説明のためのコメントです。

データベース名の設定

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' でインストールし、動作するかどうか確認してください。インストールに失敗しているようであれば、ホスティングプロバイダー (レンタルサーバー) に問い合わせてください。

MySQL 代替ポート

利用しているホスティングサービスがデータベースに代替ポートを使用している場合は、wp-config.phpDB_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 をホスティングサービスから指定されたソケットまたはパイプの情報と置き換えてください。

DB_HOST の候補

ホスティング会社によって MySQL データベースのネットワーク設定は異なります。ホスティング会社が以下の表の左側の列にあれば、DB_HOST の値は右側の列の値、または似た値になります。念の為、ホスティング会社のテクニカルサポートに連絡するか、オンラインドキュメントを確認してください。

日本のホスティングサービスDB_HOST 値
XREA (無料サーバ)localhost
エックスサーバーmysqlnn.xserver.jp (nn は数字)
さくらのレンタルサーバmysqlnn.db.sakura.ne.jp (nn は数字)
Just-Size.Networkslocalhost または mysqlnn.just-size.net (nn は数字)
freeweb (無料サーバ)localhost
ウイルネットlocalhost
海外のホスティング会社

英語版をご確認ください。

データベースの文字コード設定

DB_CHARSET で MySQL データベーステーブルの定義に使われる文字コード設定(例:タイの TIS620 用 tis620)の指定ができるようになりました。

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

次の例は、WordPress のデフォルト値 utf8 の場合です。

define( 'DB_CHARSET', 'utf8' );

通常 DB_CHARSET のデフォルト値を変更する必要はありません。ブログで別の文字コード設定が必要な場合は、MySQLでサポートされる有効な文字セットと照合順序を参照してください。

警告: アップグレードを実行している方へ。

wp-config.php ファイルに DB_CHARSET と DB_COLLATE の両方が存在しない場合、 DB 文字コードセットの変換を読んで理解できない限り、どちらの定義も wp-config.php ファイルに追加しないでください。既存ブログの wp-config.php ファイルに DB_CHARSET と DB_COLLATE を追加すると、不具合が生じる可能性があります。

データーベース照合順序

DB_COLLATE は、データベース照合順序 (文字セットのソート順) を指定できるようになりました。ほとんどの場合、この値は空白 (null) のままにしておくと、DB_CHARSET で指定されたデータベース文字設定のデータベース照合順序に基づいて自動的にデータベース照合順序が割り当てられます。DB_COLLATE を設定する例として特に西ヨーロッパ系の言語で、同じ入力に対して異なる文字を表示する言語の場合があります。このとき UTF-8 文字セットで定義された UTF-8 値を設定します。詳細は MySQL Manual Unicode Character Sets を参照してください。

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 によって自動的に割り当てられます。

警告: アップグレードを実行している方へ。

wp-config.php ファイルに DB_CHARSET と DB_COLLATE の両方が存在しない場合、DB 文字コードセットの変換を読んで理解できない限り、どちらの定義も wp-config.php ファイルに追加しないでください。既存ブログの wp-config.php ファイルに DB_CHARSET と DB_COLLATE を追加すると、不具合が生じる可能性があります。

セキュリティキー

キーを覚える必要はありません。長くて複雑なランダムな値を設定します。オンラインジェネレータ を使用して作成すると良いでしょう。これらは変更することで、既存のすべての 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’ などの辞書にある単語を使用しないランダムな長いパスワードは、ブルートフォースアタックで攻撃者が解読するのに何百万時間もかかります。生成された結果のセキュリティをさらに強化するためにソルトが使用されます。

セキュリティを強化するには、4つのキーが必要です。4つの SALT が推奨されますが、必須ではありません。何も登録されない場合、 WordPress は SALT を生成します。これは、包含性のためにデフォルトで wp-config.php に含まれています。

技術的背景と秘密鍵と安全なパスワードについては、以下を参照してください。

高度なオプション

次のセクションには高度な情報が含まれる場合があり、一部の変更により予期しない問題が発生する場合があります。これらの設定を変更する前に、定期的なバックアップを実行し、復元する方法を確認してください。

table_prefix

$table_prefix は、データベースのテーブル名の前につけられる値です。wp_ 以外のデータベース接頭辞を使用する場合はこの値を変更してください。通常、マルチサイトのように、同じデータベースに複数の WordPress インストールを行う場合に変更します。

それぞれに固有の接頭辞を付けると、1つのデータベースに複数のWordPressをインストールすることができます。この方法を行う場合はセキュリティに注意してください。

$table_prefix = 'r235_'; // 半角英数字とアンダースコア (_) のみ使用できます !

WP_SITEURL

WP_SITEURL は WordPress アドレス (URL) を定義します。ここで定義する値は、WordPress のコアファイルが存在する URL です。 http:// の部分は含める必要があります。最後のスラッシュ “/” は含めないでください。 wp-config.php でこの値を設定すると、 wp-options テーブルの値よりも優先されます。これを追加することで、サイトを読み込む時のデータベースの呼び出し回数を減らすことができます。

注: この設定はデータベースに保存されている値を変更しません。この行が wp-config.php から削除されると、URL は元のデータベースの値に戻ります。データベースの siteurl の値を変更するには RELOCATE 定数を使用します。

ドメイン名 example.comwordpress ディレクトリに 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 も動的に作成されますが、 Appacheを 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_HOME は WP_SITEURL と同様に wp_opsions テーブルの値よりも優先されますが、データベースの値は変更されません。home は WordPress にアクセスするためにユーザーがブラウザに入力するアドレスです。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 ディレクトリの移動

テーマやプラグイン、アップロードファイルなどがある、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 にこのディレクトリの完全な URI (末尾のスラッシュなし) を指定してください。

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

プラグインとの互換性の問題がある場合 PLUGINDIR にこのディレクトリの完全なローカルパス (末尾のスラッシュなし) を指定してください。

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

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

テーマディレクトリはパスが以下のようにハードコードされているため、wp-content ディレクトリの外に移動できません。

$theme_root = WP_CONTENT_DIR . '/themes'; 

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

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

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

UPLOADS の設定は以下のとおりです。

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

このパスは絶対パスにすることは出来ません。常に ABSPATH からの相対なので、先頭のスラッシュ (/) は必要ありません。

自動保存間隔の変更

投稿を編集する際、 WordPress は Ajax を使用して編集中の投稿の改訂履歴 (リビジョン) を自動保存します。自動保存の間隔を伸ばすにはこの値を増やし、変更が失われないようにするには値を減らします。初期値は 60 秒です。

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

投稿の改訂履歴

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

投稿の改訂履歴を無効にする

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

define( 'WP_POST_REVISIONS', false );

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

投稿の改訂履歴の数を指定する

WordPress が保存する改訂履歴の版数の最大値を指定する場合は、 false を 3 や 12 などの数値に変更します。

define( 'WP_POST_REVISIONS', 3 );

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

Cookie ドメインの設定

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

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

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

WP_ALLOW_MULTISITE は、マルチサイトを有効にする機能です。この設定が wp-config.php にない場合、デフォルトは false です。

define( 'WP_ALLOW_MULTISITE', true );

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

存在しないサブドメインまたはサブディレクトリにアクセスされた場合 NOBLOGREDIRECT を使用して、ブラウザをリダイレクトできます。

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

WP_DISABLE_FATAL_ERROR_HANDLER

WordPress5.2 で、プラグインが致命的なエラーを起こした場合に、白い画面ではなくエラーメッセージを表示するリカバリモードが導入されました。

サイトで技術的な問題が発生しています。サイト管理者のメールを確認して指示に従ってください。

白い画面と PHP のエラーメッセージはユーザーに表示されなくなりました。しかし、開発環境で WP_DEBUG_DISPLAY を有効にする場合は、 WP_DISABLE_FATAL_ERROR_HANDLER に true を設定してリカバリモードを無効にする必要があります。

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 以降 
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );

デバッグ

WP_DEBUG オプションは、いくつかのエラーと警告のレポートを制御し、 WP_DEBUG_DISPLAY と WP_DEBUG_LOG 設定の使用を有効にします。デフォルトは false です。

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 以降
define( 'WP_DEBUG', true );

データベースエラーは、 WP_DEBUG が true に設定されている場合にのみ表示されます。データベースエラーは wpdb クラスによって処理され、 PHP のエラー設定の影響を受けません。

WP_DEBUG を true にした場合、エラー出力レベルも E_ALL に上げられ、非推奨関数やファイルを使用すると警告が表示されます。 false の場合、 WordPress はエラー出力レベルを E_ALL ^ E_NOTICE ^ E_USER_NOTICE に設定します。

SCRIPT_DEBUG

SCRIPT_DEBUG は WordPress が wp-includes/jswp-includes/csswp-admin/js および、 wp-admin/css のスクリプトとスタイルシートの「開発」バージョンを強制的に読み込みます。これは、 .min.css.min.js バージョンの代わりに読み込まれます。 WordPress の組み込み JavaScript またはカスケーディングスタイルシート (CSS) の一部を変更する場合は、次のコードを構成ファイルに追加する必要があります。

define( 'SCRIPT_DEBUG', true );

JavaScript 連結の無効化

管理画面を高速化するために、全ての JavaScript ファイルが 1 つの 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 を記録しません (動作するものの粗雑なコードを使用すると投げられます) 。 目的にあったカスタムエラー値を決定し、 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_DEBUG を true に設定すると、 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' );
/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */

次は wp-hackers のメーリングリストで Mike Little が提案した、エラーを記録する別の例です。

/**
 * これにより、すべてのエラー通知と警告が 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 );

マンチェスター WordPress ユーザーグループ で提案された Mike Little による改良版。

/**
 * WP_DEBUG が true である場合に限り、すべてのエラー、通知、警告をファイル
 * 「wp-content/debug.log」に出力します。
 * Apache に書き込み権限がない場合、先にファイルを作成し、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 );
}

WordPress には似たような 3 つの定数があるため混乱しますが、以下の点に注意してください。
まず WP_DEBUG が false の場合、WP_DEBUG を含む 3 つの DEBUG 定数は何の動作もしません。すべての PHP ディレクティブ ( 設定オプション ) の設定は有効です。例外は ‘error_reporting’ で、WP_DEBUG が false の場合、WordPress は ‘error_reporting’ に 4983 を設定します。
2番目に、WP_DEBUG が true に設定されても、WP_DEBUG_LOG と WP_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 の割り当てメモリを増やす

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 を使用するには、次の方法がもっとも簡単です。
最初のインスタンスの wp-config.php 内の define 文では、現在ユーザーデータを格納するテーブル、デフォルトでは wp_users テーブルを指定します。
最初のサイトのセットアップ後、この wp-config.php を2番目のインストール開始前のインスタンスへコピーします。このとき $table_prefix 変数の値を変更します。
元のインストールで既に使用されている電子メールアドレスは使用しないでください。
セットアップを終えたら、自動生成された admin アカウントとパスワードでログインします。
次に、管理に使用する個人アカウントに管理者権限を付与します。
自分でログインし直し、管理者アカウントを削除し、必要に応じて他のユーザーアカウントを昇格させます。

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

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

WordPress バージョン 3.9.6 以前

WPLANG は、言語翻訳ファイル(.mo)の名前を定義します。WP_LANG_DIR は、WPLANG .mo ファイルが存在するディレクトリを定義します。WP_LANG_DIR が定義されていなければ、WordPress は wp-content/languages、wp-includes/languages の順に .mo ファイルを探します。

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

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

解析向けにクエリを保存

SAVEQUERIES を定義すると、データベースクエリを配列に保存し、表示でき、クエリの分析を行うことが出来ます。保存される情報は各クエリ、呼び出された関数、クエリ実行時間です。
注: この設定はサイトのパフォーマンスに影響を与えます。デバッグ以外では無効化してください。

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

define( 'SAVEQUERIES', true );

次にテーマフッターに以下を追加します。

<?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 など) を使用するホストで、「グループ」または「その他」のパーミッションによるファイルアクセスが拒否される場合、この定義で問題を解決できます。

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

setgid を指定する例:

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

注: ‘0755‘ および ‘02755‘ は 8 進数です。 8 進数は 0 で始まり、引用符 (‘) で囲みません。「ファイルパーミッションの変更」も参照してください。

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_PASSFTP_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

WP で代替 cron を使用する必要がある場合があります。例えば予約済み投稿が正しく公開されない場合に使用します。この代替メソッドはリダイレクト手法を使用します。cron の動作が必要になるとユーザーのブラウザはリダイレクトされ、抜けた接続内で cron が動作している間にすぐにサイトに戻ってきます。この方法は、非ネイティブの WordPress サービスに依存するため、特定のリスクがあります。

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

ゴミ箱を空にする

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

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

ゴミ箱機能を無効化するには、この数字を0にします。

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

注: この設定を使用して「完全に削除する」をクリックしても WordPress は確認ダイアログを表示しません。

自動データベース最適化

以下の定義を wp-config.php ファイルに追加すると自動データベース最適化のサポートが有効化されます。

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

 define( 'WP_ALLOW_REPAIR', true );

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

DO_NOT_UPGRADE_GLOBAL_TABLES

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' ) を使用すると影響を受ける場合があります。プラグイン作成者はエディター機能の確認を避けるか、少なくともこの定数の設定の有無を確認し、適切なエラーメッセージを表示してください。プラグインが動作しない場合、この定数が原因の場合があります。

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

この定数は 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 定数を使用することです。

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

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

画像編集のクリーンアップ

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

 define( 'IMAGE_EDIT_OVERWRITE', true );

保存の前の再確認

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

ファイルを保存する前に、パラメーター値を囲む引用符を誤って削除されていないことを必ず確認してください。ファイル内の終了 PHP タグの後にはなにもないことを確認してください。ファイルの最後は ?> であり、それ以外はなにもないはずです。空白もありません。

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

この記事は役に立ちましたか ? どうすればさらに改善できますか ?