変更されたコアファイル？ WordPressのコアファイルを安全に復元する方法

ホームページがあった場所が白い画面になっています。代わりに 500 エラーが表示されるか、セキュリティプラグインのアラートでコア WordPress ファイルが変更されたと通知されるかもしれません。

自分で壊したサイトや、すでに壊れた状態で表示されたサイトでコアファイルを置き換えました。どのような理由であっても、修正方法は同じで、聞こえるよりも破壊的ではありません。

WordPress のコアファイルを復元するとは、WordPress 自身のプログラムファイル（wp-admin、wp-includes、ルートディレクトリにあるファイル）を WordPress.org からのクリーンなコピーと交換することです。投稿、ページ、メディア、テーマ、プラグイン、設定は移動しません。それらはまったく別の場所に存在します。

自分でこれを試みると、2つの問題が発生します。

1つ目は、コアフォルダと一緒にwp-contentを削除してしまうことです。これにより、20分の修理が完全な再構築になります。2つ目は、古いバージョンでサイトを実行しているのに最新版のWordPressを取得してしまうことです。これにより、すでに不安定なサイトにメジャーバージョンジャンプを強制することになります。

この記事では、何かを削除する前にコアファイルが問題であるかを確認する方法、それらを置き換える3つの方法、そして置き換えても実際の修正にならない場合の対処法を紹介します。

クイックテイクアウェイ:

• 何かを削除する前に確認する: wp core verify-checksums は、コアファイルが問題であるかどうかを1つのコマンドで回答します。クリーンなパスは、決して壊れていないファイルを置き換えることを意味します。
• 最新版を取得するのではなく、バージョンを一致させる: 古いサイトに最新のWordPressをインストールすると、すでに不安定なサイトに計画外のメジャーアップグレードとデータベーススキーマの変更が強制されます。
• 3つの方法があります: ログインできる場合は「バージョンX.X.Xを再インストール」ボタン、SSHがある場合は1つのWP-CLIコマンド、どちらもない場合は手動のFTPスワップです。
• 上書きするのではなく、コアフォルダを削除する: 上書きすると、公式ビルドの何も攻撃者によって追加されたファイルを置き換えないため、wp-adminとwp-includes内に攻撃者によって追加されたファイルが残ります。
• クリーンなコアファイルはハッキングされたサイトをクリーンにしない: wp-content/uploadsのバックドア、悪意のあるmu-plugins、注入されたデータベース行はすべて生き残ります。これは、ファイルごとの修理よりも完全な復元が優れている点です。

目次

WordPress のコアファイルとは？

何かを削除する前に、どのフォルダがWordPressのコアファイルとしてカウントされ、どれが自分のものかを把握する必要があります。これを間違えることが、プロセス全体で最も高価な間違いです。

コアファイルと見なされるものは次のとおりです。

• wp-admin内のすべて。 これは管理ダッシュボード自体であり、ログインするすべての画面です。
• wp-includes内のすべて。 これらはWordPressが実行されるライブラリです。ファイル数で最大のフォルダであり、変更されたとフラグが立てられる可能性が最も高いです。
• ルートディレクトリにある、フォルダ外のPHPファイル。 index.php、wp-login.php、wp-settings.php、wp-cron.phpのようなファイルはフォルダの横にあり、これらも置き換えられます。

どの WordPress ファイルを置き換えるべきではないか？

そのままにしておくべきものは次のとおりです。

• wp-content。 これには、サイト固有のアップロード、インストールされているプラグイン、テーマ、mu-plugins、および場合によってはホストまたはデプロイメントアーティファクトが含まれています。WordPressはこのフォルダのコピーを提供しますが、あなたのものはユニークです。
• wp-config.php。 これにはデータベースの認証情報が含まれています。これを上書きすると、サイトは自身のコンテンツを見つけられなくなります。
• .htaccess。 コアファイルではありませんが、WordPressはこれに書き込みます。コピーを保存し、元のファイルをそのままにしておきます。
• ホストまたは開発者が追加したもの。 ドメイン検証ファイル、カスタムスクリプト、手編集されたrobots.txt。WordPressのダウンロードに含まれていないものは、そのままにしておきます。

wp-content を削除すると、コアファイルを復元するのではなく、サイトをゼロから再構築することになります。

