すべてのWordPressサイト運営者が知っておくべきwp-config.phpファイルの設定

WordPressサイトを新しいホスティングプロバイダーに移行したばかりです。移行中はすべて順調に進んだようでした。

すると、ホームページにアクセスした際に、データベース接続エラーが表示されます。

幸いなことに、ほとんどの場合、このエラーは対処が必要な特定のファイル、つまり wp-config.php を指しています。

wp-config.php ファイルは、WordPress の制御センターです。このファイルには、サイトの動作に必要なデータベースの認証情報に加え、セキュリティキー、デバッグ設定、その他の主要な設定が格納されています。

ホストを移行したり、データベースの詳細を変更したりする場合は、新しい環境に合わせてこのファイルを更新する必要があります。

この重要なファイルを自信を持って扱えるようになるために、以下の内容について解説します：

• wp-config.php ファイルの場所と、安全にアクセスするための最適な方法
• サイトの稼働を維持するために不可欠なデータベース設定とセキュリティ設定
• cPanelのファイルマネージャーまたはFTPクライアントを使用してファイルを編集するための明確な手順
• 接続エラーや機能の不具合を防ぐ、移行に伴う変更点
• 編集に失敗してサイトが表示されなくなった場合の復旧策

目次

これら4つの情報が欠けている場合（またはそのいずれかが間違っている場合）、WordPressはデータベースから投稿、ページ、設定を取得することができません。

このファイルには、ユーザー固有のセキュリティキー、サイトのURL設定、デバッグ設定、およびメモリ制限も含まれています。

テーマファイルやプラグインファイル、さらにはアップロードしたコンテンツでさえ、一時的に欠落していても、サイトが完全に機能しなくなることはありません。しかし、wp-config.phpはどうでしょうか？これが破損していたり、欠落していたり、誤った情報が含まれていたりすると、サイト全体がコンテンツの代わりにエラーメッセージを表示してしまいます。

セキュリティを重視するユーザーの中には、wp-config.php を WordPress のルートディレクトリから 1 階層上に移動させる人もいます。これにより、機密性の高いデータベースの認証情報が、Web からアクセス可能なフォルダ構造の外側に配置されます。WordPress は、通常配置されている場所に見つからない場合、自動的にその親ディレクトリを確認するようになっています。

wp-config.php がどこにも見つからない？まずはファイルマネージャーの表示設定を確認してみてください。

一部のFTPクライアントやホスティングパネルでは、特定の文字で始まるファイルがデフォルトで非表示になっています。クライアントの表示設定で「隠しファイルを表示」に設定する必要があります。

そのファイルが本当に存在しない場合、誤って削除されたか、転送中に破損した可能性があります。その場合は、最近のバックアップから復元するか、WordPressのインストール時に同梱されている「wp-config-sample.php」テンプレートを使用して手動で作成し直す必要があります。

サイト運営者が知っておくべきwp-config.phpの基本設定

これらの wp-config.php の設定は、WordPress サイトが安全に機能するか、あるいはそもそも機能するかどうかを左右します。

データベース接続情報

WordPressはページを読み込む際、まず最初にデータベースの認証情報を確認します。

• DB_NAME は、コンテンツが格納されているデータベースを WordPress に指定します。
• DB_USER と DB_PASSWORD は、アクセス用の認証情報を指定します。
• DB_HOST は、データベースサーバーの場所を指します。

データベース接続エラーが発生した場合は、通常、以下の4つの値のうちいずれかが間違っています。

認証キーとソルト

認証キーとソルトは、WordPressがユーザーのパスワードやログインセッションを暗号化する際に、ランダム性を加える役割を果たします。ユーザーがサイトにログインすると、WordPressはこれらの文字列を使用して、そのユーザーの身元を確認するための固有の暗号化されたCookieを作成します。

適切な鍵がなければ、ログインシステムは予測可能になり、攻撃者がブルートフォース攻撃やセッションハイジャックを利用して悪用できるようになります。

データベーステーブルのプレフィックス

