データベース設定の構成

重要: 決して Microsoft Wordのようなワードプロセッサを使用してWordPressファイルを編集しないでください！

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

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

注: これはデフォルトのwp-config-sample.phpの例です。ここにある値は、何をすべきかを示すための例です。 

  1. // ** MySQL settings - You can get this info from your web host ** //
  2. /** The name of the database for WordPress */
  3. define( 'DB_NAME', 'database_name_here' );
  4. /** MySQL database username */
  5. define( 'DB_USER', 'username_here' );
  6. /** MySQL database password */
  7. define( 'DB_PASSWORD', 'password_here' );
  8. /** MySQL hostname */
  9. define( 'DB_HOST', 'localhost' );

注: / /内のテキストは コメントであり、情報提供のみを目的としています。

データベース名の設定

‘database_name_here’をあなたのデータベースの名前、例えばMyDatabaseNameに置き換えます。 

  1. define( 'DB_NAME', 'MyDatabaseName' ); // Example MySQL database name

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

‘username_here’をあなたのユーザー名、例えばMyUserNameに置き換えます。 

  1. define( 'DB_USER', 'MyUserName' ); // Example MySQL username

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

‘password_here’をあなたのパスワード、例えばMyPassWordに置き換えます。 

  1. define( 'DB_PASSWORD', 'MyPassWord' ); // Example MySQL password

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

必要に応じて、‘localhost’をあなたのデータベースホストの名前（例: MyDatabaseHost）に置き換えます。ポート番号やUnixソケットファイルパスも必要になる場合があります。 

  1. define( 'DB_HOST', 'MyDatabaseHost' ); // Example MySQL Database host

注: 変更する必要がない可能性が高いです。確信がない場合は、デフォルト値の‘localhost’でインストールを試みて、動作するか確認してください。インストールが失敗した場合は、ウェブホスティングプロバイダーに連絡してください。

MySQLの代替ポート

ホストがデータベース用の代替ポート番号を使用している場合、wp-config.phpファイル内のDB_HOST値をホストが提供する代替ポートに反映させる必要があります。

ローカルホストの場合: 

  1. define( 'DB_HOST', '127.0.0.1:3307' );
  2. or
  3. define( 'DB_HOST', 'localhost:3307' );

指定されたサーバーの場合: 

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

上記のコード例のいずれかで、ホストが提供するポート番号情報で3307を置き換えます。

MySQLソケットまたはパイプ

ホストがUnixソケットまたはパイプを使用している場合、wp-config.phpファイル内のDB_HOST値をホストが提供するソケットまたはパイプ情報に反映させる必要があります。 

  1. define( 'DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock' );
  2. // or define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );
  3. // or define( 'DB_HOST', 'example.tld:/var/run/mysqld/mysqld.sock' );

上記の/var/run/mysqld/mysqld.sockのテキスト文字列をホストが提供するソケットまたはパイプ情報に置き換えます。

データベース文字セット

DB_CHARSETは、MySQLデータベーステーブルを定義する際に使用されるデータベース文字セット（例: TIS620 Thai用のtis620）を指定できるようにするために提供されました。

デフォルト値のutf8（Unicode UTF-8）は、ほぼ常に最良の選択肢です。UTF-8は任意の言語をサポートするため、通常はDB_CHARSETをutf8のままにし、代わりにあなたの言語のDB_COLLATE値を使用することをお勧めします。

この例は、WordPressのデフォルト値と見なされるutf8を示しています: 

  1. define( 'DB_CHARSET', 'utf8' );