WordPress のコアファイルを復元する必要があるのはいつか？

コアファイルは数ヶ月間そのままにされています。壊れるときは、ほとんどの場合、数個の原因のいずれかです。どの原因を経験しているかを知ることで、その後のクリーンアップの処理方法が変わります。

コアファイルを置き換えるのが正しい判断となるのは、次のような場合です。

• コアのアップデートが途中で失敗した。 接続が切れた、サーバーがタイムアウトした、または PHP のメモリ制限に達した。古いバージョンの一部のファイルと新しいバージョンの一部のファイルが残され、WordPress はそれらを調和させることができません。
• コア WordPress ファイルが変更されたとスキャンが報告した。 Wordfence、Sucuri、および多くのマネージドホストは、ファイルを公式の WordPress.org のバージョンと比較します。変更されたコアファイルは、誰も編集すべきではないコードが変更されたことを意味します。
• サイトがハッキングされた。 攻撃者はコアファイルにコードを注入します。なぜなら、これらのファイルはすべてのリクエストで読み込まれるからです。それらを置き換えることで、注入されたコードはクリアされます（ただし、感染の残りはクリアされません。これについては後で説明します）。
• 転送中にファイルが破損した。 FTP セッションが切断された、または 移行が途中で完了しなかった 場合、切り捨てられたファイルが残ります。ファイル一覧では正常に見えますが、PHP が実行しようとすると失敗します。
• 基本的なトラブルシューティングでも解決しないホワイトスクリーンまたは 500 エラー。 すべてのプラグインを無効にし、デフォルトのテーマに切り替えてもエラーが解消しない場合は、次にコアファイルを確認する必要があります。
• 誰かが意図的にコアファイルを編集した。 これは考えているよりも頻繁に起こります。編集は、アップデートによって上書きされるか、ファイルが WordPress の期待と一致しなくなるまで保持されます。

コアファイルを復元しても全く役に立たない状況が一つあります。それは、プラグインまたはテーマの破損です。このプロセスでは wp-content には触れないため、それが本当の問題である場合、すべての作業を行っても同じエラーにたどり着きます。ステップ 1 は、1 時間費やす前にそれを特定する方法です。

開始する前に必要なもの

コア WordPress ファイルを復元する前に準備しておくべきものは次のとおりです。

• 今すぐ取得した完全なバックアップ。 サーバーを変更する前に、サーバーとは別の場所に保存してください（Duplicator Cloud をお勧めします）。Duplicator Pro を実行している場合、これは悪い午後を 1 回クリックするだけで復元できるものに変えます。
• 少なくとも次のいずれかへのアクセス: WordPress ダッシュボード、SFTP または FTP (FileZilla は無料です)、ホストのファイルマネージャー、または SSH。1 つあれば十分です。どのアクセス方法があるかによって、ステップ 4 の方法が決まります。
• 正確な WordPress バージョン番号を書き留めておくこと。 ダッシュボードがダウンしている場合は、FTP 経由で wp-includes/version.php を開き、先頭近くの $wp_version 行を読みます。
• wp-config.php および .htaccess のローカルコピー。 何か触る前に両方をダウンロードしてください。
• 15 分から 30 分。 最終的に使用する方法によって異なります。

サイトへの実際のトラフィックがある場合は、トラフィックの少ない時間帯にこれを行ってください。アップロードの実行中は、一部が破損した状態になります。

WordPress のコアファイルを復元する方法

プロセスは6つのステップで実行されます。そのうち3つは常に同じですが、ステップ4では、まだアクセスできるものに基づいてパスを選択します。

WordPressコアファイルを復元する方法は次のとおりです。

• ステップ1：コアファイルが問題であることを確認します。チェックサムスキャンにより、元に戻せないものを削除する前に、正しいものを修正しているかどうかを確認できます。
• ステップ2：何かを置き換える前にサイトをバックアップします。スワップ中にドロップする転送は、サイト全体をダウンさせる可能性があります。これは、それを回復可能にするステップです。
• ステップ3：復元しているWordPressのバージョンと一致させます。間違ったバージョンをプルすると、破損したサイトの上に計画外のアップグレードが発生します。
• ステップ4：コアファイルを置き換えます。アクセスに基づいてダッシュボード、WP-CLI、またはFTPのいずれかを選択し、3つのうち1つだけを実行します。
• ステップ5：データベースのアップグレードを実行し、残りをクリアします。古いスキーマに対する新しいコード、スタックされた.maintenanceファイル、および古いキャッシュは、ファイルがすでに正常な場合でも、「まだ破損している」と読み取られます。
• ステップ6：復元が機能したことを確認します。読み込まれるサイトは何も証明しません。2回目のクリーンチェックサムパスが証明になります。

