wp-config.php ファイルの開発者向け上級ガイド

公開: 2022-09-28

wp-configをどれだけ知っていますか? この数行の PHP には、驚くほどのパワーがあります。 この記事は、あなたが知らなかったかもしれないが、本当に知っておくべきwp-configの一部を紹介するツアーです。

wp-config.phpファイルについて知っておくべきことをすべて知っていますか? それに関するWordPressのドキュメントページ全体を読みましたか? 最後まで？

すでにwp-configの基本に精通している場合は、WordPress の公式ドキュメントを読むのが適切なスヌーズ フェストになるでしょう。

本当の開発者の扱い、件名ごとに適切にグループ化され、「いくつかの PHP 定数に対するまったく不必要な熱意」としか言いようのないものを提供したい場合は、そのままにしておいてくださいwp-config.phpを再びクールにしようとしています。

顔全体に「wp-config」と書かれた「シンプソンズ」のミルハウスと、「ママは私がクールだと言っている」というキャプション。

目次

  1. 誰が読むべきですか?
  2. これを読むべき理由
  3. 基礎
  4. wp-config 定数の表示
  5. wp-config.phpの読み込みプロセスの分析
    1. wp-config は上に移動できます
    2. wp-config.php ファイルがない場合にセットアップ画面が読み込まれる
    3. wp-config.php が非常に早く読み込まれる
    4. wp-config.php をいじらないでください!
  6. wp-config.php ファイルのチェック/リンティング
  7. wp-config.php で WordPress を保護する
    1. ウェブサイトの訪問者から wp-config.php を保護する
    2. ローテーション キー/ソルト
    3. 物の移動と非表示
    4. ファイル エディタの無効化
    5. 自動更新の無効化
    6. 外部 HTTP リクエストの防止
  8. 物の移動
    1. ユーザーおよびユーザーメタテーブルの移動
    2. コンテンツ、アップロード、およびプラグインのディレクトリを移動する
  9. コンテンツ関連の設定
    1. サイトとダッシュボードの URL を変更する
    2. 投稿設定
    3. リビジョンの投稿
    4. 自動保存間隔の変更
  10. まとめ

誰が読むべきですか?

この記事は、 wp-config.phpファイルの編集方法を既に知っていて、そこに入れることができるいくつかの構成設定を認識している開発者および上級ユーザーを対象としています。

FTP や cPanel を使用してファイルを編集する方法や、編集に MS Word を使用してはならない理由については説明しません。

データベースを構成する方法や、2013 年に使用していた従来の設定を変更する方法を説明するつもりはありませんが、実際にはもう必要ありません。 とにかく、ほとんどのホストが基本的なことをしてくれます。

wp-config.phpを初めて使用する場合は、基本を説明するガイドが不足することはありません。または、いつでも公式ドキュメントを掘り下げることができます。

これを読むべき理由

ええ、ええ、聞こえます。 この記事に記載できる内容の基本的な詳細がすべて別の場所でカバーされていて、ホストが基本的なことのほとんどを処理しているのであれば、なぜこれを読む必要があるのでしょうか? そして、実際、なぜ私はそれを書くのに時間を費やしているのでしょうか?

wp-config.phpの編集に満足していて、基本的な機能を知っているなら、おそらく少なくとも中級レベルの WordPress 開発者です。

あなたはおそらく、大規模なサイト (おそらくクライアント) のホスティングに少なくとも部分的に責任を負っています。 そのため、緊急時にこのファイルを使用する方法を知っておく必要があります。 そして、このファイルを十分に理解して、編集しても問題が起こらないようにする必要があります。

さらに、WordPress の特定の機能を、ホストが自動的に構成できる範囲を超えてロックダウンしたいと思うことはほぼ確実です。

wp-config.phpでできることさえ知らないことがあるかもしれません! いくつかの「あはは！」 持つべき瞬間。

この記事は、WordPress の内部構成の一部を構成するための便利なリファレンス ポイントです。 読んで、ブックマークして、友達や同僚と共有してください。