通常、DB_CHARSETのデフォルト値を変更する理由はありません。ブログが異なる文字セットを必要とする場合は、MySQLがサポートする文字セットと照合を読んで、有効なDB_CHARSET値を確認してください。警告: アップグレードを行う人へ。 

  1.  <a name="database-collation"></a>
  3. ### データベース照合
  5. **DB\_COLLATE**は、データベースの[照合](https://codex.wordpress.org/Glossary#Collation)（すなわち、文字セットのソート順序）を指定できるようにするために提供されました。ほとんどの場合、この値は空白（null）のままにしておくべきであり、DB_CHARSETで指定されたデータベース文字セットに基づいてMySQLによって自動的にデータベース照合が割り当てられます。異なる言語で、入力した文字が表示されるものと異なる場合に、[UTF-8文字セット](http://dev.mysql.com/doc/refman/5.6/en/charset-unicode-sets.html)で定義されたUTF-8値の1つに‘DB_COLLATE’を設定する必要がある場合があります（SQLマニュアルの[Unicode文字セット](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html#charset-unicode-sets-general-versus-unicode)も参照）。  
  7. WordPressのデフォルトDB_COLLATE値:  
  10. ``````bash
  11. define( 'DB_COLLATE', '' );
  12. `

UTF-8 Unicode一般照合 

  1. define( 'DB_COLLATE', 'utf8_general_ci' );

UTF-8 Unicodeトルコ語照合 

  1. define( 'DB_COLLATE', 'utf8_turkish_ci' );

通常、DB_COLLATEのデフォルト値を変更する理由はありません。値を空白（null）のままにすると、データベーステーブルが作成されるときに照合がMySQLによって自動的に割り当てられます。警告: アップグレードを行う人へ 

  1.  <a name="security-keys"></a>
  3. ### セキュリティキー
  5. キーを覚えておく必要はありません。長く、ランダムで複雑にしてください — それよりも、[オンラインジェネレーター](https://api.wordpress.org/secret-key/1.1/salt/)を使用するのが良いでしょう。これらはいつでも変更でき、すべての既存のクッキーを無効にします。これは、すべてのユーザーが再度ログインする必要があることを意味します。  
  7. 例（これを使用しないでください！）:  
  10. ``````bash
  11. define( 'AUTH_KEY',         't`DK%X:>xy|e-Z(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@}IcnCa|' );
  12. define( 'SECURE_AUTH_KEY',  'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj' );
  13. define( 'LOGGED_IN_KEY',    'MGKi8Br(&{H*~&0s;{k0<S(O:+f#WM+q|npJ-+P;RDKT:~jrmgj#/-,[hOBk!ry^' );
  14. define( 'NONCE_KEY',        'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe' );
  15. define( 'AUTH_SALT',        '7T-!^i!0,w)L#JK@pc2{8XE[DenYI^BVf{L:jvF,hf}zBf883td6D;Vcy8,S)-&G' );
  16. define( 'SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F }F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #' );
  17. define( 'LOGGED_IN_SALT',   'w<$4c$Hmd%/*]`Oom>(hdXW|0M=X={we6;Mpvtg+V.o<$|#_}qG(GaVDEsn,~*4i' );
  18. define( 'NONCE_SALT',       'a|#h{c5|P &xWs4IZ20c2&%4!c(/uG}W:mAvy<I44`jAbup]t=]V<`}.py(wTP%%' );
  19. `

秘密鍵は、パスワードにランダムな要素を追加することで、サイトを攻撃しにくくします。

簡単に言えば、秘密鍵は、セキュリティバリアを突破するための選択肢を生成するのが難しくなる要素を持つパスワードです。「password」や「test」のようなパスワードは単純で簡単に破られます。辞書の単語を使用しない、ランダムで長いパスワード（例: “88a7da62429ba6ad3cb3c76a09641fc”）は、ブルートフォース攻撃者が解読するのに何百万時間もかかります。‘saltは、生成された結果のセキュリティをさらに強化するために使用されます。

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

秘密鍵と安全なパスワードの技術的背景と内訳についての詳細は、次を参照してください:

高度なオプション

以下のセクションには高度な情報が含まれている場合があり、一部の変更は予期しない問題を引き起こす可能性があります。これらの設定を変更する前に、定期的なバックアップを実施し、それを復元する方法を知っていることを確認してください。

table_prefix

$table_prefixは、データベーステーブルの前に置かれる値です。データベースプレフィックスとしてwp_以外のものを使用したい場合は、値を変更してください。通常、これは同じデータベースに複数のWordPressブログをインストールする場合に変更されます。これはマルチサイト機能で行われます。

一意のプレフィックスを与えることで、1つのデータベースに複数のインストールを持つことが可能です。これを選択する場合は、セキュリティを考慮してください。 

  1. $table_prefix = 'r235_'; // Only numbers, letters, and underscores please!

WP_SITEURL

WP_SITEURLは、WordPressアドレス（URL）を定義できるようにします。定義された値は、WordPressコアファイルが存在するアドレスです。http://部分も含める必要があります。末尾にスラッシュ“/”を付けないでください。この値をwp-config.phpに設定すると、siteurlのwp_optionsテーブルの値が上書きされます。これを追加することで、サイトを読み込む際のデータベース呼び出しの数を減らすことができます。注: これはデータベースに保存された値を変更しません。この行がwp-configから削除されると、URLは古いデータベース値に戻ります。RELOCATE定数を使用して、データベース内のsiteurl値を変更します。

WordPressがdomain example.comの“wordpress”というディレクトリにインストールされている場合、次のようにWP_SITEURLを定義します: 

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

$_SERVER[‘HTTP_HOST’]に基づいてWP_SITEURLを動的に設定 

  1. 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を動的に設定 

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

ブログアドレス（URL）

WP_SITEURLと同様に、WP_HOMEはhomeのwp_optionsテーブルの値を上書きしますが、データベース内では変更しません。homeは、ユーザーがブラウザに入力してWordPressブログにアクセスするためのアドレスです。http://部分を含め、末尾にスラッシュ“/”を付けないでください。これを追加することで、サイトを読み込む際のデータベース呼び出しの数を減らすことができます。 

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

Giving WordPress Its Own Directoryで説明されている技術を使用している場合は、以下の例に従ってください。このような設定を使用する場合、ウェブルートディレクトリにもindex.phpを配置することになります。 

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

$_SERVER[‘HTTP_HOST’]に基づいてWP_HOMEを動的に設定 

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

wp-contentフォルダの移動

テーマ、プラグイン、アップロードを保持するwp-contentディレクトリをWordPressアプリケーションディレクトリの外に移動できます。

WP_CONTENT_DIRをこのディレクトリの完全なローカルパスに設定します（末尾にスラッシュは不要）、例: 

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

WP_CONTENT_URLをこのディレクトリの完全なURLに設定します（末尾にスラッシュは不要）、例: 

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

プラグインフォルダの移動

WP_PLUGIN_DIRをこのディレクトリの完全なローカルパスに設定します（末尾にスラッシュは不要）、例: 

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

WP_PLUGIN_URLをこのディレクトリの完全なURIに設定します（末尾にスラッシュは不要）、例: 

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

プラグインに互換性の問題がある場合は、PLUGINDIRをこのディレクトリの完全なローカルパスに設定します（末尾にスラッシュは不要）、例: 

  1. 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を次のように設定します: 

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

このパスは絶対的であってはなりません。常にABSPATHに対して相対的であるため、先頭にスラッシュは必要ありません。

自動保存間隔の変更

投稿を編集する際、WordPressはAjaxを使用して投稿のリビジョンを自動保存します。この設定を増やして自動保存の間隔を長くするか、設定を減らして変更を失わないようにすることができます。デフォルトは60秒です。 

  1. define( 'AUTOSAVE_INTERVAL', 160 ); // Seconds

投稿リビジョン

WordPressはデフォルトで、投稿やページに対する各編集のコピーを保存し、その投稿やページの以前のバージョンに戻る可能性を提供します。リビジョンの保存は無効にすることができるか、投稿やページごとに最大リビジョン数を指定できます。

投稿リビジョンの無効化

この値を設定しない場合、WordPressはデフォルトでWP_POST_REVISIONSをtrue（投稿リビジョンを有効にする）に設定します。この素晴らしいリビジョン機能を無効にしたい場合は、この設定を使用します: 

  1. define( 'WP_POST_REVISIONS', false );

注: 一部のユーザーは、wp-config.phpの初期ブロックコメントの下の最初の行にコマンドを移動するまで、これが機能しなかったと報告しています。

投稿リビジョンの数を指定

WordPressが保存するリビジョンの最大数を指定したい場合は、falseを整数/数値（例、3または12）に変更します。 

  1. define( 'WP_POST_REVISIONS', 3 );

注: 一部のユーザーは、wp-config.phpの初期ブロックコメントの下の最初の行にコマンドを移動するまで、これが機能しなかったと報告しています。

クッキーのドメインを設定

WordPressのクッキーに設定されるドメインは、異常なドメイン設定を持つ場合に指定できます。たとえば、サブドメインを使用して静的コンテンツを提供する場合、静的コンテンツへの各リクエストでWordPressクッキーが送信されないように、クッキーのドメインを非静的ドメインのみに設定できます。 

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

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

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

  1. define( 'WP_ALLOW_MULTISITE', true );

存在しないブログのリダイレクト

NOBLOGREDIRECTは、訪問者が存在しないサブドメインまたはサブフォルダにアクセスしようとした場合にブラウザをリダイレクトするために使用できます。 

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

致命的エラーハンドラー

WordPress 5.2では、リカバリーモードが導入され、プラグインが致命的なエラーを引き起こした場合に白い画面の代わりにエラーメッセージが表示されます。

サイトは技術的な問題に直面しています。指示については、サイト管理者のメールボックスを確認してください。

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

  1. define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later define( 'WP_DEBUG', true );
  2. define( 'WP_DEBUG_DISPLAY', true );

WP_DEBUG

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

  1. define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later
  2. define( 'WP_DEBUG', true );

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

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

WP_ENVIRONMENT_TYPE

WP_ENVIRONMENT_TYPEオプションは、サイトの環境タイプを制御します: local、development、staging、およびproduction。

環境タイプの値は、次の順序で処理され、各連続する方法が以前の値を上書きします: WP_ENVIRONMENT_TYPE PHP環境変数およびWP_ENVIRONMENT_TYPE定数。

両方の方法で、提供された環境タイプの値が許可された環境タイプのリストにない場合、デフォルトのproduction値が返されます。

値を設定する最も簡単な方法は、おそらく定数を定義することです: 

  1. define( 'WP_ENVIRONMENT_TYPE', 'staging' );

注: developmentがwp_get_environment_type()によって返されると、WP_DEBUGはtrueに設定されます。wp-config.phpファイルに定義されていない場合。

SCRIPT_DEBUG

SCRIPT_DEBUGは、WordPressがwp-includes/js、wp-includes/css、wp-admin/js、およびwp-admin/cssのスクリプトとスタイルシートの“dev”バージョンを使用するように強制する関連定数です。WordPressの組み込みJavaScriptやCascading Style Sheetsの一部を変更する予定がある場合は、次のコードを設定ファイルに追加する必要があります: 

  1. define( 'SCRIPT_DEBUG', true );

JavaScriptの連結を無効化

管理画面をより速くするために、すべてのJavaScriptファイルは連結されて1つのURLにまとめられます。管理画面でJavaScriptが機能しない場合は、この機能を無効にしてみてください: 

  1. define( 'CONCATENATE_SCRIPTS', false );

エラーロギングの構成

エラーロギングの構成は少し難しい場合があります。まず、デフォルトのPHPエラーログと表示設定はphp.iniファイルに設定されており、アクセスできるかどうかは不明です。アクセスできる場合は、公開されるPHPページに対して望ましい設定に設定する必要があります。エラーメッセージは公開されないことを強く推奨し、代わりにエラーログにルーティングするべきです。さらに、エラーログはサーバーの公開アクセス可能な部分に配置されるべきではありません。推奨されるphp.iniエラー設定のサンプル: 

  1. error_reporting = 4339
  2. display_errors = Off
  3. display_startup_errors = Off
  4. log_errors = On
  5. error_log = /home/example.com/logs/php_error.log
  6. log_errors_max_len = 1024
  7. ignore_repeated_errors = On
  8. ignore_repeated_source = Off
  9. html_errors = Off

エラーレポート4339について これは、サイトの機能に影響を与える問題のみをログに記録し、エラーでない可能性のある通知などは無視するカスタム値です。1000011110011の各バイナリ位置の意味については、PHPエラー定数を参照してください。最も左の1は、E_RECOVERABLE_ERRORを報告することを意味します。次の0は、E_STRICTを報告しないことを意味します（これは、雑ながらも機能するコーディングが使用されるときに発生します）などです。4339の代わりに使用するカスタムエラーレポート番号を自由に決定してください。

明らかに、開発環境には異なる設定が必要です。ステージングコピーが同じサーバー上にある場合、またはphp.iniにアクセスできない場合は、実行時にデフォルト設定を上書きする必要があります。エラーをログファイルに送信するか、エラーが発生した場合に即座に通知されることを好むか、またはその両方を好むかは個人の好みです。以下は、wp-config.phpファイルに挿入できるすべてのエラーを即座に報告する例です: 

  1. @ini_set( 'log_errors', 'Off' );
  2. @ini_set( 'display_errors', 'On' );
  3. define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later
  4. define( 'WP_DEBUG', true );
  5. define( 'WP_DEBUG_LOG', false );
  6. define( 'WP_DEBUG_DISPLAY', true );
  2. エラーロギングをオンにした場合は、後でファイルを削除することを忘れないでください。公開アクセス可能な場所にあることが多く、誰でもログにアクセスできる可能性があります。  
  4. PHPエラーロギングをオンにし、特定のファイルにログを記録する例です。WP_DEBUGがtrueに定義されている場合、エラーもこのファイルに保存されます。*require_once*または*include*コマンドの上に配置してください。  
  7. ``````bash
  8. @ini_set( 'log_errors', 'On' );
  9. @ini_set( 'display_errors', 'Off' );
  10. @ini_set( 'error_log', '/home/example.com/logs/php_error.log' );
  11. /* That's all, stop editing! Happy blogging. */
  12. `

Mike Littleがwp-hackersメールリストで提案したエラーをログに記録する別の例: 

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

Manchester WordPressユーザーグループのMike Littleによる洗練されたバージョン: 

  1. /**
  2.  * This will log all errors notices and warnings to a file called debug.log in
  3.  * wp-content only when WP_DEBUG is true. if Apache does not have write permission,
  4.  * you may need to create the file first and set the appropriate permissions (i.e. use 666).
  5.  */
  6. define( 'WP_DEBUG', true ); // Or false
  7. if ( WP_DEBUG ) {
  8.    define( 'WP_DEBUG_LOG', true );
  9.    define( 'WP_DEBUG_DISPLAY', false );
  10.    @ini_set( 'display_errors', 0 );
  11. }

問題を混乱させるのは、WordPressには同じことをするように見える3つの定数があることです。まず、WP_DEBUGがfalseの場合、WP_DEBUGと他の2つのWordPress DEBUG定数は何も行いません。PHPの指示は、何であれ優先されます。‘error_reporting’を除いて、WordPressはこれをfalseとして定義されている場合4983に設定します。次に、WP_DEBUGがtrueであっても、他の定数はそれらもtrueに設定されている場合にのみ何かを行います。falseに設定されている場合、PHPの指示は変更されません。たとえば、php.iniファイルに指示（‘display_errors’ = ‘On’）がある場合でも、wp-config.phpファイルにdefine(‘WP_DEBUG_DISPLAY’, false);という文があると、WP_DEBUG_DISPLAYをfalseに設定しても、エラーは画面に表示されます。これは、PHPの設定された動作です。このため、関連するWP定数がfalseに設定されている場合に必要なPHPの指示を設定することが非常に重要です。安全のために、両方のタイプを明示的に設定/定義してください。WP定数の詳細な説明は、WordPressのデバッグで入手できます。

公開用のWordPressインストールには、wp-config.phpファイルに次の内容を配置することを検討してください。部分的に冗長であるかもしれませんが: 

  1. @ini_set( 'log_errors', 'On' );
  2. @ini_set( 'display_errors', 'Off' );
  3. define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false );   // 5.2 and later
  4. define( 'WP_DEBUG', false );
  5. define( 'WP_DEBUG_LOG', false );
  6. define( 'WP_DEBUG_DISPLAY', false );