WordPressではプレフィックスを使用します wp_ すべてのデータベーステーブル名に対してデフォルトで設定されます。投稿は wp_posts、以下の選択肢があります wp_options、およびユーザーデータは wp_users. この標準的な命名規則により、WordPressの動作が予測可能になりますが、これは利便性をもたらす一方で、セキュリティ上の懸念も生じさせます。

一部のサイト運営者 テーブルのプレフィックスを変更する 次のようなものに abc123_ または mysite_ インストール中に。その考え方は妥当です。自動化された攻撃は、多くの場合、標準的なWordPressのテーブル名を標的にしてSQLインジェクションを試みます。もしテーブル名が xyz_posts の代わりに wp_posts、通常攻撃は即座に失敗する。

デバッグ設定

WP_DEBUG wp-config.php 内の簡単な true/false 設定により、エラーの表示/非表示を制御します。

これを設定する trueまた、WordPressはサイトのページ上に直接エラーメッセージを表示します。赤い警告テキストや致命的なエラーの詳細、対処が必要な古いコードに関する通知が表示されます。

ただし、決して放置しないでください WP_DEBUG 本番環境でこのモードが有効になっている場合、エラーが発生した際にサイトを訪問したユーザーに、サーバーの設定、ファイルのパス、データベースの構造といった機密情報が漏洩する恐れがあります。

WP_DEBUG_LOG 本番環境向けのより安全な代替手段を提供します。この設定により、 /wp-content/debug.log メッセージを一般に公開する代わりに。訪問者に技術的な詳細をさらすことなく、必要な診断情報を得ることができます。

絶対パス

WordPressは、サーバー上のどこに配置されているかを正確に把握する必要があります。そこで ABSPATH ここで登場するのがこの定数です。この定数は、WordPressのインストール先への完全なサーバーパスを定義するものです。これは、訪問者が目にするWeb上のURLではなく、ホスティングサーバー上の実際のフォルダ構造を指します。

一般的な共有ホスティングでは、 ABSPATH どうやら /home/ユーザー名/public_html/ または /home/username/public_html/blog/ もし WordPressはサブディレクトリ内に配置されています.

WindowsではC:\xampp\htdocs\mysite\、Macでは /Applications/MAMP/htdocs/mysite/といったパスがローカルの開発環境で表示されます。

WordPressは、URLの構成やサイトがどのディレクトリから動作しているかに関係なく、この絶対パス情報を使用してファイルを確実に特定します。WordPressがテーマファイルをインクルードしたり、プラグインを読み込んだり、アップロードされたメディアにアクセスしたりする必要がある場合、以下の方法を使用して完全なファイルパスを構築します。 ABSPATH を出発点として。

wp-config.php ファイルの編集方法

ウェブサイト上の wp-config.php ファイルを編集する方法をご説明します。

ウェブサイトのバックアップ

経験から学んだことですが、wp-config.php を編集する前に、必ずサイトのバックアップを取るべきです。

wp-config.php は PHP の構文を使用しており、PHP はミスを一切許しません。セミコロンが1つ抜けていたり、引用符が1つ余っていたり、文字が1つでも間違っていると、致命的なエラーが発生し、サイト全体がダウンしてしまいます。

テーマやプラグインの不具合とは異なり、wp-config.phpのエラーが発生すると、WordPressがまったく読み込まれなくなります。

FileZillaなどのFTPクライアントを使用している場合は、ファイルを右クリックして「ダウンロード」を選択してください。

cPanelのファイルマネージャーも同様の操作です。wp-config.phpファイルを見つけて右クリックし、「ダウンロード」を選択してください。

より簡単な復元方法として、Duplicatorを使用してサイト全体のバックアップを作成してください。破損を防ぐため、クラウドに保存することをお勧めします。

万が一問題が発生した場合は、管理ダッシュボードでそのバックアップを見つけて、「復元」をクリックしてください。

さらに深刻なエラーが発生した場合は、バックアップファイルとインストーラーファイルをサイトのルートディレクトリに再アップロードしてください。以下のURLから復元を実行してください：https://your-domain/installer.php