基礎

これは初心者向けの記事ではないと言いましたが、同じ出発点にいることを確認するために基本的な事実を確立する必要があります。

wp-config.phpファイルは、WordPress インストールのルートに存在し (他の場所に存在することもできますが、それについて説明します)、WordPress の初期化の一部としてロードされ、WordPress コアを構成できるようにします。

WordPress の実行に不可欠です。 以下を指定できる一連の定数が格納されます。

  • WordPress が使用するデータベース接続とテーブルプレフィックス。
  • ソルトや認証キーなどのセキュリティ情報。
  • WP_CACHEやWP_DEBUGなど、WordPress コアの他の機能の設定。
  • ファイルに独自のオプションを追加できるプラグインの設定。
  • 独自の構成オプション。

重要なのは、 wp-config.phpが環境固有のファイルであることです。 その内容は、サイトごとに異なる可能性があります (そうあるべきです!)。 同じサイトのローカル コピー、ステージング コピー、およびライブ コピーでも、ファイル内の値は異なります。

WordPress にはwp-config-sample.phpファイルが付属しており、WordPress が機能するために必要な最小限の詳細が含まれています。 これをインストールの一部として自分のwp-config.phpにコピーすることもできますが、最近では通常は自動的に行われます。

最後に、既存のサイトからwp-config.phpファイルを開くと、デフォルトのファイル許可やアップグレードを実行するための FTP 資格情報などのレガシー機能の古い PHP 定数が表示される可能性があることに注意してください。 それらを使用する必要はほとんどないため、ここでは説明しません。

wp-config 定数の表示

リモートサーバーに SSH 接続してファイルを開くことなく、WordPress 定数の値をすばやく確認する方法がいくつかあります。

WordPress コアのサイト ヘルス機能では、[ツール] -> [サイトのヘルス] -> [情報] -> [WordPress 定数] に移動して、いくつかの基本的な値を表示できます。 データベース定数は、同じページの「データベース」セクションにも表示されます。

WordPress サイトヘルスページのデータベースセクションに表示されているデータベース定数。

Query Monitor プラグインには「環境」パネルがあり、一般的に使用されるwp-config定数を確認できます。

Query Monitor プラグインの「環境」パネル。一般的に使用される wp-config 定数がいくつか表示されています。

WordPress コマンドライン インターフェイスである WP-CLI には、 wp-config.phpで定数を取得および設定するために使用できるwp configコマンドがあります。 これには通常、最初に SSH を実行する必要がありますが、WP-CLI 構成でエイリアスを設定すると、リモートwp-configファイルの定数を表示および変更するためのクイック ショートカットを作成できます。

wp-config.phpの読み込みプロセスの分析

wp-config.phpファイルがいつ読み込まれるかを知っておくと便利です。これにより、できることとできないことが決まります。 読み込みプロセスをトレースするのは良い練習です:

  • WordPress はindex.phpファイルの読み込みを開始します。 これにはwp-blog-header.phpファイルが必要です。

  • wp-blog-header.phpが最初に行うのは、 wp-load.phpロードです。

  • 次に、 wp-load.phpは ABSPATH 定数 (ベースの WordPress コア ディレクトリ) を設定し、 wp-config.phpをロードする前にerror_reporting()を初期化します。

