WordPressのバグを修正するための情報を取得する方法

公開: 2020-07-20

WordPressサイトを管理して、会社のビジネスに最高の価値を提供できるようにすることは、単純な義務ではありません。 WordPressサイトを効果的に運営するために必要な幅広いスキルと知識があります。 WordPressサイトのバグを調査して修正する能力は、Webサイトをスムーズに実行するために最も重要です。

目次を隠す
  1. 1. WordPressのサイトの本質的なアーキテクチャを理解します
    1. 1.1。 フロントエンド
    2. 1.2。 Webプラットフォーム– WordPress
    3. 1.3。 Webサーバー（LAMPスタック）
    4. 1.4。 オペレーティングシステムとハードウェアインフラストラクチャ/ VPS
    5. 1.5。 ネットワークとセキュリティ
  2. 2.コミュニティサポートを依頼する
  3. 3.システム全体を以前の安定したバージョンに復元します
  4. 4.最後の言葉

WordPressサイトの根本原因を特定するプロセスは、サイトごとに異なる場合があります。 これは、サイトアーキテクチャとそれに対応するコンポーネントの多様性によるものです。 以下の投稿は、鳥瞰図からWordPressのバグを修正するためのいくつかの重要なポイントを提供します。 したがって、WordPressの問題のトラブルシューティングは、科学だけでなく芸術にも属する必要があります。

WordPressサイトの基本的なアーキテクチャを理解する

DevSecOpsスコープを見ると、WordPressのバグは次の原因で発生している可能性があります。

  • フロントエンド。
  • Webプラットフォーム–WordPress。
  • Webサーバー（LAMPスタック）。
  • オペレーティング・システム
  • ハードウェアインフラストラクチャ/ VPS（Amazon、VMwareESXI…）。
  • ネットワークセキュリティー。

バグを修正するには、WordPressサイトのアーキテクチャについて知っておく必要があります。

フロントエンド

キャッシュのクリアとDNSのフラッシュは、Webの読み込みの問題が発生した場合のエンドユーザーの一般的なアクションプランです。

クライアントのWebブラウザの開発者ツールを使用して問題のあるHTML要素を特定し、サーバーサイトから再確認します。 これは多くの場合、次のレベルになります–Webプラットフォームレベルでのトラブルシューティング。

クライアントのWebブラウザの開発者ツールを使用してWordPressのバグを修正します。

Webブラウザの開発者向けツール

Webプラットフォーム– WordPress

WordPressホームの重要なファイルとディレクトリに注意してください（ $WP_HOMEのデフォルト値は/var/www/html/<wordpress_root_dir> ）。

ファイルパス説明
$WP_HOME/wp-config.php –サイトの構成ファイル。
$WP_HOME/wp-content –WordPressサイトのコンテンツが含まれています。
$WP_HOME/wp-content/uploads –WordPressのアップロードファイルを含むディレクトリ。

–このアップロードディレクトリはCONFIGURABLEです。

現在の状態をバックアップする

複雑なバグの場合、トラブルシューティング計画での誤った試みは避けられないようです。 WordPressサイトのバグを修正しながら予期しない結果に対処するには、システム全体または重要なコンポーネントをバックアップする必要があります。 バックアップバージョンは、WordPressテーマ、それに付随するデータベースを備えたWebソースにすることができます。 開発者がホスト全体のバックアップを実装できれば理想的です。

システム管理者が本番サイトのダウンタイムを減らすために、事前にいくつかの安定したバージョンを準備しておけば素晴らしいと思います。

WordPressキャッシュをクリアする

キャッシュされたデータをクリアすると、WordPressサイトは利用可能な最新のリソースで動作します。 オペレーターはプラグインを使用して、キャッシュされたアイテムを簡単に削除できます。

ページ/投稿レベルでのトラブルシューティング

まず、いくつかのページ/投稿を試して、すべてのページ/投稿で同様のバグが発生するかどうかを確認します。 同様のコンテンツでページ/投稿を再作成すると、問題が解決する場合があります。

プラグインレベルのトラブルシューティング

1.すべてのプラグインを無効にします。
2.プラグインを一度に1つずつ再アクティブ化します。
3.再アクティブ化するたびにサイトをテストします。 問題は再発しましたか？ もしそうなら、あなたは今疑わしいプラグインを見つけました。 そうでない場合は、次のプラグインに進みます。
4.問題のあるプラグインを無効にし、最新バージョンに更新し、可能であれば代替プラグインを見つけます。
5.他のプラグインをテストして、複数のプラグインの問題がないことを確認します。

テーマレベルのトラブルシューティング

1.現在のテーマを無効にします。
2.デフォルトのテーマまたは別のテーマをアクティブにします。
3.問題が解決した場合、テーマが問題を引き起こしています。 そうでない場合は、WordPressコアレイヤーに移動します。
4.すべてのプラグインを個別に再アクティブ化して、複合的な問題がないことを確認します。 問題が再発しない場合、根本的な原因はテーマ領域に属します。

WordPressコアでのトラブルシューティング

1.wordpress.orgからクリーンバージョンのWordPressをダウンロードします。
2. SSH、FTP、または適切な端末ツールを使用してサイトに接続します。
3. wp-adminとwp-includes名前を変更して、これらのディレクトリのクリーンコピーを確実にアップロードします。
4.万が一の場合に備えてwp-config.phpバックアップします。 これらのファイルは、（とりわけ）データベース接続の詳細を保持します。
5.クリーンバージョンのWordPressをアップロードします。
6.テストします。 問題が解消された場合、根本的な原因はWordPressコアにあります。 問題が解決しない場合は、さらにアクションプランを進める時間です。
7.テーマを再度アクティブにして、テストします。
8.プラグインを再度アクティブにして、テストします。

