wp-config.php

一時的な注意: これは簡単な部分へのリンクかもしれません。

• https://developer.wordpress.org/advanced-administration/wordpress/wp-config/

• https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
  

Advanced Options

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

table_prefix

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

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

$table_prefix = 'example123_'; // Only numbers, letters, and underscores please!

WP_SITEURL

WP_SITEURLは、WordPressアドレス（URL）を定義することを可能にします。定義された値は、WordPressコアファイルが存在するアドレスです。https://部分も含める必要があります。末尾にスラッシュ「**/**」を入れないでください。`````wp-config.php`````でこの値を設定すると、[wp_optionsテーブル](https://codex.wordpress.org/Database_Description#Table:_wp_options)の**siteurl**の値が上書きされます。これを追加することで、サイトを読み込む際のデータベース呼び出しの数を減らすことができます。**注意:** これはデータベースに保存された値を変更しません。この行がwp-configから削除されると、URLは古いデータベースの値に戻ります。RELOCATE定数を使用して、データベース内のsiteurlの値を変更します。

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

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

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

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

注意: HTTP_HOSTは、リクエストのHTTP HOSTヘッダーの値に基づいてPHPによって動的に作成されるため、ファイルインクルージョンの脆弱性を許可する可能性があります。SERVER_NAMEも動的に作成される場合があります。ただし、ApacheがUseCanonicalName「on」に設定されている場合、SERVER_NAMEはサーバーの設定によって設定され、動的には設定されません。その場合、HTTP_HOSTよりもSERVER_NAMEを使用する方が安全です。

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

Blog address (URL)

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

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

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

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

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

Moving wp-content folder

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

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

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

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

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

Moving plugin folder

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

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

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

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

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

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

Moving themes folder

テーマフォルダは、そのパスがwp-contentフォルダに対してハードコーディングされているため、移動できません:

$theme_root = WP_CONTENT_DIR . '/themes';

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

wp-contentフォルダを移動する方法については、詳細を参照してください。テーマフォルダがどのように決定されるかについての詳細はwp-includes/theme.phpを参照してください。

Moving uploads folder

UPLOADSを次のように設定します:

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

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

Modify AutoSave Interval

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

define( 'AUTOSAVE_INTERVAL', 180 ); // Seconds

Post Revisions

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

Disable Post Revisions

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

define( 'WP_POST_REVISIONS', false );

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

Specify the Number of Post Revisions

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

define( 'WP_POST_REVISIONS', 3 );

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

Set Cookie Domain

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

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

Enable Multisite / Network Ability

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

define( 'WP_ALLOW_MULTISITE', true );

Redirect Nonexistent Blogs

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

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

Fatal Error Handler

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

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

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

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

WP_DEBUG

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

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 and later
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値が返されます。

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

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やカスケーディングスタイルシートを変更する予定がある場合は、次のコードを設定ファイルに追加する必要があります:

define( 'SCRIPT_DEBUG', true );

Disable Javascript Concatenation

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

define( 'CONCATENATE_SCRIPTS', false );

Configure Error Logging

エラーロギングの設定は少し難しい場合があります。まず、デフォルトの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

エラーレポート4339について これは、サイトの機能に影響を与える問題のみをログに記録し、エラーでない可能性のある通知などは無視するカスタム値です。1000011110011の各バイナリ位置の意味についてはPHPエラー定数を参照してください。最も左の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_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 and later
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', true );

エラーロギングをオンにした場合は、後でファイルを削除することを忘れないでください。公開アクセス可能な場所にあることが多く、誰でもログにアクセスできる可能性があります。  
PHPのエラーロギングをオンにし、特定のファイルにログを記録する例です。WP_DEBUGがtrueに定義されている場合、エラーもこのファイルに保存されます。これは、*require_once*または*include*コマンドの上に配置してください。  
``````bash
@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がManchester WordPress User Groupで提案した洗練されたバージョン:

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