Duplicatorは、サイトが完全にダウンしていても復元します！

FTPを使って wp-config.php を編集する

cPanelが利用できない場合や、デスクトップソフトウェアでの操作を希望する場合、FTPを使用すればサーバーに直接アクセスしてwp-config.phpを編集することができます。

ホスティングアカウントのコントロールパネル（通常は「FTPアカウント」セクション）で、FTPの認証情報を確認してください。ホスト名（多くの場合、ドメイン名または「ftp.yourdomain.com」）、ユーザー名、パスワードが必要になります。ホスティング業者によっては、これらの情報をウェルカムメールで案内している場合もあります。

FTPクライアントを開き、以下の接続情報を入力してください。FileZillaをご利用の方は、「クイック接続」バーに情報を入力してください。接続が完了すると、右側のパネルにサーバーのディレクトリ構造が表示されます。

ウェブサイトのメインフォルダ（通常は「public_html」、「www」、またはドメイン名で名付けられている）に移動します。

wp-config.php を右クリックし、「ダウンロード」を選択して、コピーをコンピュータに保存してください。これにより、作業用コピーと、編集に失敗した場合に備えたバックアップの両方が作成されます。

ダウンロードしたファイルを、Notepad++ や VS Code などのプレーンテキストエディタで開いてください。Microsoft Word やリッチテキストアプリケーションは、PHP の構文を破壊する見えない書式設定文字を追加してしまうため、使用しないでください。

変更を加える際は、引用符、セミコロン、括弧などがすべて正しく残っているかを確認しながら、慎重に行ってください。ファイルは、バイト順マーク（BOM）を含まないプレーンテキスト形式で保存してください。

変更したファイルをサーバーにアップロードし、元のファイルを上書きしてください。ほとんどのFTPクライアントでは、既存のファイルを上書きする前に確認を求められます。

アップロード後30秒以内に、新しいブラウザウィンドウでウェブサイトにアクセスしてください。ホームページが正常に表示されれば、編集は正常に反映されています。エラーや真っ白な画面が表示された場合は、直ちにバックアップをアップロードして機能を復元し、その間に構文の問題をトラブルシューティングしてください。

cPanel を使用して wp-config.php を編集する

cPanelのファイルマネージャーを使えば、サーバー上で直接wp-config.phpを編集する最も簡単な方法を利用できます。すべての操作は、ホスティングコントロールパネルのWebインターフェースを通じて行われます。

ホスティングアカウントのcPanelダッシュボードにログインし、「ファイル」セクションにある「ファイルマネージャー」アイコンを探してください。それをクリックすると、新しいウィンドウまたはタブでサーバーのディレクトリブラウザが開きます。

ファイルマネージャーが開いたら、「public_html」または ドメイン名のフォルダをクリックして、ウェブサイトのファイルにアクセスしてください。

複数のサイトを運営している場合は、WordPressがインストールされている特定のフォルダに移動してください。

wp-config.php やその他の WordPress のコアファイルとともに、wp-admin、wp-content、wp-includes というフォルダが見つかれば、それが正しいディレクトリです。

ファイル一覧で「wp-config.php」を右クリックし、「編集」を選択します。

ファイルはcPanelに組み込まれたテキストエディタで開き、現在の設定がすべて表示されます。引用符、セミコロン、およびPHPの正しい構文に注意しながら、慎重に変更を行ってください。

編集が完了したら、変更を保存してください。変更は即座に反映されます。再アップロードの手順は不要です。

cPanelでの直接編集は、ダウンロードとアップロードの手順を省略できるため、より迅速に感じられます。しかし、この利便性には代償があり、ローカル環境で事前にテストするという安全策を講じることなく、変更が即座に反映されてしまいます。

ここでも、バックアップの予防措置や慎重な編集作業が求められます。構文エラーが1つあるだけで、他の編集方法と同様にサイトが完全に機能しなくなる可能性があります。

wp-config.php が WordPress の移行に与える影響