ステップ 1: コアファイルに問題があることを確認する

このステップをスキップすると、破損していないファイルを1時間かけて置き換えることになります。私はそれをやりました。破損したコアファイルと致命的なプラグインエラーは、フロントエンドからは同じように見えます。

WP-CLIは、1つのコマンドで質問を解決します。

WP-CLIはWordPressのコマンドラインツールであり、SSH（サーバーへのターミナル接続）経由で実行します。ほとんどのマネージドホストにはすでにインストールされているため、除外されていると仮定する前に確認してください。

SSHで接続し、WordPressディレクトリに移動して、次を実行します。

wp core verify-checksums

WordPress.orgは、すべてのリリースで各ファイルのチェックサムを公開しています。これは、そのファイルのコンテンツの短いフィンガープリントです。コマンドは、お使いのバージョンのリストをプルし、サーバー上にあるものと比較します。

クリーンインストールは、単一の成功行を返します。破損したものは、検証できないすべてのファイルの名前を付けます。

Warning: File doesn't verify against checksum: wp-includes/version.php

Error: WordPress installation doesn't verify against checksums.

1つの結果は、認識する価値のある誤報です。readme.htmlは、ホストが変更または削除するため、常に失敗します。コマンドはインストール言語を自動的に検出するため、間違って推測した場合にのみ--localeフラグ（例：wp core verify-checksums --locale=de_DE）が必要です。

次に、--include-rootを付けて再度実行します。

wp core verify-checksums --include-root

そのフラグは、WordPressの一部ではないルートディレクトリに配置されたファイルについて警告します。ハッキングされたサイトでは、これが最初に原因となったものを見つける場所であることがよくあります。

SSHアクセスがない場合は、チェックする他の3つの方法があります。

• Wordfenceスキャンを実行します。そのコアファイル比較は、ダッシュボード内から同じジョブを実行し、各ファイルで変更されたものを正確に示します。
• ホストのファイル整合性ツールを使用します。ほとんどのマネージドホストには、通常、セキュリティまたはツールタブの下にあるものが用意されています。
• 手動で比較します。 WordPressのバージョンを新規ダウンロードし、両方のコピーから疑わしいファイルを開き、並べて読みます。

さらに進む前に、正直に結果を読んでください。チェックサムがクリーンであれば、コアファイルは問題なく、問題はプラグイン、テーマ、またはデータベースにあります。

コアファイルを置き換えても、これらのいずれも修正されません。

検証に失敗した特定のファイルのリストを持っているか、別の場所を探すように指示するクリーンなパスを受け取った場合に、ステップ2の準備が整います。

ステップ 2: 何かを置き換える前にサイトをバックアップする

WordPressの実行に必要な2つのフォルダを削除しようとしています。それらを置き換えるアップロードが途中でドロップした場合、サイトは壊れた状態から消滅します。

それは現在抱えている問題よりも悪い問題です。

ファイルとデータベースの両方をカバーする完全なバックアップを取得してください。編集しようとしているサーバーとは別の場所にコピーを送信してください。サーバーレベルの障害から生き残る唯一のコピーは、オフサイトコピーです。

私の好きなツールはDuplicatorです。Duplicator Pro » Backupsに移動し、Add Newをクリックします。

Full Siteバックアッププリセットを選択し、少なくとも2つのストレージ場所を選択します（私はローカルとDuplicator Cloudを使用するのが好きです）。

最終的に2つのファイルが残ります。1つは圧縮されたサイトとデータベースを保持するアーカイブ、もう1つはすべてを元に戻すPHPスクリプトであるインストーラーです。

ファイル復元プロセス中に何か問題が発生した場合は、これらのファイルをサーバーに再アップロードしてDuplicatorのインストーラーを起動してください。

Duplicatorを使用していない場合は、手動でバックアップを取得してください。このステップの最小限必要なことは次のとおりです。