デフォルトのデバッグログファイルは/wp-content/debug.logです。公開アクセス可能な場所にエラーログを配置することはセキュリティリスクです。理想的には、ログファイルはサイトの公開ルートディレクトリの上に配置されるべきです。これができない場合は、少なくともログファイルの権限を600に設定し、WordPressインストールのルートディレクトリにある.htaccessファイルにこのエントリを追加してください: 

  1. <Files debug.log>
  2.    Order allow,deny
  3.    Deny from all
  4. </Files>

これにより、誰もHTTP経由でファイルにアクセスできなくなります。サーバーからFTP経由でログファイルを取得することで、常にログファイルを表示できます。

PHPに割り当てられたメモリの増加

WP_MEMORY_LIMITオプションは、PHPが消費できる最大メモリ量を指定できます。この設定は、「Allowed memory size of xxxxxx bytes exhausted」というメッセージを受け取った場合に必要になることがあります。

この設定は、WordPressのためにのみPHPメモリを増加させ、他のアプリケーションには影響しません。デフォルトでは、WordPressはシングルサイトの場合は40MB（/wp-includes/default-constants.phpのコードの最初にあります）、マルチサイトの場合は64MBにPHPに割り当てられたメモリを増やそうとします。したがって、wp-config.phpの設定は、セットアップに応じて40MBまたは64MBよりも高い値を反映する必要があります。

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