完璧に計画された移行作業が、移行先のサイトで接続エラーが表示されるまで誰もデータベースの接続設定を確認しようとしなかったために、数日間にわたる大惨事へと発展してしまうのを何度も目にしてきました。

一般的な移行失敗のパターンは以下の通りです。WordPressのすべてのファイルを新しいホスティングプロバイダーに正常に移行し、データベースもインポートしました。一見、すべて完了しているように見えます。しかし、移行後のサイトにアクセスしてみると、wp-config.phpファイルに以前のホスティングプロバイダーのデータベース認証情報がまだ残っているため、WordPressがデータベースに接続できなくなってしまいます。

以前のホストでは、次のようなデータベース設定が使用されていました localhost ～のために DB_HOST そして oldhost_dbuser ～のために DB_USER新しいホスティングプロバイダーは、まったく異なる認証情報を割り当てます――おそらく mysql.newhost.com サーバーアドレスについては、 newhost_wp123 ユーザー名として。

新しいホスティング環境のデータベース情報を wp-config.php に更新しない限り、WordPress はこの変更を認識できません。

URLの不一致は、データベース接続を確立した後でも、さらなる問題を引き起こします。

以前のサイトのURLやファイルパスは、一見して分かりにくい形でWordPressの至る所にハードコードされています。データベースの内容、テーマの設定、プラグインの設定では、以前のホスティング環境を指す絶対URLやサーバーパスが参照されていることがよくあります。

データベースへの接続が正しく行われていても、こうした参照の不一致により、リンク切れや 画像の表示不能、管理権限に関する問題が発生します。

Duplicator Proは、移行作業中にこうした複雑なURLやパスの更新を自動的に処理します。データベースのレコードや設定ファイルを手作業でくまなく調べてハードコードされた参照箇所を探す必要はなく、Duplicator Proの移行プロセスにより、URL、パス、およびwp-config.phpの設定が、一連の連携した操作で一括更新されます。

wp-config.php を編集する一般的な方法

多くのサイト管理者は、データベース接続エラーの修正や移行プロセスの不具合のトラブルシューティングなど、やむを得ない事情からwp-config.phpの編集を始めるものです。しかし、このファイルの構造に慣れれば、問題のデバッグ、セキュリティの強化、パフォーマンスの最適化など、実用的な改善策を数多く活用できるようになります。

デバッグ

設定 define('WP_SCRIPT_DEBUG', true); これにより、デバッグ作業は当て推量から、的を絞った問題解決へと変わります。難解な参照ではなく、エラーメッセージは、適切にフォーマットされたコード内の読みやすい関数名と論理行番号を指し示します。

WP_DEBUG_DISPLAY エラーメッセージをサイトのページに直接表示するか、訪問者には非表示にするかを制御します。これを falseそれでもエラーは発生し、ログに記録されますが、サイトのデザインを乱すような赤い文字の警告として表示されることはありません。

環境に応じて、これらの設定を戦略的に組み合わせています。開発サイトでは、両方を有効にしています WP_DEBUG そして WP_DEBUG_DISPLAY 問題を即座に把握するため。

ステージングサーバーでは、私は WP_DEBUG と WP_DEBUG_LOG ただし、無効にする WP_DEBUG_DISPLAY 視覚的なテスト体験を損なうことなく、問題を検出するため。

本番環境では、デバッグ機能を有効にしたままにしないでください。これらのエラーメッセージには、サーバーの設定、ファイルパス、プラグインのバージョン、データベースの構造など、機密情報が含まれている可能性があります。

セキュリティの強化

WordPressでは、管理画面を介した不正な変更を防ぐために、ファイル編集の保護機能が採用されています。ホスティングアカウントが侵害されたり、権限のない者が管理者権限を取得したりした場合でも、これらの定数により、最も深刻な被害をもたらす攻撃に対する防御壁が築かれます。

DISALLOW_FILE_EDIT WordPressのダッシュボードからテーマおよびプラグインのエディタ画面を完全に削除します。この保護機能がない場合、管理者権限を持つ者なら誰でも、直接 外観 » テーマエディタ または プラグイン » プラグインエディタ.

