WordPressサイトを修正するための4つのヒント

公開: 2020-09-03

数日前、友人から電話があり、古いWordPressプロジェクトを維持するタスクが与えられたと言われました。どうやら、ウェブサイトは3年以上更新されておらず、至る所で問題がありました。プラグイン、テーマ、コンテンツなど、何も更新できなかったため、貧しい人は完全に立ち往生していました。何も機能しませんでした。すべてのアクション（サイト自体の閲覧を除く）により、WordPressがクラッシュし、エラーが返されました。

エラーを継続的に生成し、更新できない使用できないWordPressがある場合、最初に行う必要があるのは、WordPressがそのように動作している理由を特定することです。つまり、犯人を見つける必要があります。通常、WordPressサイトで発生する可能性のある問題は、テーマまたは1つ（または複数）のプラグインが原因で発生します。

これを考慮して、WordPressサイトを修正する通常の手順は、問題のあるプラグインを特定し、方程式から除外し、すべてを更新し、最後に、問題のあるプラグインをWebサイトに再インストールして更新できるかどうかを確認するか、置換。今日は、Webサイトが失敗する理由を発見し、それを修正できるようにするための4つの簡単なトリックを紹介します。

サーバーのエラーログの使用

それが私たちのウェブサイトで私たちが持っているエラーを引き起こしているプラグインであるという仮説を仮定すると、私たちが最初にやらなければならないことは、その仮説を検証することです。そうするためのさまざまな式があります。個人的には、cPanelに独自のオプションがあるサーバーのエラーログを確認することから始めたいと思います。

うまくいけば、エラーログには、当社のWebサイトで発生したエラーのトレースだけでなく、エラーが発生した「場所」、つまり誰が原因であるかに関する情報も含まれています。たとえば、先週、開発環境のエラーログで次の問題が発生しました。

 appserver_1 | [Mon Aug 24 09:18:20.977541 2020] [php7:notice] [pid 1107] [client 172.20.0.2:34396] PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>yoast/v1/get_head</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugg ing in WordPress</a> for more information. (This message was added in version 5.5.0.) in /app/.lando/wordpress/wp-includes/functions.php on line 5225, referer: http://nab5.lndo.site/wp-admin/edit.php

ログは、WordPress自身のファイルの1つ（ wp-includes/functions.php ）で発生したPHP通知を報告していますが、これは「プラグインが原因である」ことについては何も教えてくれません。幸いなことに、メッセージ全体を読むと、失敗したもの（つまり、 register_rest_route関数の呼び出し）が説明され、何が間違っている可能性があるかについてのヒントが得られます。Yoast（「 yoast/v1/get_head 」の記述を参照してください。？）。

エラーログは、何かが間違っているかどうか、もしそうなら、エラーの背後にある理由をすばやく見つけるための最も簡単な方法です。この特定の例では、Yoastに問題があることがわかりました。まあ、私がしなければならなかったのは、プラグインを最新バージョンに更新することだけでした。

WordPressダッシュボードからのプラグインの非アクティブ化

残念ながら、Webサイトのエラーログにアクセスして、状況が悪化した時期を確認できるとは限りません。または、ログにアクセスできる場合は、ログが不完全である可能性があります。このような場合、最初の仮説を検証（または反証）するための代替式が必要です。

プラグインの欠陥が原因で当社のWebサイトが失敗していると仮定すると、最も簡単な方法は、すべてのプラグインを非アクティブ化し、エラーが続くかどうかを確認することです。そうでない場合、犯人はプラグインでした。それが続く場合、問題は他の場所にあります。

これを行うには、WordPressダッシュボード»プラグインに移動し、アクティブなプラグインをすべて選択して、それらを一括で非アクティブ化します。

それでもエラーが発生するかどうかを確認します。そうでない場合は、非アクティブ化したプラグインの1つが原因で問題が発生したことがわかります。さて、どれを正確に発見する時が来ました。

障害のあるプラグインを特定するには、プラグインを1つずつアクティブにして、エラーが再び表示されるタイミングを確認します。または、より速く進みたい場合は、次の手順を適用できます。

プラグインの半分をアクティブにします。
1. エラーが再発する場合は、アクティブ化したばかりの半分に原因があるため、残りの半分を安全にアクティブ化できます。
2. エラーが表示されない場合、原因は残りの半分です。
障害のあるプラグインがどの「グループ」にあるかがわかれば、そのプラグインに焦点を合わせてプロセスを繰り返すだけで済みます。そのグループの半分をアクティブにし、残りの半分を非アクティブにして（つまり、全体の4分の1をチェックすることになります）、Webサイトが正しく機能するかどうかを確認します。
原因が見つかるまでこのプロセスを繰り返します。