注: 一部のホストは、PHPメモリ制限を自動的に増加させることを許可していません。その場合は、ホストに連絡してPHPメモリ制限を増加させてください。また、多くのホストはPHP制限を8MBに設定しています。

WordPressのメモリ制限を調整することは、問題を引き起こす可能性もあります。プラグインや機能を追加するにつれて、後で問題が発生する根本的な原因を隠すことになるかもしれません。

メモリ制限を引き上げてもOut of Memoryの問題が発生する場合は、インストールを適切にデバッグする必要があります。特定のアクションに関連付けられたメモリ集約関数が多すぎる可能性があり、これらの関数をcronjobに移動する必要があります。

PHPメモリを64MBに増加 

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

PHPメモリを96MBに増加 

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

管理タスクは、通常の操作よりもメモリを必要とする場合があります。管理エリアにいるとき、メモリはWP_MEMORY_LIMITから増加または減少させることができ、WP_MAX_MEMORY_LIMITを定義することで行います。デフォルト値は256MBです。 

  1. define( 'WP_MAX_MEMORY_LIMIT', '512M' );

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

キャッシュ

WP_CACHE設定がtrueの場合、wp-content/advanced-cache.phpスクリプトがwp-settings.phpを実行する際に含まれます。 

  1. define( 'WP_CACHE', true );