DISALLOW_FILE_MODS WordPressの管理画面を通じたすべてのファイル変更を阻止することで、セキュリティ対策をさらに強化します。これには、プラグインのインストールやテーマのアップロードなどが含まれます。 WordPress コアの更新そして バックグラウンドでの自動更新.

その代償は大きい。便利なワンクリックでのプラグインインストールや自動セキュリティ更新が利用できなくなる。変更のたびにファイルシステムへの手動アクセスが必要となるため、信頼性の高い開発プロセスが確立されている場合にのみ実用的な方法となる。

FORCE_SSL_ADMIN 必要とする 暗号化されたHTTPS接続 WordPressの管理操作全般において、ログインページ、ダッシュボードへのアクセス、および管理機能は、暗号化されていないHTTP接続では動作しません。

セット define('FORCE_SSL_ADMIN', true); サイトが機密情報を扱う場合、または管理用アクセスの暗号化を義務付けるコンプライアンス要件の下で運用されている場合。

この機能は、サイトの一般的なSSL設定とは独立して動作します。つまり、管理画面では暗号化を強制しつつ、一般公開ページではHTTPを許可することが可能です。

パフォーマンスの向上

コンテンツの更新が頻繁に行われるアクセス数の多いサイトには、目に見えないパフォーマンス上の問題があります。それは、無制限の投稿リビジョンによるデータベースの肥大化です。WordPressでは、デフォルト設定でコンテンツの下書き、自動保存データ、公開済みバージョンのすべてが保存されます。

WP_POST_REVISIONS WordPressが各投稿やページに対して保持するバージョンの数を制御します。設定 define('WP_POST_REVISIONS', 3); 保存できるのは、現在のバージョンと、その前の3つのリビジョンに限られます。

通常、これだけで、誤って削除したコンテンツを復元したり、問題のある編集を元に戻したりするのに十分であり、無制限の履歴によるデータベースへの負荷もかかりません。

WordPressのダッシュボードは、公開ページよりも多くのメモリを使用します。特に、プラグインのインストール、テーマのカスタマイズ、またはコンテンツの一括操作を行う際には、その傾向が顕著です。 WP_MAX_MEMORY_LIMIT 具体的には メモリの使用可能量を制御する 事務作業のために。

追加 define('WP_MAX_MEMORY_LIMIT', '512M'); これにより、大規模なXMLファイルのインポート、画像のバッチ処理、複雑なプラグイン設定の処理など、メモリを大量に消費する操作において、余裕を持たせることができます。

WordPressでは、削除されたコンテンツは完全に削除されるまで30日間ゴミ箱に保存されます。設定 define('EMPTY_TRASH_DAYS', 7); 保存期間を1週間に短縮し、 削除されたコンテンツを自動的に削除する より積極的に。

ニュースサイトや活発なフォーラムでは、削除されたコンテンツが数日後には復元される必要がほとんどないため、ゴミ箱の保持期間を短く設定する方が適しています。

wp-config.phpによくある問題とその解決方法

wp-config.phpに関する問題のほとんどは、予測可能なパターンに分類されます。どこを確認すべきかが分かれば、これらのエラーは不可解なトラブルではなく、問題解決のヒントとなります。

死の白い画面

サイトにコンテンツが表示されず、真っ白なページが表示されています。これは通常、構文エラーのため、PHPがwp-config.phpファイルを解析できないことを意味します。

これの原因は、何よりもセミコロンが抜けてしまっていることです。wp-config.php ファイル内の、次のように始まるすべての行が define 文の末尾には必ずセミコロンを付ける必要があります。うっかりセミコロンを1つでも抜かすと、PHPはそのファイル全体の処理を停止してしまいます。

引用符の不一致でも同じことが起こります。文字列の先頭を単一引用符で始め、末尾を二重引用符で閉じると、PHPの解析が完全に失敗してしまいます。