• wp-content、wp-config.php、および.htaccessをFTPでコンピューターにダウンロードします。
• phpMyAdminからデータベースを.sqlファイルとしてエクスポートします。

バックアップがどこにあるか、そしてそれをどのように元に戻すかを知っていれば、次に進む準備ができています。

ステップ3：復元するWordPressのバージョンを一致させる

このトピックに関するすべてのチュートリアルでは、最新バージョンのWordPressをダウンロードするように指示されています。サイトがすでに最新バージョンで実行されている場合は、それは良いアドバイスです。そうでない場合は、落とし穴です。

たとえば、2つのメジャーリリースが遅れているとします。最新のコアファイルをドロップしても、何も修正されていません。行ったことは、不安定なサイトに、テストなしで、緊急事態の最中に、メジャーバージョンアップグレードとデータベーススキーマの変更を強制することです。

現在使用しているバージョンを復元します。後で、意図的に、サイトが健全になったらアップグレードしてください。

バージョン番号を見つける方法は次のとおりです。

• ダッシュボードから： Dashboard » Updatesに移動します。実行中のバージョンは画面の上部に記載されています。
• FTP経由： wp-includes/version.phpを開き、ファイルの上部近くにある$wp_version行を読みます。これは他の何も機能しない場合に機能します。
• SSH経由： wp core versionを実行すると、番号が表示されます。

次に、メインのダウンロードページではなく、WordPressリリースアーカイブからその正確なビルドをダウンロードします。メインページは現在のリリースのみを提供します。

WordPressコアファイルのダウンロードは、wp-admin、wp-includes、wp-content、およびルートの個別ファイルを単一のzipファイルにまとめたものです。メジャー番号だけでなく、完全なバージョン文字列と一致させてください。1リリースポイントの違いでも、ファイルセットは異なります。

WP-CLIを使用する場合は、ダウンロードを完全にスキップできます。以下の方法2のコマンドは、バージョンを読み取り、一致するファイルを1つのステップで取得します。

コンピューター上にサイトと一致するWordPress zipファイルがあるか、ターミナルが開いて待機状態になれば、ステップ4の準備ができたことになります。

ステップ 4: コアファイルを置き換える

これは、破損したファイルが取り除かれ、クリーンなファイルが挿入されるステップです。3つの方法があり、すべてWordPress.orgから検証済みのコピーとWordPressのプログラムファイルを置き換えますが、コンテンツと設定はそのまま残ります。

どちらの方法を使用するかは、アクセス権によって決まります。

• 方法1：ダッシュボードのボタン。 WordPressにまだログインできる場合に使用します。圧倒的に最も速い方法です。
• 方法2：WP-CLI。 SSHがある場合に使用します。最も正確で、同じコマンド内でバージョンを固定できる唯一の方法です。
• 方法3：手動FTP。 そのどちらもない場合に使用します。どのホストでも機能し、最も間違いが発生しやすい方法です。

方法 1: ダッシュボードの再インストールボタンを使用する

wp-adminがまだ読み込める場合は、ここから開始してください。WordPressコアを再インストールする最も速い方法であり、単一のフォルダに触れる必要はありません。

ダッシュボード » 更新に移動します。すでに現在のバージョンを使用している場合、WordPressはその旨を表示し、バージョンX.X.Xを再インストールボタンを提供して、そのバージョンを再インストールするように促します。

クリックします。WordPressはアップデートをダウンロードし、コアアップデートを展開し、展開されたファイルを検証し、最新バージョンをインストールし、データベースをアップグレードします。同じ画面で成功メッセージが表示されて完了します。

開始する前に1つの制限を知っておいてください。これはWordPressがインストールすべきだと判断したバージョンを再インストールするため、ダウングレードすることはできません。もし悪いアップデートがサイトを壊した原因であれば、このボタンでは元に戻せません。

また、フォルダを削除するのではなくファイルを上書きします。方法2も同様です。攻撃者がwp-adminまたはwp-includes内に追加したものはそのまま残ります。ハッキングのクリーンアップを行う場合は、方法3を使用するか、後でチェックサムパスを実行して余分なものが残っていないことを確認してください。

一部のホストでは、接続情報ダイアログが表示され、FTP認証情報を要求されることでプロセスが中断されます。これはファイル所有権の問題であり、下のトラブルシューティングセクションで修正方法を説明しています。