カスタムユーザーおよびユーザーメタテーブル

CUSTOM_USER_TABLEおよびCUSTOM_USER_META_TABLEは、通常WordPressによって使用されるユーザーおよびユーザーメタテーブルが使用されないことを指定するために使用されます。代わりに、これらの値/テーブルがユーザー情報を保存するために使用されます。 

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

注: ‘CUSTOM_USER_META_TABLE’が手動で設定されている場合でも、各インスタンスに対して対応する権限を持つユーザーメタテーブルが各データベースに作成されます。デフォルトでは、WordPressインストーラーは最初のユーザー（ID #1）に対して権限を追加します。各サイトへの権限を管理するためには、プラグインまたはカスタム関数が必要です。これが設定されていない場合、権限エラーやログインの問題が発生します。

CUSTOM_USER_TABLEは、最初のWordPressインスタンスの初期設定中に採用するのが最も簡単です。最初のインスタンスのwp-config.phpの定義文は、wp_usersデータがデフォルトで保存される場所を指します。最初のサイトの設定後、動作しているwp-config.phpを次のインスタンスにコピーするには、$table_prefix変数を変更するだけで済みます。元のインストールで既に使用されているメールアドレスを使用しないでください。設定プロセスが完了したら、自動生成された管理アカウントとパスワードでログインします。次に、通常のアカウントを管理者レベルに昇格させ、管理者からログアウトします。自分として再度ログインし、管理アカウントを削除し、必要に応じて他のユーザーアカウントを昇格させます。