どのプラグインが失敗しているのかがわかったら、問題を修正する方法はあなた次第です。開発者に連絡するか、プラグインを自分で修正するか、別のプラグインに置き換えることを検討する必要があるかもしれません。しかし、少なくとも、問題を取り除くために何をする必要があるかがわかったはずです。

アクティブなプラグインのリストをバックアップする

最初から私の友達を覚えていますか？彼のウェブサイトを調査していたとき、私たちは前のすべての手順に従い、彼のウェブサイト上のすべてのプラグインを非アクティブ化しました…

…その結果、死の白い画面が表示されました。

どうやら、ウェブは多くの相互依存関係を持つカスタムプラグインとテーマの微調整でいっぱいでした。プラグインを非アクティブ化することにより、テーマが依存していた機能の一部が使用できなくなり、致命的なエラーが発生しました。これは明らかに悪い習慣です。テーマは、プラグインがアクティブであることに依存することはできません。特定のプラグインによって提供される機能の一部が必要な場合は、セキュリティチェックを実装して、それらが使用可能かどうかを検証する必要があります。

とにかく、サイトは完全にシャットダウンされ、ダッシュボードを使用してプラグインを再アクティブ化できませんでした。では、ここでの解決策は何ですか？さて、初心者のために、あなたは常にあなたのウェブサイトのバックアップを持っているべきです…しかしこの特定のケースでは手元にもっと簡単でより速い解決策があります。

WordPressデータベースには、 wp_optionsという名前のテーブルがあります。そこに、 active_pluginsという名前のオプションがあります。その値は、すべてのアクティブなプラグインを含む配列です。したがって、前述の一括アクションを使用してプラグインを非アクティブ化する前に、この値をテキストファイルに保存してください。

このように、「すべてのプラグインの非アクティブ化」が起こりそうもない（ただし不可能ではない）WSODになった場合、データベースのactive_pluginsオプションを復元することにより、すべてのプラグインを再アクティブ化できます。

FTP経由でプラグインを非アクティブ化する方法

問題が特定のプラグインによって生成されていることがわかっているが、WordPressダッシュボードから問題を非アクティブ化する方法がない場合は、FTP経由で安全に実行できます。

すでにご存知のように、プラグインはファイルのセットにすぎません。 Webサイトに新しいプラグインをインストールすると、そのコードはWordPressのwp-content/pluginsフォルダーに配置されます。この知識を利用して、プラグインを上記のフォルダーから「削除」することにより、プラグインを非アクティブ化できます。

サーバーのcPanelに移動し、FTPオプションを探します。

次に、FTPファイルエクスプローラーを使用して、 wp-content/pluginsフォルダーを見つけ、プラグインを見つけます。

これで、プラグインを削除するか、WordPressが見つけられないようにフォルダーの名前を変更するだけです。このように、WordPressサイトにログインすると、WordPressはプラグインを認識しなくなり、障害のあるコードをロードできなくなり、問題が解決します。

デフォルトのテーマを使用する

最後に、問題の原因がプラグインの1つであるという仮説が正しくない場合、次のステップは、原因がテーマであると想定することです。この場合、あなたがしなければならないのは、デフォルトのWordPressテーマ（Twenty Twentyなど）をインストールして、問題が解消されるかどうかを確認することだけです。それが消えた場合、あなたはすでにあなたの元のテーマに何か問題があることを知っています。そうでない場合は、別の投稿で説明する必要があります。

何らかの理由でWordPressダッシュボードにアクセスできない場合は、FTP（ wp-content/themes ）経由でアップロードして新しいテーマをWebサイトにインストールし、データベースを使用してアクティブなテーマを変更できます。 wp_optionsのオプションtemplateとstylesheet 。たとえば、アップロードしたテーマが20であると仮定して、両方のオプションをtwentytwentyに設定することができます。

要約すれば

バニラワードプレス（プラグインなし、カスタムテーマなし）が失敗する可能性は低いです。したがって、Webサイトに問題がある場合、原因はプラグインまたはテーマの1つである可能性があります。今日の投稿では、犯人を見つけ、邪魔にならないようにし、Webサイトを回復するためのさまざまな公式を見てきました。これらのトリックを使用する必要がないことを心から願っています…しかし、使用する場合は、それらが役立つことを願っています。

友達のウェブサイトはどうですか？よくわかりませんが、転職したと言う人もいます…

UnsplashのOliaNaydaによる注目の画像。