方法 2: WP-CLI を使用する

ターミナルアクセスがある場合は、常にWP-CLIを使用します。SSHで接続し、WordPressディレクトリに移動して、次を実行します。

wp core download --version=$(wp core version) --force --skip-content

各部分の機能は次のとおりです。

• --version=$(wp core version) は、サイトで実行されているバージョンを読み取り、その正確なリリースをダウンロードします。
• --force は、既存のファイルを上書きします。これがないと、WP-CLIは既にWordPressが含まれているディレクトリに触れることを拒否します。
• --skip-content は、wp-contentをダウンロードから完全に除外するため、テーマ、プラグイン、アップロードは上書きされることはありません。

名前は正しく聞こえますが、ここではwp core installに手を伸ばさないでください。このコマンドは、新規サイトでWordPressのインストールルーチンを実行しますが、既に存在するサイトには不適切なツールです。

Enterキーを押す前に、--forceは確認を求めないことを知っておいてください。誰かがこのサイトのコアファイルを意図的に編集した場合、その編集はコマンドが実行された瞬間に消えます。通常はそれが目的ですが、確信がない場合はサイトを構築した人に確認してください。

次に、結果を確認します。

wp core verify-checksums

クリーンなパスは、ファイルの半分が解決したことを意味します。

方法 3: FTP でファイルを直接置き換える

ダッシュボードにアクセスできず、SSHもない場合は、手動で同じ作業を行います。2つのコアフォルダをサーバーから削除し、新しいフォルダを配置します。

個々の操作はどれも難しくありません。保持する必要のあるファイルを保護するのはシーケンスなので、順序に従う価値があります。

1. ダッシュボードにまだアクセスできる場合は、プラグインを非アクティブ化してください。できない場合はスキップしてください。これは予防措置であり、必須ではありません。
2. WordPressのダウンロードをコンピューターで解凍します。wp-admin、wp-includes、wp-content、およびいくつかのルートファイルが表示されます。
3. サーバー上のwp-adminとwp-includesを削除します。両方のフォルダを完全に削除します。他のすべてはそのままにしておきます。
4. 解凍したコピーから新しいwp-adminとwp-includesを同じ場所にアップロードします。
5. 新しいビルドからルートファイルをアップロードし、古いファイルを上書きします。最初にルートフォルダを削除しないでください。そうするとwp-config.phpと.htaccessも一緒に削除されます。
6. 新しいwp-content内のファイルを既存のwp-contentにコピーします。中にコピーします。決して置き換えないでください。
7. wp-config.phpと.htaccessがまだルートにあることを確認します。どちらかが欠落している場合は、以前に保存したコピーをアップロードしてください。

そのリストのステップ3は、削除は上書きよりもリスクが高いと感じるため、人々がためらう場所です。それは逆です。

上書きは、両方のコピーに存在するファイルのみを置き換えます。攻撃者がwp-adminまたはwp-includes内に配置したものは、公式ビルドの一部ではないため、何も上書きせず、クリーンアップ全体をそのまま通過します。最初にフォルダを削除することが、これを真の修正にするのではなく、見た目だけのものにします。

タイミングについても期待を設定してください。wp-includesだけでも千以上のファイルがあり、FTPはそれらを1つずつ移動します。遅い接続では20分が普通であり、転送が中断される可能性があります。

アップロードが引き続き失敗する場合は、zipファイルを単一のファイルとしてサーバーに送信し、ホストのファイルマネージャーでそこに展開してください。1回の大きな転送は、千回の小さな転送よりもはるかに信頼性が高くなります。

フォルダ構造が新しいコピーと一致し、wp-config.phpがそのまま残っており、サイトがデータベースの更新プロンプトで挨拶されたとしても、サイトがロードされると、このステップは完了です。

ステップ 5: データベースのアップグレードを実行し、残りをクリアする

これでファイルはクリーンになりましたが、WordPressは失敗した更新が残した状態のままになっている可能性があります。3つの小さなクリーンアップで作業を完了します。

/wp-adminにアクセスして開始します。再度ログインを求められることがありますが、これは正常です。

WordPressがデータベースをコードに追いつかせる必要があると検出した場合、データベースアップデートが必要ですという画面が表示され、WordPressデータベースをアップデートボタンが表示されます。それをクリックして実行させてください。