言語と言語ディレクトリ

WordPress バージョン4.0では、WordPressの管理画面で言語を変更できます。管理設定画面で言語を変更するには、設定 > 一般に移動し、サイトの言語を選択します。

WordPress v3.9.6およびそれ以前

WPLANGは、言語翻訳（.mo）ファイルの名前を定義します。WP_LANG_DIRは、WPLANG .moファイルが存在するディレクトリを定義します。WP_LANG_DIRが定義されていない場合、WordPressは最初にwp-content/languagesを確認し、その後wp-includes/languagesでWPLANGファイルによって定義された.moを探します。 

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

WPLANG言語コードを見つけるには、こちらを参照してください。WP Local列のコードが必要なものです。

Save queries for analysis

SAVEQUERIES定義は、データベースクエリを配列に保存し、その配列を表示してクエリを分析するのに役立ちます。情報は各クエリ、どの関数がそれを呼び出したか、そしてそのクエリが実行されるのにかかった時間を保存します。注意: これはサイトのパフォーマンスに影響を与えるため、デバッグしていないときはこれをオフにしてください。

まず、wp-config.phpファイルにこれを追加します: 

  1. define( 'SAVEQUERIES', true );

次に、テーマのフッターにこれを置きます: 

  1. if ( current_user_can( 'administrator' ) ) {
  2.    global $wpdb;
  3.    echo "<pre>";
  4.    print_r( $wpdb->queries );
  5.    echo "</pre>";
  6. }
  7. ?>

または、Query Monitorの使用を検討してください。

デフォルトファイル権限のオーバーライド

FS_CHMOD_DIRおよびFS_CHMOD_FILEの定義文は、デフォルトのファイル権限を上書きすることを許可します。これら2つの変数は、suexecで実行されているホストのコア更新機能が失敗するという問題に応じて開発されました。ホストがすべてのユーザーファイルに対して制限付きファイル権限（例: 400）を使用し、グループまたは世界の権限が設定されたファイルへのアクセスを拒否する場合、これらの定義は問題を解決する可能性があります。 

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

setgidを提供する例: 

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

注意: ‘0755′ および ‘02755‘ は8進数の値です。8進数の値は0で始まる必要があり、単一引用符（‘）で区切られてはいけません。参照: ファイル権限の変更

WordPress Upgrade Constants

注意: 更新の問題を修正するために必要な定数をできるだけ少なく定義してください。

これらを定義する必要がある最も一般的な原因は:

特別なインストール設定でsymlinkを使用しているホスト。パス関連の定数（FTP_BASE、FTP_CONTENT_DIR、FTP_PLUGIN_DIR）を定義する必要があるかもしれません。通常、単にベースを定義するだけで十分です。

特定のPHPインストールには、特定のFTPサーバーと互換性のないPHP FTP拡張が付属しています。これらのまれな状況下では、FS_METHODを「ftpsockets」に定義する必要があるかもしれません。

以下は、WordPressの更新に有効な定数です:

  • FS_METHODは、ファイルシステムメソッドを強制します。「direct」、「ssh2」、「ftpext」、または「ftpsockets」のいずれかである必要があります。一般的には、更新の問題が発生している場合にのみ変更するべきです。変更しても効果がない場合は、元に戻す/削除する必要があります。ほとんどの状況では、自動的に選択された方法が機能しない場合、’ftpsockets’に設定することで機能します。
    • （主な優先）「direct」は、PHP内から直接ファイルI/Oリクエストを使用することを強制します。これは、設定が不十分なホストでセキュリティの問題を引き起こす可能性があります。適切な場合に自動的に選択されます。
    • （二次優先）「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インストールのプラグインフォルダへの完全なパスです。
  • 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です（すべてのサーバーで利用可能ではありません）。これは「セキュアFTP」のためであり、SSH SFTPのためではありません。 
  1. define( 'FS_METHOD', 'ftpext' );
  2. define( 'FTP_BASE', '/path/to/wordpress/' );
  3. define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' );
  4. define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' );
  5. define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' );
  6. define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' );
  7. define( 'FTP_USER', 'username' );
  8. define( 'FTP_PASS', 'password' );
  9. define( 'FTP_HOST', 'ftp.example.org' );
  10. define( 'FTP_SSL', false );