このロード プロセス、特にwp-load.phpのコードは、いくつかの興味深いことを教えてくれます。 そのコードは次のとおりです。

 /* * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit * of avoiding cases where the current directory is a nested installation, eg / is WordPress(a) * and /blog/ is WordPress(b). * * If neither set of conditions is true, initiate loading the setup process. */ if ( file_exists( ABSPATH . 'wp-config.php' ) ) { /** The config file resides in ABSPATH */ require_once ABSPATH . 'wp-config.php'; } elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) { /** The config file resides one level above ABSPATH but is not part of another installation */ require_once dirname( ABSPATH ) . '/wp-config.php'; } else { // A config file doesn't exist. // [Code here to load the setup screen for in-browser configuration] }

ここで何が見えますか？

wp-config.php は上に移動できます

まず、コメントは、 wp-config.phpを「WordPress ルート」に配置できることを示しています。 言及されていないのは、「ルート」が実際にはwp-load.phpが存在するABSPATHの上のディレクトリである可能性があるということです。

この追加のチェックは、 dirname( ABSPATH ) . '/wp-config.php'を検索するelseifで確認できます。 dirname( ABSPATH ) . '/wp-config.php' . elseifの追加条件は、コメントで説明されています。

wp-config.php ファイルがない場合にセットアップ画面が読み込まれる

次に、構成ファイルが存在しない場合は、セットアップ画面が読み込まれることがわかります。

この画面を見たことがない可能性は十分にあります。 Web ベースのユーザー インターフェイスで、データベースの資格情報などの初期構成情報を入力できます。

めったに見られないWordPressのセットアップ画面。構成ファイルが見つからない場合、WordPress はこれをロードし、構成オプションを手動で設定できるようにします。

これは、知っておく価値のある WordPress の機能です。 WordPress のコア ファイルを公開されている Web サーバーに配置したことがあるが、 wp-config.phpファイルを作成していない場合は、他の誰か (またはボット) がやって来て、WordPressを自分のやり方でセットアップできます。ホスティングを危険にさらす可能性があります。

wp-config.php が非常に早く読み込まれる

3 つ目の注意点は、 wp-config.phpが WordPress の起動シーケンスの非常に早い段階で読み込まれることです。 この意味は：

  1. wp-config.phpではできないことがたくさんあります。 たとえば、ここにフック (アクションまたはフィルター) を追加することはできません。これを行うための関数とデータ構造がまだ読み込まれていないためです。 また、WordPress の内部関数、オブジェクト、および API のいずれにもアクセスできません。

  2. 私たちは、次に何が起こるかについて多くのことをコントロールできます。 ファイルは非常に早く読み込まれるため、WordPress に大きな影響を与えます。 これは良いことでもあり悪いことでもあります。 WordPress を完全に死なせるのは簡単です。 しかし、WordPress のどこからでもwp-config.phpで定義されているものにアクセスできます。

wp-config.php をいじらないでください!

このプロセスから最後に学べることは、この大きな力には大きな責任が伴うということです。

wp-config.phpファイルの下部には、次の行があります。

 /* Add any custom values between this line and the "stop editing" line. */ /* That's all, stop editing! Happy publishing. */ /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php';

ここにいくつかの指示がありますが、「編集を停止する」という行が重要です。 この行の後は、WordPress の初期化シーケンスの続きです。 間違った場所に新しいコードを追加すると、おそらく新しいコードはまったく効果がなくなります。 ただし、安全のために、次の手順に従うことをお勧めします。 彼らは正当な理由でそこにいます。

wp-config.php ファイルのチェック/リンティング

本番環境で作業している場合、 wp-config.phpファイルにエラーを入れたくないでしょう。 ここでエラーが発生すると、Web サイトが破損する可能性があり、エラーが発生したときに有用なエラー メッセージが表示されない場合があります。

コマンド ラインで-l (「lint」) オプションを指定してphpを実行すると、 wp-config.phpファイルに重大な PHP 構文エラーがないかどうかを確認できます。

$ php -l wp-config.php

解析エラー: 構文エラー、行 9 の wp-config.php の予期しないトークン「require_once」

wp-config.php の解析エラー

シェルスクリプトを書いて…

  1. wp-config.phpを一時ファイルにコピーし、
  2. 一時ファイルを編集し、
  3. 一時ファイルをリントし、
  4. 構文エラーがない場合にのみ、コピーして戻します。

コマンドラインに満足している場合は、手動で行うよりもwp config set <name> <value>などの WP-CLI コマンドを使用して値を安全に設定する方が安全です。

WP-CLI を使用して構成値を一覧表示することもできます (これはいくつかのエントリを削除したサンプルです。おわかりいただけると思います!):

$ wp 設定リスト
+---------------------+--------------------------- ------+----------------------+
| | 名前 | 値 | タイプ |
+---------------------+--------------------------- ------+----------------------+
| | root_dir | /Users/smithers/sites/snpp | 変数 |
| | webroot_dir | /Users/smithers/sites/snpp/public | 変数 |
| | table_prefix | wp_ | 変数 |
| | WP_HOME | https://snpp.test | 定数 |
| | WP_SITEURL | https://snpp.test/ | 定数 |
| | DB_NAME | スナップ | 定数 |
| | DB_USER | ルート | 定数 |
| | DB_PASSWORD | モンゴメリー | 定数 |
| | DB_HOST | 127.0.0.1 | 定数 |
| | DB_CHARSET | utf8mb4 | 定数 |
| | DB_COLLATE | | | 定数 |
| | DB_PREFIX | wp_ | 定数 |
| | WP_DEBUG | 1 | 定数 |
| | WP_DEBUG_LOG | 1 | 定数 |
| | WP_DEBUG_DISPLAY | | | 定数 |
| | WP_ENVIRONMENT_TYPE | 開発 | 定数 |
| | DISABLE_WP_CRON | | | 定数 |
| | DISALLOW_FILE_EDIT | 1 | 定数 |
+---------------------+--------------------------- ------+----------------------+

これらの 2 つの手法を使用すると、面倒な作業が大幅に軽減され、このような重要なファイルの間違った場所に誤ってセミコロンを挿入してしまう心配をなくすことができます。

wp-config.php で WordPress を保護する

セキュリティは、WordPress で常にホットなトピックです。 wp-configファイルで変更できる一部の設定により、セキュリティ ツールボックスに追加のツールが追加されます。

wp-configファイルのこれらの部分は、WordPress の優れたセキュリティを実現するために使用する必要がある唯一のものではありません。 次のセクションの情報に加えて、Web サイトのセキュリティを完全に理解していることを確認してください。

ウェブサイトの訪問者から wp-config.php を保護する

wp-configファイルはデフォルトで Web サイトのルート ディレクトリにあり、データベースのログイン情報やパスワード ソルトなどの重要な情報が含まれています。 この情報を公開したくないので、 wp-configファイルが Web サイトの訪問者から保護されていることを確認する必要があります。

多くの場合、ホスティング会社がこれを行います。 ドメインの直後に/wp-config.phpを追加して、ブラウザーからファイルにアクセスすることで確認できます。 ファイルを移動した場合、この URL は異なる場合があります。

Web サイトのルート ディレクトリの上のディレクトリにwp-configファイルを配置した場合、それは表示されないはずです。 他のほとんどの場合、ファイルにアクセスしようとすると PHP エラー メッセージが表示されるだけなので、通常は何もする必要はありません。 ただし、適切に保護したい場合は、Web サーバー (Apache または nginx) の構成を変更してアクセスをブロックすることで実現できます。

最後に、Web サイトのファイルを Git に保存する場合は、 wp-configファイルを Git リポジトリに保存しないことが重要です。 これを行うと、サイトに関する重要な情報が漏洩する可能性がありますが、さらに、環境ごとに異なるバージョンのこのファイルが必要になることもあります。 そのため、 .gitignoreに追加して、各環境で手動でファイルを管理することをお勧めします。

ローテーション キー/ソルト

キー/ソルトとは何ですか?

キーとソルトのセクションは、 wp-configの謎めいた部分の 1 つです。 この奇妙に見える定数のセットは、Cookie やノンスなどの暗号化に役立ちます。 WP Engine のように詳細に入ることなく、ソルトとキーがわからない場合に復号化を困難にするランダム性の層が追加されます。

キー/ソルトを「ローテーション」するのはなぜですか?

まず、「回転」は「変化」を意味する派手な言葉です。 「回転」を使用する理由がわかりません。 同じキーセットに戻ることはありません。

キーとソルトがまだ秘密であることを保証できないため、サイトがハッキングされた場合は、おそらくキーとソルトを変更する必要があります。 ただし、パスワードのように定期的にローテーションして、誰にもわからないようにすることもできます。

キー/ソルトのローテーションの問題

キーとソルトを変更するのに苦労がないわけではありません。 Cookie セットを持っている人は誰でもそれを失います。 したがって、ログインしている人は誰でも追い出され、WooCommerce カートを持っている人は誰でもカートを空にすることができます。

キー/ソルトをローテーションする方法

つまり、 wp-configファイルを編集して、古い文字の上に新しいランダムな文字を入力するだけです。 しかし、これは退屈で、人間はランダム性があまり得意ではありません。

wp-configで新しいキー/ソルトを設定するいくつかの方法についてお話ししましょう。

  1. ジェネレーターからキーを手動で追加する: wordpress.org ジェネレーターを使用して、必要なコードを取得できます。 古い値の代わりにwp-configファイルにコピー アンド ペーストするだけです。
  2. プラグインを使用する: Sucuri Security、iThemes Security、Malcare などの多くのセキュリティ プラグインにはすべてこの機能があります。 また、Salt Shaker は、スケジュールに従ってこのプロセスを自動化する専用のプラグインです。
  3. WP-CLI を使用します。 WP-CLI がどれほど優れているか、もう言いましたか? やった？ わかった。 さて、もう一度言います！ また、 wp config shuffle-saltsコマンドを使用して、このジョブを数秒で実行できます。

物の移動と非表示

セキュリティ担当者は、「あいまいなセキュリティ」はまったくセキュリティではないと言いますが、WordPress のものを隠して、ハッカーに対する追加の障壁を設けるのを好む人もいます.

wp-configファイルには、これを行うための多くのオプションが用意されています。これらについては、後のセクションで移動とファイル編集の無効化について説明します。

ファイル エディタの無効化

WordPress には、管理ダッシュボード内からテーマやプラグインのファイルを編集できる便利な機能があります。 wp-config.phpを編集すると、これらのファイル エディターをオフにできます。 一部の人々は、安心のためにそれらを無効にすることを好みます。

誰かがあなたのサイトへの管理者アクセス権 (これらのエディターを使用するために必要) を持っていれば、プラグインをアップロードして好きなことを何でもできるというセキュリティ上の議論があることを今私は知っています。 これらのエディターを有効にしても、ハッカーがすでに持っている以上の力を提供することにはなりません。

ただし、これらをオフにしてもセキュリティが実際に向上するわけではありませんが、これを行う本当の理由は、実際に管理者として承認されているユーザーがそれらを使用できないようにするためです。 あなたがエージェンシーであれば、おそらくクライアントにすべてのテーマ ファイルを編集できることを知られたくないでしょう。

多くのホストは、デフォルトでこの機能を無効にします。 しかし、それらを消したい場合は、以下を追加するのと同じくらい簡単です:

 define( 'DISALLOW_FILE_EDIT', true );

または、ファイルシステムを本当にロックダウンしたい場合は、次のセクションで説明するDISALLOW_FILE_MODSがあります。

自動更新の無効化

好きか嫌いかに関係なく、WordPress の自動更新は WordPress のエコシステムにプラスの影響を与えており、無視することはできません。 しかし、誰もが自分のソフトウェアが自動的に処理されることを望んでいるわけではありません!

したがって、 wp-configを使用すると、設定可能なわかりやすい定数のセットを使用して、自動更新プロセスを制御できます。

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

もっと極端なものが必要な場合は、 DISALLOW_FILE_MODSを実行できます。

 define( 'DISALLOW_FILE_MODS', true );

ただし、これにより、WordPress はコア、テーマ、プラグイン、または翻訳に関連するディスクへの書き込みを停止し、マイナー アップデートに関するメール通知を無効にします。 中心的な貢献者は、「自分が何をしているのかを正確に理解していない限り、使うのは馬鹿げている」と説明しています。

AUTOMATIC_UPDATER_DISABLEDは、それほど極端ではありません。 これにより、プラグインとテーマをインストールできますが、それらやコア ソフトウェアは更新されません。 ただし、翻訳の更新も無効にします。

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

wordpress.org には、これらすべてに関する詳細なガイドがあり、フィルターを使用してよりきめ細かい制御を行うなどの他のオプションも含まれています。

最後に、サイトがバージョン管理されている場合、WordPress が更新を無効にしている可能性が高いことに注意してください。 たとえば、サイトのルート (またはさまざまな場所にあるさまざまな他のファイル) に.gitディレクトリが存在すると、 wp-configに何も追加しなくても自動更新が無効になります。

HTTPS の設定

HTTPS の構成は、しばしば困難でした。 LetsEncrypt や Cloudflare などの無料の信頼できるセキュリティ証明書の出現により、多くのホストが数回クリックするだけでこれを設定します. この設定はおそらくレガシーと見なされるべきですが、何かのためにまだ必要な場合があります。

FORCE_SSL_ADMIN定数は、ログイン ページと WordPress ダッシュボードに常にSSL を使用するように WordPress に指示します。 これにより、安全な資格情報と Cookie を暗号化せずに送信できないことが保証されます。

しかし、私が言ったように、優れたホスティング会社はサイトでの HTTPS の設定をとにかく簡単にしてくれるので、それを実行してください。

外部 HTTP リクエストの防止

最後に、セキュリティでは、外部 HTTP リクエストをブロックできます。 これは、WordPress がインターネット上の他の場所にアクセスして、API 呼び出しや更新のダウンロードなどを行うことができないことを意味します。

WordPress が HTTP 経由で外部サービスに接続できるようにすることは、更新を取得したり、プラグインやテーマをインストールしたり、HTTP リクエストをオフにすると多くのプラグインが壊れたりするため、一般的には良い考えです。

しかし、WordPress コアと多くのプラグインとテーマは、「テレメトリ」または「使用状況データ」を中央サーバーに送り返します。 これは良いことです。プラグインとテーマの開発者が、誰がどのようにソフトウェアを使用しているかを知るのに役立ちます。 ただし、特に機密データを含むサイトがある場合は、これを無効にすることをお勧めします。 そして、あなたはそれを行うことができます:

 define( 'WP_HTTP_BLOCK_EXTERNAL', true );

接続できるホストの許可リストが必要な場合は、それも実行できます。

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

アクセス可能なホストのリストはコンマ区切りのリストであり、ワイルドカード サブドメインが許可されていることに注意してください。 また、Log HTTP Requests プラグインを使用して、どのホストが接続されているかを監視できます。

物の移動

すべての WordPress インストールが同じというわけではありません。 一部のホストやフレームワークは、セキュリティ上の理由からディレクトリを移動したり、サイト固有のコードやアセットを WordPress コアから分離したりすることを好みます。 Git と Composer を使用して WordPress を管理するという私の記事では、このアプローチの利点について説明しています。

では、WordPress は、より適切な用語が必要な場合に、「動くもの」に対してどのようなオプションを提供するのでしょうか?

データベース接頭辞の変更

WordPress はデフォルトでデータベーステーブル名の接頭辞wp_を使用します。 このプレフィックスは、すべてのデータベース テーブル名に追加され、オプション テーブルの<prefix>user_rolesオプションや<prefix>capabilitiesユーザー メタ エントリなど、他の場所でも使用されます。

ハッカーまたは攻撃者は、攻撃にデフォルトのプレフィックスを使用して、データベース テーブルを検出または変更しようとする可能性があります。 そのため、デフォルトから変更することを推奨する人もいます。

wp_configオプションの$table_prefixを使用すると、これを行うことができます。おそらく、短いがランダムな文字列に設定し、末尾にアンダースコアを付ける必要があります。

 $table_prefix = 'b4F8az_';

これにより、WordPress はb4F8az_postsの代わりにwp_postsなどのテーブル名を使用するようになります。

この変更に対応するためにコードを更新する必要はありませんが (コードの記述が非常に悪い場合を除きます)、既存のサイトでこれを変更する場合は、名前を変更するだけでなく、データベースを更新する必要があります。テーブル！

一部のセキュリティ プラグインはこれを行います。また、これを行うことができるプラグインもあります。 これを行う前に、データベースのバックアップを作成することを強くお勧めします。デフォルト以外のテーブル プレフィックスを選択するのは、サイトの進行中に変更するときではなく、WordPress をインストールするときに行うのが最適です。

これに関する興味深い注意点は、 $table_prefixが定数ではなく変数であることです。 これは、WordPress が提供するサンプル構成ファイルで定義されている唯一の変数です! それでも興味がある場合: はい、WP-CLI のwp configコマンドは、あなたが知らなくても、これを処理してくれます!

ユーザーおよびユーザーメタテーブルの移動

私はこれが行われたのを見たことがなく、この記事を書いているときにそれが可能であることを知りましたが、user テーブルと usermeta テーブルの名前を完全に変更することもできます。

これは、「SELECT * FROM wp_usermeta;」を試みる SQL インジェクション攻撃を防ぐのに役立つと思いますが、そうする他の理由を聞いてうれしく思います。

いずれにせよ、 CUSTOM_USER_TABLEおよびCUSTOM_USER_META_TABLE定数が必要です。

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

これらの定数を使用する前に知っておく価値のある警告がいくつかあります。 この機能を使用する前に、公式ドキュメントを確認してください。 また、カスタム テーブル プレフィックスを使用する場合と同様に、後で変更するよりも、新しいサイトをインストールするときにこれを行うのが最適です。

コンテンツ、アップロード、およびプラグインのディレクトリを移動する

wp-contentディレクトリ全体、 uploadsディレクトリ、 themesおよびpluginsディレクトリを移動することもできます。 注意事項:

  • これらのケースのいくつかでは、ディレクトリだけでなく URL も設定する必要があります。
  • 必要に応じて完全パスまたは相対パスを使用するように注意する必要があります。
  • これらの設定には、末尾にスラッシュを付けないでください。

詳細については、公式ドキュメントを参照してください。ここではそのすべてを繰り返しません。

最後に、不適切にコーディングされたプラグインまたはテーマは、これらを変更すると混乱する可能性があることに注意してください。 これは決して起こるべきではありませんが、知っておく価値があります。

プラグインまたはテーマの開発者は、これらのパスが変更される可能性があることを覚えておくことが重要です。 そのため、ディレクトリや URL へのパスをハードコーディングしないでください。 ここで役立つ機能は次のとおりです。

wp_upload_dir
plugins_url
plugin_dir_url
plugin_dir_path
get_stylesheet_directory
get_stylesheet_directory_uri
get_template_directory – 子テーマの場合、これは親テーマの場所を返すことに注意してください
get_template_directory_uri

WordPress 開発者ハンドブックには、このような関数の完全なリストがあります。

最後に、WordPress インストール内でファイルを移動するだけでなく、wp-admin の場所を移動したり、サイトの場所を変更したりすることもできます。 そしてwp-config.phpもそれを助けることができます。

コンテンツ関連の設定

結局のところ、WordPress はコンテンツ管理システムです。 そのため、 wp-config.phpでコンテンツ オプションを制御するために使用できるいくつかの定数を期待できます。 何ができるか見てみましょう。

サイトとダッシュボードの URL を変更する

これらはいつも私を混乱させてきました。

サイトの URL を設定するには、 WP_SITEURL WP_HOMEを使用する必要があります。

WP_SITEURL定数はサイトの URL を変更しません。

混乱している？

WP_SITEURLが行うことの公式な説明は、「WordPress コア ファイルが存在するアドレス」です。 これも、ディレクトリではなく URL であるため、混乱を招きます。

これについて私を責めないでください、私はその日のツアーガイドです！

WP_HOMEとWP_SITEURLを設定すると、 wp_optionsデータベース テーブルのhomeとsiteurlエントリが上書きされます。 少なくとも、それは理にかなっています。

 // NOTE: These must not have trailing slashes define( 'WP_HOME', 'https://helfish.media' ); define( 'WP_SITEURL', 'https://hellfish.media/wordpress` );

サイトを新しい URL に移動した後、これらの定数を使用して、データベースを適切に修正しながらサイトを稼働させることができます。 後でそれらをそのままにしておくこともできます。

WP_SITEURL設定は、コア WordPress ファイルを別のディレクトリに移動した場合にも使用できます。

これらを使用すると、オプション テーブルから値を取得するためにデータベース クエリが 1 つまたは 2 つ実行されるのを防ぐこともできるため、パフォーマンスがわずかに向上する可能性があります。 ただし、オブジェクト キャッシングを行っている場合、そのゲインはおそらく無視できます。

公式ドキュメントにはさらに詳細が記載されており、サイト URL の変更に関する完全なサポート記事もあります。 さらに、その記事には、この記事を調査するまで聞いたことのないwp-config.phpのあいまいなRELOCATE定数が含まれています。

最後に、サイトを移動するときは、変更する必要があるのはこれだけではないことに注意してください。 URL 文字列をデータベース全体で検索して置換することをお勧めします。

投稿設定

投稿に関しては、いくつかの異なる設定を変更できます。 これらのほとんどは、リビジョンの投稿または自動保存機能に関係しています。

リビジョンの投稿

WordPress のデフォルトの動作は、投稿とページに加えられたすべての変更を保存することです。 これの利点は、以前のバージョンに簡単に戻せることです。 欠点は、これらすべてのリビジョンがデータベースのスペースを占有し、データベース クエリの速度が低下してサイトのパフォーマンスに影響を与える可能性があることです。

wp-config.phpファイルのWP_POST_REVISIONS値を変更することで、投稿リビジョンを完全に無効にすることができます。 デフォルトは true です。 リビジョンを無効にするには、代わりに false に設定します。

 define( 'WP_POST_REVISIONS', false );:

WP Engine を含む一部のホストは、デフォルトで投稿リビジョンを無効にします。 変更を加える前に、ホスティング プロバイダーに確認することをお勧めします。 これはホストごとに異なりますが、WP Engine を使用している場合は、サーバー レベルで上書きされるため、 wp-configでリビジョンを有効にすることはできません。

ホストがこれを制御していて、それを変更しようとすると、必ずしも何かが壊れるわけではありませんが、時間を無駄にしている可能性があります。

リビジョンの投稿によってデータベース クエリが遅くなることが懸念される場合は、WordPress が保存するリビジョンの数を制限することをお勧めします。 これは、保持したいリビジョンの最大数に設定できるWP_POST_REVISIONS定数によって制御されます。

 define( 'WP_POST_REVISIONS', 5 );

自動保存間隔の変更

自動保存が開始される頻度を減らすこともできます。 これはデフォルトで 60 秒ごとに設定されていますが、任意に変更できます。 偏執狂的な人は、代わりにこれを 20 秒または 30 秒に設定することをお勧めします。

自動保存にかかる時間に注意することが重要です。 頻繁に発生させてオーバーラップさせたくないので、この値をたとえば 1 秒に設定しないでください。 自動保存にデフォルトの 60 秒以上かかることはあまりありませんが、リクエストを保存したい場合は間隔を長くすることができます:

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

まとめ

ロックが解除されるのを待っているwp-configには多くの可能性があります。 このツアーが、可能性のほんの一部を強調するのに役立つことを願っています. 今後の記事では、マルチサイト インストールやデバッグなど、 wp-configに固有の高度な機能について詳しく説明します。 また、メモリ制限の調整方法、CRON の問題、環境の種類など、パフォーマンスについても調べます。

公式文書には、発見されるのを待っている他の宝物が潜んでいることに疑いの余地はありません。 wp-configを使用する際に見つけたヒントは何ですか? コメントで教えてください。