これをすぐに実行してください。なぜなら、それまでサイトは古いスキーマに対して新しいコードを実行しているからです。

次に、ルートディレクトリにある.maintenanceという名前のファイルを探し、存在する場合は削除してください。WordPressはアップデートの開始時にそのファイルを作成し、完了時に削除します。アップデートが途中で失敗すると、ファイルが残ったままになり、訪問者はメンテナンスメッセージが表示されます。

これは隠しファイルなので、隠しファイルをオンにしないとファイル一覧に表示されません。FileZillaではサーバー » 隠しファイルの表示を強制、ほとんどのホストファイルマネージャーでは設定の隠しファイルを表示チェックボックスです。

次に、すべてのキャッシュをクリアしてください。キャッシュプラグイン、ホストのサーバーキャッシュ、CDN、およびブラウザのキャッシュです。これをスキップすると、すでに修正されたページをデバッグするのに20分を無駄にする可能性があります。

方法3で無効にした場合は、プラグインを再度有効にしてください。

ダッシュボードがロードされ、アップデートのプロンプトが消え、フロントエンドがレンダリングされれば、ここでは完了です。

ステップ 6: 復元が機能したことを確認する

ロードされるサイトと修正されたサイトは同じではありません。タブを閉じる前に、このリストを確認してください。

確認する内容は次のとおりです。

• wp core verify-checksumsを再実行します。クリーンなパスは、コアファイルが公式リリースと一致することの唯一の確実な証拠です。
• プライベートブラウジングウィンドウで、ログアウトした状態でフロントエンドをロードします。ログインした状態の表示は、キャッシュの問題や権限エラーを隠します。
• 重要なページをクリックして確認します。ホームページ、単一の投稿、カテゴリアーカイブ、ログイン画面、および依存しているフォームまたはチェックアウト。
• パーマリンクを再保存します。設定 » パーマリンク設定に移動し、何も変更せずに変更を保存をクリックします。これにより、リライトルールが再生成されます。これは、ファイルスワップ後に投稿が404エラーを返すようになる一般的な理由です。
• URLを確認します。設定 » 一般で、WordPressアドレス（URL）とサイトアドレス（URL）が以前と同じであることを確認します。
• エラーログを読みます。まだ変更内容を覚えている間に、そこにある新しいものはすべて対処する価値があります。

その後、もう一度バックアップを取ります。サイトは現時点で既知の良い状態にあり、キャプチャする価値のある状態であり、ステップ2で取った緊急バックアップよりもはるかに役立つコピーです。

コアファイルを置き換えても問題が解決しない場合は？

すべての手順を実行し、チェックサムがクリーンに戻っても、サイトがまだ間違っている場合があります。その場合、破損したコアファイルは原因ではなく症状でした。

これらのほとんどは、3つのシナリオで説明できます。

• サイトがハッキングされました。コアファイルを置き換えても、注入されたコードはコアファイルから削除されるだけで、それ以外は何も削除されません。wp-content/uploads のバックドア、変更されたテーマの functions ファイル、または mu-plugins に隠されたものはすべて、これでは生き残れません。最も明白な兆候は、メディア以外の何も置かれるべきではないアップロードフォルダに PHP ファイルが存在することです。
• データベースも破損しました。ファイルは無事ですが、コンテンツはそうではありません。投稿テーブルに注入されたスパムリンク、オプションテーブルで書き換えられた siteurl、および見慣れない管理者アカウントはすべて、コアの復元後も残ります。
• チェックサムは合格しましたが、サイトはまだエラーが発生します。これは、プラグイン、テーマ、または PHP バージョンの不一致を示しています。ステップ 1 は正しい方向へ導きましたが、コアファイルが問題だったことは一度もありませんでした。

これら 3 つのケースすべてにおいて、信頼できるバックアップからサイト全体を復元することが、ファイルを 1 つずつ調べていくよりも優れています。クリーンなものが何であるかを推測する必要がなくなります。

Duplicator Pro で、問題が発生する前のバックアップを見つけて復元してください。

そのバックアップが Google Drive、Dropbox、またはその他の接続されたストレージの場所にある場合、アーカイブをダウンロードして再アップロードする前に、WordPress から直接復元できます。