一部の構成では、プラグインやWP自体を更新しようとしたときに503の問題を回避するためにFTP_HOSTをlocalhostに設定する必要があります。

Enabling SSH Upgrade Access

SSH2を使用してアップグレードする方法は2つあります。

最初は、SSH SFTP Updater Supportプラグインを使用することです。2つ目は、pecl SSH2拡張がインストールされている必要がある組み込みのSSH2アップグレーダーを使用することです。

pecl SSH2拡張をインストールするには、次のようなコマンドを発行する必要があります。あるいは、これをインストールするためにウェブホスティングプロバイダーに相談してください: 

  1. pecl install ssh2

pecl ssh2拡張をインストールした後は、この拡張を自動的に読み込むようにPHP設定を変更する必要があります。

peclは、ほとんどのLinuxディストリビューションでpearパッケージによって提供されます。Redhat/Fedora/CentOSでpeclをインストールするには: 

  1. yum -y install php-pear

Debian/Ubuntuでpeclをインストールするには: 

  1. apt-get install php-pear

パスフレーズで保護されていないプライベートキーを使用することをお勧めします。パスフレーズで保護されたプライベートキーが正しく機能しないという報告が多数あります。パスフレーズで保護されたプライベートキーを試すことに決めた場合は、プライベートキーのパスフレーズをFTP_PASSとして入力するか、更新をインストールする際に提示された資格情報フィールドの「パスワード」フィールドに入力する必要があります。

Alternative Cron

WPで代替のCronを使用する理由があるかもしれません。最も一般的には、スケジュールされた投稿が予想通りに公開されない場合に行われます。この代替方法はリダイレクションアプローチを使用します。ユーザーのブラウザは、cronが実行される必要があるときにリダイレクトされ、接続が切断された直後にサイトに戻ります。これは、ネイティブのWordPressサービスに依存しているため、特定のリスクがあります。 

  1. define( 'ALTERNATE_WP_CRON', true );

Disable Cron and Cron Timeout

DISABLE_WP_CRONをtrueに設定することで、cronを完全に無効にします。 

  1. define( 'DISABLE_WP_CRON', true );

WP_CRON_LOCK_TIMEOUT秒ごとにcronプロセスが1回以上実行されないようにしてください。 

  1. define( 'WP_CRON_LOCK_TIMEOUT', 60 );

Additional Defined Constants

ここに追加の定数を定義できます。これらは、他の方法が最初に試みられた場合にのみ設定すべきです。クッキーの定義は、異常なドメイン設定がある場合に特に便利です。 

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

Empty Trash

この定数は、WordPressがゴミ箱から投稿、ページ、添付ファイル、コメントを完全に削除するまでの日数を制御します。デフォルトは30日です: 

  1. define( 'EMPTY_TRASH_DAYS', 30 ); // 30 days

ゴミ箱を無効にするには、日数をゼロに設定します。 

  1. define( 'EMPTY_TRASH_DAYS', 0 ); // Zero days

注意: この設定を使用して「完全に削除」をクリックした場合、WordPressは確認を求めません。

自動データベース最適化

自動データベース修復サポートがあり、wp-config.phpファイルに次の定義を追加することで有効にできます。

注意: 必要な場合のみ有効にし、問題が解決したら無効にしてください。有効にすると、ユーザーは機能にアクセスするためにログインする必要がなくなります。これは、主に破損したデータベースを修復するためのものであり、データベースが破損しているときにユーザーがログインできないことがよくあるからです。 

  1. define( 'WP_ALLOW_REPAIR', true );

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

DO_NOT_UPGRADE_GLOBAL_TABLES

DO_NOT_UPGRADE_GLOBAL_TABLES定義は、dbDelta()およびアップグレード機能がグローバルテーブルに対して高コストのクエリを実行するのを防ぎます。