問題を混乱させるのは、WordPressには同じことをするように見える3つの定数があります。まず、WP_DEBUGがfalseの場合、それと他の2つのWordPress DEBUG定数は何も機能しません。PHPの指示は、何であれ優先されます。「error_reporting」を除いて、WordPressはこれをWP_DEBUGが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ファイルに以下を配置することを検討してください。部分的に冗長であるかもしれませんが:

@ini_set( 'log_errors', 'On' );
@ini_set( 'display_errors', 'Off' );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false ); // 5.2 and later
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経由でサーバーからログファイルを取得することで、常にログファイルを表示できます。

Increasing memory allocated to 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が割り当てられている場合、この値を64Mに設定する必要はありません。WordPressは必要に応じて自動的にすべての64MBを使用します。

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

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

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

PHPメモリを64MBに増加

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

PHPメモリを96MBに増加

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

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

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

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

Cache

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

define( 'WP_CACHE', true );

Custom User and Usermeta Tables

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

define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' );
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変数を変更するだけで済みます。元のインストールで既に使用されているメールアドレスを使用しないでください。設定プロセスが完了したら、自動生成された管理アカウントとパスワードでログインします。次に、通常のアカウントを管理者レベルに昇格させ、管理者からログアウトします。自分として再度ログインし、管理アカウントを削除し、必要に応じて他のユーザーアカウントを昇格させます。

Language and Language Directory

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

WordPress v3.9.6 and below

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

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

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

Save queries for analysis

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

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

define( 'SAVEQUERIES', true );

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

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

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

Override of default file permissions

FS_CHMOD_DIRおよびFS_CHMOD_FILEの定義文は、デフォルトのファイル権限を上書きすることを許可します。これら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 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のためではありません。

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の問題を回避するためにFTP_HOSTをlocalhostに設定する必要があります。

Enabling SSH Upgrade Access

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

最初は、SSH SFTP Updater Supportプラグインを使用することです。2つ目は、pecl SSH2拡張がインストールされている必要がある組み込みの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として入力するか、更新をインストールする際に提示された資格情報フィールドの「パスワード」フィールドに入力する必要があります。

Alternative Cron

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

define( 'ALTERNATE_WP_CRON', true );

Disable Cron and Cron Timeout

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

define( 'DISABLE_WP_CRON', true );

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

define( 'WP_CRON_LOCK_TIMEOUT', 60 );

Additional Defined Constants

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

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

Empty Trash

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

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

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

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

注意: この設定を使用して「完全に削除」をクリックした場合、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()およびアップグレード機能がグローバルテーブルに対して高コストのクエリを実行するのを防ぎます。

大規模なグローバルテーブル（特にユーザーおよびユーザーメタ）を持つサイトや、bbPressや他のWordPressインストールとユーザーテーブルを共有するサイトは、DO_NOT_UPGRADE_GLOBAL_TABLESをtrueに定義することで、アップグレード中にそれらのテーブルが変更されるのを防ぐことができます。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を要求する

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

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

define( 'FORCE_SSL_ADMIN', true );

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

WP_HTTP_BLOCK_EXTERNALを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コアの更新を無効にする

コアの更新を操作する最も簡単な方法は、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として定義することで、この動作を変更できます。画像編集のセットは1つだけ作成され、元の画像を復元すると、編集はサーバーから削除されます。

define( 'IMAGE_EDIT_OVERWRITE', true );

保存前にダブルチェック

上記の値の前後に余分なスペースがないか確認し、シングルクォートを削除しないでください！

ファイルを保存する前に、パラメータ値の周りにシングルクォートを誤って削除していないかダブルチェックしてください。ファイル内のPHPタグの閉じた後に何もないことを確認してください。ファイルの最後は**?

**であり、他には何もありません。スペースもありません。

ファイルを保存するには、**ファイル

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

変更履歴

• 2022-10-25: コンテンツとリンクを修正しました。
• 2022-09-04: wp-config.phpからの元のコンテンツ; チケットGithub。
• 2023-01-20: ドキュメントチケットGithubからのコンテンツを追加しました。