WordPress がまったくロードしない場合は、最初に開始したバックアップをルートディレクトリに再アップロードしてください。次のような URL で Duplicator のインストーラーを起動します: https://your-domain/installer.php

復元は、バックアップが取得された瞬間にサイトを戻すため、それ以降に公開または注文されたものはすべて失われます。侵害されたサイトでは、通常、これは正しい判断です。なぜなら、1 つのバックドアを見逃した不完全なクリーンアップは、1 週間後にあなたをここに戻してしまうからです。

Duplicator はマルウェアをスキャンまたは削除しません。正常に機能していたサイトのクリーンなコピーを提供します。アクティブな感染に対処している場合は、セキュリティスキャナーと組み合わせて使用してください。

手動でのルートの場合、WordPress サイトを手動で復元する方法 はファイルとデータベースを手動で復元する方法をカバーしており、データベースバックアップのみでウェブサイトを復元する方法 はデータベースしかない場合にどうするかをカバーしています。

トラブルシューティング: コアファイルを復元した後の一般的なエラー

これらは、コアファイルの交換後に最も頻繁に発生する障害です。確認している症状のいずれかから作業を開始してください。

「スケジュールされたメンテナンスのため一時的に利用できません」とサイトに表示されるのはなぜですか？

単一のテキスト行が表示された真っ白なページが表示され、消えません。

WordPress は、アップデートが開始されると .maintenance というファイルをルートディレクトリに書き込み、アップデートが完了すると削除します。アップデートが途中で失敗した場合、そのファイルはまだそこにあり、WordPress はジョブが完了しなかったことを知る方法がありません。WordPress は 10 分後にファイルを無視しますが、アップデートの失敗はサイトを中途半端な状態で残す可能性があります。

隠しファイルを表示した状態で FTP を使用して、ルートディレクトリから .maintenance を削除します。SSH では、wp maintenance-mode deactivate で同じことができます。ファイルが削除された瞬間にサイトは元に戻ります。

FTP 接続情報を求められるのはなぜですか？

Re-install version X.X.X をクリックすると、WordPress はホスト名、ユーザー名、パスワードを求める Connection Information ダイアログを開きます。これは ファイル所有権の問題です。

WordPress は、Web サーバーが実行されているのと同じユーザーが所有するファイルにのみ直接書き込みます。そうでない場合は、FTP 認証情報を要求して、別の方法で書き込めるようにします。

WordPress ファイルを所有する FTP アカウントの認証情報を入力すると、続行されます。それらを持っていない場合は、ホストに所有権を修正するように依頼してください。それが真の修正です。

オンラインで define('FS_METHOD', 'direct'); を wp-config.php に追加するというアドバイスも見つかるでしょう。時々機能しますが、それは症状を回避するだけで、ダイアログよりも診断が難しい方法で後で失敗する可能性があります。

コアファイルを置き換えた後に白い画面が表示されるのはなぜですか？

フロントエンドも管理画面も何も読み込まれず、エラーテキストもありません。これらのほとんどすべてをカバーする 3 つの原因があります。FTP 転送が不完全に終了した、アップロード中にファイルパーミッションが間違っていた、または PHP の致命的なエラーが抑制されていることです。

最も大きいフォルダであり、ファイルがドロップされた可能性が最も高い wp-includes を最初に再アップロードしてください。次に、パーミッションを確認してください。ファイルは 644、フォルダは 755 である必要があります。

画面がまだ空白の場合は、wp-config.php に define('WP_DEBUG', true); と define('WP_DEBUG_LOG', true); を追加し、wp-content/debug.log を読んでください。これにより、白い画面がファイル名と行番号に変わります。

クリーンな再インストール後もチェックサムが失敗するのはなぜですか？

すべてを置き換えましたが、wp core verify-checksums はまだ警告を発しています。通常は 3 つのもののうちの 1 つです。readme.html は、ホストが変更または削除しているためフラグが付けられている、コマンドがインストールに間違った言語を選択した、またはそれらのフォルダ内の何かが実際にそこにあるべきではないことです。

すべてのファイルにフラグが付けられている場合は、ロケールを指定して再実行し (例: wp core verify-checksums --locale=fr_FR)、何が残っているかを確認してください。「ファイルが存在しないはずです」という警告は、コアフォルダ内に余分なものが存在し、上書きしても削除されないことを意味します。wp-admin と wp-includes を完全に削除して、新しいコピーをアップロードしてください。これが Method 3 の違いです。