大規模なグローバルテーブル（特にユーザーおよびユーザーメタ）を持つサイトや、bbPressや他のWordPressインストールとユーザーテーブルを共有するサイトは、DO_NOT_UPGRADE_GLOBAL_TABLESをtrueに定義することで、アップグレード中にそれらのテーブルが変更されるのを防ぐことができます。ALTERや無制限のDELETEまたはUPDATEは完了するのに長い時間がかかる可能性があるため、大規模なサイトは通常、アップグレードの一部としてこれらが実行されるのを避けたいと考えています。さらに、複数のbbPressおよびWordPressインストール間でユーザーテーブルを共有している場合、1つのサイトをアップグレードマスターにしたい場合があります。 

  1. define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );

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

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

  1. print_r( @get_defined_constants() );

プラグインおよびテーマファイルエディタを無効にする

時折、過剰なユーザーが機密ファイルを編集してサイトをクラッシュさせるのを防ぐために、プラグインまたはテーマファイルエディタを無効にしたい場合があります。これを無効にすることで、ハッカーが特権のあるユーザーアカウントにアクセスした場合の追加のセキュリティ層も提供されます。 

  1. define( 'DISALLOW_FILE_EDIT', true );

注意: 一部のプラグインの機能は、コード内でcurrent_user_can('edit_plugins')を使用することによって影響を受ける可能性があります。プラグインの著者は、この機能をチェックすることを避けるべきであり、少なくともこの定数が設定されているかどうかを確認し、適切なエラーメッセージを表示するべきです。プラグインが機能していない場合、これが原因である可能性があることに注意してください。

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

これにより、ユーザーはWordPress管理エリアからプラグインおよびテーマのインストール/更新機能を使用できなくなります。この定数を設定すると、プラグインおよびテーマファイルエディタも無効になります（つまり、DISALLOW_FILE_MODSおよびDISALLOW_FILE_EDITを設定する必要はなく、DISALLOW_FILE_MODS単独で同じ効果があります）。 

  1. define( 'DISALLOW_FILE_MODS', true );

管理者およびログインにSSLを要求する

注意: WordPress バージョン 4.0ではFORCE_SSL_LOGINが非推奨になりました。FORCE_SSL_ADMINを使用してください。

FORCE_SSL_ADMINは、ログインと管理エリアを保護したい場合に使用します。これにより、パスワードとクッキーがクリアテキストで送信されることはありません。詳細については、Administration_Over_SSLを参照してください。 

  1. define( 'FORCE_SSL_ADMIN', true );

外部URLリクエストをブロックする

WP_HTTP_BLOCK_EXTERNALをtrueとして定義することで外部URLリクエストをブロックし、これによりlocalhostとあなたのブログのみがリクエストを行えるようになります。定数WP_ACCESSIBLE_HOSTSは、リクエストを通過させる追加のホストを許可します。WP_ACCESSIBLE_HOSTS定数の形式は、許可するホスト名のカンマ区切りリストであり、ワイルドカードドメインがサポートされています。例えば、*.wordpress.orgはwordpress.orgのすべてのサブドメインに連絡を許可します。 

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

WordPressの自動更新を無効にする

サイトが自動更新しない理由があるかもしれません。例えば、カスタマイズやホスト提供の更新などです。また、主要なリリースの前に、開発またはステージング環境でのテストのための時間を確保するために行うこともできます。 

  1. define( 'AUTOMATIC_UPDATER_DISABLED', true );

WordPressコアの更新を無効にする

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

  2. # すべてのコア更新を無効にする:
  4. define( 'WP_AUTO_UPDATE_CORE', false );
  5.  # すべてのコア更新を有効にする（マイナーおよびメジャーを含む）:
  6.  define( 'WP_AUTO_UPDATE_CORE', true );
  7.  # マイナーリリースのコア更新を有効にする（デフォルト）:
  8.  define( 'WP_AUTO_UPDATE_CORE', 'minor' );

参照: WordPress 3.7での自動更新の無効化

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

デフォルトでは、WordPressは画像を編集するたびに新しい画像セットを作成し、元の画像を復元すると、すべての編集がサーバーに残ります。IMAGE_EDIT_OVERWRITEをtrueとして定義することで、この動作が変更されます。画像編集のセットは1つだけ作成され、元の画像を復元すると、編集はサーバーから削除されます。 

  1. define( 'IMAGE_EDIT_OVERWRITE', true );

保存前にダブルチェック

入力した上記の値の前後にスペースがないか確認し、単一引用符を削除しないでください！

ファイルを保存する前に、パラメータ値の周りに単一引用符を誤って削除していないかダブルチェックしてください。ファイル内のPHPタグの閉じた後に何もないことを確認してください。ファイルの最後は?”>であり、他には何もありません。スペースもありません。

ファイルを保存するには、ファイル > 名前を付けて保存 > wp-config.phpを選択し、WordPressインストールのルートにファイルを保存します。ファイルをウェブサーバーにアップロードし、WordPressのインストールの準備が整いました！