Webサーバー（LAMPスタック）

Webサーバーは、HTTP要求の受信、HTTP要求の処理、およびクライアントへのHTTP応答の提供を担当するソフトウェアです。 すべてのWordPressサイトは、特定のWebサーバー上で実行されます。 LAMPスタック（Linux – Apache – MySql / MariaDB – PHP）は、WordPressサイトの一般的なWebサーバーです。

Apache

重要なディレクトリ（CentOSにApacheをデプロイする場合のデフォルト値。デフォルト値はプラットフォームによって異なります）。

ファイルパス説明
/ var / www / html Webrootホームディレクトリ

[root @ centos-wp-01 wpadmin] ＃cat /etc/httpd/conf/httpd.conf | grep'DocumentRoot '

＃DocumentRoot：サービスを提供するディレクトリ

DocumentRoot“ / var / www / html”

/ etc / httpd / ApacheWebサーバーのルートディレクトリ

[root @ centos-wp-01 wpadmin] ＃cat /etc/httpd/conf/httpd.conf | grep'ServerRoot '

ServerRoot“ / etc / httpd”

/etc/httpd/conf.d/ Apache構成のディレクトリ
/ etc / httpd / logs Apacheログ

[root @ centos-wp-01ログ] ＃ls -1 / etc / httpd / logs

access_log

access_log-20200227

access_log-20200301

access_log-20200429

エラーログ

error_log-20200227

error_log-20200301

error_log-20200429

error_log-20200605

–重要な構成ファイル：/etc/httpd/conf/httpd.conf
– Apache構成ファイルのリスト：

  • [root @ centos-wp-01ログ] ＃ls -1 /etc/httpd/conf.d/
  • autoindex.conf
  • php.conf
  • phpMyAdmin.conf
  • README
  • userdir.conf
  • welcome.conf

通常、問題がある場合は、Apacheログに表示されます。 ただし、他のセクションも確認する必要があります。

MySQL / MariaDB

ユーザー名、パスワードなど、データベース内のデータの名前を確認する必要があります…

PHP

PHPの操作を制御する重要な手法の1つは、ログを有効にすることです。 WordPressオペレーターは、 .htaccessファイルまたはphp.iniファイルを変更することでログを有効にできます。 バグが発生した場合、開発者はバックアップし、デバッグログを有効にして、問題を再現できます。 システムの動作はログファイルに記録されます。 この情報は、オペレーターが根本原因を特定し、解決策を考え出すのに役立ちます。

ログファイルの絶対パスを決定するために、オペレーターはパラメーター$_SERVER['DOCUMENT_ROOT']確認できます。

オペレーティングシステムとハードウェアインフラストラクチャ/ VPS

RAM、ディスクスペース、CPU使用率、ネットワークトラフィックなどの重要なパラメータを使用してシステムパフォーマンスを監視します。 詳細なユーティリティは、WordPressサイトをホストしているプラ​​ットフォームによって異なります。 それでも、問題のトラブルシューティングを行うには、これらのパラメーターを再確認する必要があります。

システムパフォーマンスを監視すると、WordPressのバグを修正するのに役立ちます。

topコマンドを使用してLinuxリソースを監視する

ネットワークとセキュリティ

HTTP / HTTPSプロトコルのトラフィックが正常に動作していることを確認します。 デフォルトでは、ポート80/443（HTTP / HTTPS）にある必要があります。 懸念すべきもう1つの重要なポートは、MySQL / MariaDBの3306です。

HTTP / HTTPSプロトコルのトラフィックをチェックして、WordPressのバグを修正します。

ネットワークツールを使用して、リモートホストのポートオープンステータスを調査する

上記のポート番号は、発信トラフィックの一般的な値であることに注意してください。 HTTPリクエストの内部トラフィックとデータベーストラフィックは、異なるポートで実行される場合があります。

コミュニティサポートを依頼する

WordPressには世界中で最大のコミュニティがあるため、問題に付随する操作ログ/スクリーンショットを提供することで、簡単に助けを求めることができます。 バグを報告するために利用できるWordPress開発者はたくさんいます。

バグを報告するために利用できるWordPress開発者はたくさんいます。

StackOverflowは、WordPressのバグを修正するための参照の手がかりを収集するための便利なリソースです

もう1つのオプションは、WordPressのバグを処理するためにフリーランサーを雇うことです。

システム全体を以前の安定したバージョンに復元する

多くの場合、バグの調査を検討し、WordPressサイトのダウンタイムを最小限に抑えることをお勧めします。 いくつかの複雑なバグの場合、解決に数時間から数日かかる場合があります。 したがって、生産現場をカジュアルな運用状態に保つための代替アクションが必須です。

生産現場をカジュアルな運用状態に保つために、別のアクションを実行する必要があります。

WordPressのホストの完全バックアップを準備する

最後の言葉

WordPressのバグを修正する最終的な目標は、最高のパフォーマンスのWebサイトを提供することです。 したがって、それは企業のビジネスに最高の価値を提供することです。 WordPressのバグを修正する方法を知ることは、Webサイトの操作を深く理解するための重要なスキルです。 オペレーターは、ビジネスオペレーションをシームレスに維持するだけでなく、Web開発市場でのキャリアを向上させる機会も増えます。

この投稿を読んだ後、バグ修正についてより深い洞察を得て、自分でバグを修正するための情報をより簡単に入手できることを願っています。