WordPress が「アップデートが既に進行中です」と表示するのはなぜですか？

再インストールしようとすると、「別のアップデートが現在進行中です」というメッセージが表示されます。WordPress はコアアップデートが開始されるとオプションテーブルにロックを設定するため、2 つのアップデートを同時に実行することはできません。クラッシュしたアップデートは、それをクリアするものが何もないままそのロックを残します。

ロックは 15 分後に自動的に期限切れになるため、待つだけでは時間しか失いません。今すぐクリアするには、wp option delete core_updater.lock を実行するか、phpMyAdmin でオプションテーブルを開き、core_updater.lock 行を見つけて削除してください。

何も機能しない: どうすればよいですか？

リストをすべて試しましたが、サイトはまだダウンしています。この時点で、修復を中止して復元を開始してください。

ステップ2で取得したバックアップに戻ります。ダッシュボードにまだアクセスできる場合は、Duplicator Pro » Backupsからワンクリック復元を実行してください。アクセスできない場合は、アーカイブとインストーラーをルートディレクトリに再アップロードし、ブラウザでインストーラーを起動してください。これは、機能していないWordPressのインストールがなくても機能します。

バックアップがない場合は、ホストに連絡してサーバーサイドのスナップショットについて尋ねてください。ほとんどのホストは、共有プランでもローリングウィンドウで毎日のバックアップを保持しており、サポート担当者が復元してくれます。

よくある質問（FAQ）

クリーンなコアファイルが基本：次に何をすべきか

WordPressのプログラムファイルを検証済みのコピーに置き換え、チェックサムのパスで確認しました。そのパスは、サイトが単に再度読み込まれることよりも重要です。サイトは、変更されたコアファイルがリクエストごとに誰かのコードを静かに実行していても、完全に読み込まれる可能性があります。そのため、診断手順が他のすべてよりも先に来ました。

3つの習慣が、ここからあなたをこの状況から遠ざけます。

• バックアップをスケジュールするようにし、思い出したときに取るのではなく、スケジュールを設定してください。
• すべての正常なアップデートの後で最新のバックアップを取得してください。そうすれば、最新の既知の正常な状態が復元から1つ以上離れることはありません。
• 緊急対策としてではなく、定期的な月次チェックとしてwp core verify-checksumsを実行してください。ヘルスチェック中に見つかった変更されたコアファイルは、サイトがダウンしたときに発見したものよりもはるかに小さな問題です。

wp-config.phpを編集している間に、もう1つやっておく価値のあることがあります。define('DISALLOW_FILE_EDIT', true);を追加して、組み込みのテーマおよびプラグインエディターを無効にします。これにより、管理者アクセス権を持つ誰かがダッシュボード内からファイルを変更する最も簡単なパスが閉じられます。次に、PHPがそこで実行されるのをブロックする小さな.htaccessファイルをwp-content/uploadsに追加します。

<Files *.php>

Require all denied

</Files>

2番目のものはApache 2.4構文なので、nginxではサーバー構成で同等のlocationブロックが必要になります。これらを組み合わせることで、ほとんどの人がこの状況に陥った根本原因である2つのドアを閉じます。どちらも1分以上かかりません。

WordPress サイトを手動で修復するのはやめましょう

コアファイルを手動で置き換えることは機能します。また、午後の時間を費やし、問題が広がる前に発見した場合にのみ役立ちます。最近のバックアップとワンクリック復元により、その長いデバッグセッションが2分に変わります。

Duplicator Proは、150万人以上のアクティブユーザーが、スケジュールされたバックアップ、クラウドストレージからの直接のワンクリック復元、WordPressが読み込まれない場合でも機能する災害復旧URLのために信頼しているものです。すべての有料プランには、14日間の返金保証が付いています。

このチュートリアルがお役に立った場合は、これらのガイドもブックマークする価値があります。

• バックアップからWordPressを復元する方法（5分未満）
• WordPressサイトを手動で復元する方法
• データベースバックアップのみでウェブサイトを復元する方法
• WordPressのバージョンをダウングレードして、悪いアップデートを元に戻す方法
• Google CloudバックアップからWordPressサイトを復元する方法
• バックアップなしでWordPressサイトを以前の日付に復元する方法