サイト運営者が、本当の原因は単なるタイプミスだったというのに、複雑な仮説を検証するために何時間も費やしているのを何度も見てきました 'DB_NAME', 'database_name"); ではなく 'DB_NAME', 'database_name');。その余分な引用符がサイト全体を台無しにしてしまう。

そのバックアップファイルを保存しておいたなら、対処法は簡単です。元の wp-config.php ファイルをアップロードしてすぐに機能を復元し、その後、編集内容をより慎重に再試行してください。

データベースへの接続に失敗しました

幸いなことに、WordPress自体は正常に動作しています。ただ、データベースに接続できないだけです。

まず、4つのデータベース定数を確認してください： DB_NAME, DB_USER, DB_PASSWORDそして DB_HOST. これらの中には、ご利用のホスティングプロバイダーの実際のデータベース設定と一致しないものがあります。

権限とエンコードの問題

wp-config.php ファイルに正しい情報が記載されているにもかかわらず、WordPress がそれを読み込めない場合があります。ファイルの権限が厳しすぎる（WordPress がファイルを読み込むには、少なくとも 644 の権限が必要です）か、ファイルのエンコードに PHP の解析を妨げる隠し文字が含まれている可能性があります。

これは、Microsoft Word やその他のリッチテキストエディタで wp-config.php を編集し、目に見えない書式設定コードが追加された場合に発生します。wp-config.php を編集する際は、必ず Notepad++ や VS Code などのプレーンテキストエディタを使用してください。

ファイルの所有権が間違っていると、権限設定が正しくてもWordPressがwp-config.phpを読み込めなくなります。所有権の問題はホスティングプロバイダーが修正できますが、アクセスに関するトラブルシューティングを行うまでは、必ずしも明らかにならない場合があります。

wp-config.php ファイルを復元する方法

wp-config.phpの編集によってサイトが正常に動作しなくなった場合、トラブルシューティングよりもバックアップからの復元の方が常に有効です。

変更を加える前の最新のDuplicatorバックアップがあれば、5分以内にすべての機能が復元されます。「復元」をクリックするだけです。

これにより、サイトが即座に以前の状態に戻り、構文エラーやデータベース接続の問題のデバッグに何時間も費やす必要がなくなります。

バックアップからの復元ができない場合は、WordPressのサンプルテンプレートを使用して、wp-config.phpを最初から作り直すことができます。新しいWordPressインストールからwp-config-sample.phpをダウンロードし、そのファイル名をwp-config.phpに変更してください。

サンプルファイルには、必要な基本的な構造がすべて含まれています。プレースホルダーとして記載されているデータベースの認証情報を、ホスティングコントロールパネルのデータベースセクションに記載されている実際の値に置き換えてください。

よくある質問 (FAQ)

WordPressの設定を自在に操ろう

wp-config.php は、強力でありながら予測可能なファイルです。このファイルの構造と目的を理解すれば、データベース接続エラーの解決、セキュリティの強化、パフォーマンスの最適化といった作業は、すべて論理的なパターンに従って進めることができます。

もうひとつアドバイスがあります。カスタム設定した wp-config.php の内容とその目的をまとめたドキュメントファイルを作成しておきましょう。ファイルを再作成したり、新しいサーバーに移行したりする際、各カスタム設定がどのような役割を果たしていたかを記憶に頼る必要がなく、具体的な設定内容の参照資料として役立ちます。

WordPressの移行やバックアップを完全に管理する準備はできていますか？Duplicator Proは、wp-config.phpの設定も含めた完全なサイトバックアップを作成するため、サイトの移行や復旧作業もストレスなくスムーズに行えます。

ここにいる間、私はあなたがこれらの関連するWordPressガイドを気に入ると思います：

• ステージングサイトは必要ですか？
• 初心者のためのWordPress REST API：コンテンツにどこからでもアクセス
• WordPress移行前にホストファイルを編集する方法（Windows、Mac、Linuxチュートリアル）
• WordPressでファイルをインポートする方法
• WordPressで変更を元に戻す方法（5つの方法）
• バックアップなしでWordPressサイトを以前の日付に復元する方法