他のプラグインがうまく稼働しなくなった

QAそのものが原因の場合というよりも、プラグイン同士の相性の問題で動かなくなることが多いです。特に下記3つのプラグインにはお気をつけください。

  • キャッシュ系プラグイン
  • バックアップ系プラグイン
  • セキュリティ系プラグイン

キャッシュ系プラグインについて

JavaScriptの圧縮や書き換えを止める

キャッシュ系プラグインでは、勝手にJavaScriptを圧縮したり書き換えてしまうものがあります。その場合、QAの計測タグがうまく稼働しなくなり、データを取得できなくなります。この場合の対策は、こちらの記事にもあるようにキャッシュ系プラグインの設定画面でJavaScriptの圧縮や書き換えをしないように設定お願いします。

キャッシュの生存期間を短くする

QAはbotのアクセスを記録しないように作成しています。しかし、キャッシュ系プラグインの中には、botアクセスであってもキャッシュを作成してしまうものがあります。そうするとキャッシュにアクセスされている間、QAはbotのアクセスだと判断し、記録がされなくなります。

またQAではセキュリティ対策としてnonce値というものを利用しており、24時間以上たったキャッシュへのアクセスは計測対象外とします。

上記2点への対策はキャッシュの生存期間をなるべく短くすることです。1時間程度にして頂ければ最大でもデータ未計測時間は1時間程度になりますし、サーバー負荷がきになる場合も24時間を超えないように設定します。

バックアップ系&セキュリティ系のプラグインについて

QAのデータ保存領域を対象外にする

バックアップ系やセキュリティ系のプラグインによっては、QAほど頻繁にデータ計測をしたり、大きなデータを保存するようなソフトウェアを想定していないことがあります。

そのため、QAを入れた後、うまくバックアップがとれなかったり、セキュリティ系のプラグインの負荷があがってしまうということが起こります。

この対策として、設定画面があればQAを対象外にすることで回避できます。

具体的には、wp-content/qa-heatmap-analytics-dataというデータ領域を対象外にすることで、うまく稼働することが多いです。

別のプラグインやレンタルサーバー側のセキュリティ設定を使う

有名なプラグインだとしても、上記の設定画面がなかったり、そもそもあまりよい仕組みになっていないプラグインもあります。その場合、そもそもQAに関係なくそのプラグインを利用することでサーバーに負荷がかかっていることもあります。

QAとしては、バックアップは、レンタルサーバーに付属しているバックアップを利用されることを推奨しています。その方がサーバーの負荷も小さく、かつ確実にデータが元に戻るからです。

セキュリティについてもサーバー側で対処していることもありますので、できればレンタルサーバーを借りられる時に、その観点でもチェックされることをお勧めいたします。

その他、既存のプラグインやテンプレートに問題が発生した場合

今までご説明したように、QA側の問題だけではなく相性の問題で発生しますので、元のプラグインの設定を変更しなければならないことが多いです。

WordPress公式サイトのサポートフォーラムで、元のプラグインの公式サポートフォーラムを検索したり、QAのサポートフォーラムを検索したり、質問をすると有識者から解決策を教えてもらえることもありますので、ご活用ください。

この記事は役に立ちましたか?

関連記事