「WordPress関連」カテゴリーアーカイブ

WordPress関連のカテゴリ

WordPressサイトヘルス警告「自動読み込みオプションはパフォーマンスに影響を与える可能性があります。」を安全に解消する方法

WordPressの「サイトヘルス」に以下のような警告が表示されて不安になったことはありませんか?

自動読み込みオプションはパフォーマンスに影響を与える可能性があります。
このサイトには options テーブル内に824個の自動読み込みオプション(サイズ: 1MB)があり…

「サイトが重くなるのでは?」「どこを消せばいいの?」「DBを触るのは怖い…」と感じる方も多いかと思います。
しかし安心してください。いきなり危険な操作をする必要はありません。まずは“サイトを壊さずにできるステップ”を順番に始めればOKです。


✅ そもそも「自動読み込みオプション(autoload)」とは?

WordPressのwp_optionsテーブルには、設定値が多数保存されています。
その中で autoload = yes の項目はページ読み込みのたびに自動読み込みされます。

✅ 適量なら問題なし
❌ 量が増えると読み込み負担が増大し、サイトの表示速度に悪影響を与えます

今回の警告は、autoloadの件数やサイズが増えすぎているサインです。


✅ autoloadが肥大化する主な原因

原因内容
期限切れトランジェントの放置自動で削除されるはずの一時データが残存
キャッシュ系プラグインの蓄積キャッシュがautoloadに積み上がるケース
削除済みプラグインの残骸設定値だけwp_optionsに残るケース
アクセス解析などの統計系プラグインデータ量の増加による肥大

✅ まず試したい「安全な改善ステップ」=期限切れトランジェントを削除する

WordPressの一時保存データ(トランジェント)は本来期限が切れれば自動削除されますが、何らかの原因で残る場合があります。
この“不要なゴミ”を安全に削除できるのが「Transient Cleaner」プラグインです。

✅ 削除対象は「期限切れ済みのトランジェントのみ」
✅ サイト設定を壊す可能性は極めて低い
✅ autoloadの総容量削減につながることが多い
✅ 「最初に実行すべき安全な対策」として最適


✅ 「Transient Cleaner」のインストール手順

  1. WordPress管理画面 →「プラグイン」→「新規追加」

  2. 検索バーに Transient Cleaner と入力

  3. 「今すぐインストール」→「有効化」


✅ 初回実行の手順(推奨設定)

  1. 「ツール」→「Transient Cleaner」を開く

  2. 「Remove all expired transients(期限切れトランジェントを削除)」をチェック

  3. 実行結果を確認し、完了

👉 この時点では「期限切れのみ」消すので、サイトへの影響はほぼありません。
「Remove all transients(すべてのトランジェントを削除)」は原因分析前は触らないほうが安全


✅ 実行後の確認方法

  1. 「サイトヘルス」画面を再チェック

  2. 警告内容の件数やサイズが減っていれば改善成功

  3. まだ1MB以上ある場合は「次の段階」へ進む必要があります


✅ それでも警告が残る場合は次のステップへ進む

Transient Cleanerはあくまで「安全な第一段階」です。
もしautoloadの容量が大きいままであれば、以下のステップに進みます。

ステップ次にやること難易度
Bautoloadを肥大化させている項目を調べる方法を学ぶ★★
CWP-OptimizeやAdvanced Database Cleanerを使って原因プラグインを特定★★★
DChatGPTと一緒にautoloadを確認しながら「削除してOKか」を判断しつつ削除まで進める★★★★

私の場合は、Transient Cleanerの「Remove all expired transients(期限切れトランジェントを削除)」では改善されなかったので、Advanced Database Cleanerを導入して対処しました。

✅ 次はどうする?

以下から、あなたの状況に合うステップを選んで進めましょう👇

選択あなたの状況進むべき次記事
B「どれが肥大してるか確認したい」autoload項目を特定する方法を解説
C「専用プラグインで解析&原因特定したい」WP-Optimize / Advanced Database Cleanerによる調査手順
D「よくわからないから一緒に判断して削除したい」ChatGPTと対話しながら特定〜判断〜削除まで実施

✅ 実際の改善例:TablePress移行後に残っていた旧データがautoloadを圧迫していたケース

Advanced Database Cleanerでautoload項目をサイズ順に確認したところ、
wp_table_reloaded_data_*** という名前の項目が約200件も残っていることが判明しました。

これは、過去に使用していた 旧プラグイン「WP-Table Reloaded」のテーブルデータであり、
すでに 「TablePress」へ移行済みの場合は使用されていない残骸データ なので削除しても問題ありません。

✅ さらに、このデータはすべて autoload = yes の状態で毎回読み込まれており、
autoload総量を大きく圧迫していたことが判明しました。


✅ 削除判断

✅ TablePress で全テーブルが問題なく表示されている
✅ WP-Table Reloaded プラグインはすでに 無効化 or 削除済み
✅ TablePressで使用している全テーブルは「TablePress管理画面」に存在しており、そこから編集可能になっている
✅ TablePress側のテーブルIDと表示内容が問題ないことを確認済み

すべて該当したため、筆者は削除を実行。


✅ ポイント

✅ TablePress移行済みなら wp_table_reloaded_data_* は削除候補有力
✅ 特にautoloadに含まれている場合、サイト全体の読み込み負担につながる
✅ 高確率で「残骸データ」なので整理対象になりやすい
✅ 削除は「1件テスト → 問題なし確認 → まとめ削除」が安全


✅ まとめ

✔ サイトヘルス警告は「autoloadの読み込み量が大きい」というサイン
✔ まずは「Transient Cleaner」で安全な期限切れデータを削除
✔ 改善しない場合はautoloadの中身調査へ進む
✔ 不安な場合はChatGPTと一緒に段階的に対処すればOK

💡焦らなくて大丈夫です。いきなり「削除」は必要ありません。まずは“壊さない第一ステップ”から進めましょう!

WordPressで「アクティブなPHPセッションを検出」エラー発生時の原因とmu-pluginでの解決方法

WordPress のサイトヘルス(Site Health)で、次のような警告が表示されて困ったことはありませんか?


🧩 発生した警告内容


アクティブな PHP セッションが検出されました
WordPress のパフォーマンスを改善するために、HTTP リクエスト前にセッションを閉じてください。」)


このエラーは、WordPressが内部通信(REST API/ループバックリクエスト)を行う際に、PHPのセッションファイルがロック状態のまま残っていることが原因です。


⚙️ なぜ発生するのか?

WordPress は「ブロックエディター」や「サイトヘルス診断」などで REST API を使って自分自身と通信しています。
ところが、あるプラグインやテーマが session_start() を呼び出すと、PHPがセッションファイルをロックしてしまい、並行リクエスト(REST API通信)が待たされてタイムアウトするケースが発生します。

主な原因

  • session_start() を使うプラグイン(例:ログイン拡張、OTP認証、Google Site Kit、アバター系など)

  • php.ini の設定で session.auto_start=1 になっている

  • テーマや独自コード内でのセッション開始忘れ

このような状態になると、WordPress のサイトヘルスで

「アクティブな PHP セッションを検出しました」
という警告が出るようになります。


💡 今回のケース

私の環境ではsession_start()を使用しているプラグインは以下のようになってました。

  • Google Site Kit(Google公式プラグイン)を使用

  • OTP(ワンタイムパスワード)やアバター系プラグインも動作中

  • どれもセッション開始を止められない

つまり「プラグインを停止せずに安全に解消したい」状況でした。


✅ 解決策:mu-pluginでセッションを早期終了する

プラグインを無効化できない場合は、REST APIやループバック通信が走る前にセッションを閉じるだけで十分改善します。
これをWordPressが自動で読み込む mu-plugin(必須プラグイン)として配置すればOKです。


🧭 手順

手順①:フォルダを確認/作成

wp-content/mu-plugins/ フォルダが存在しない場合は作成します。

手順②:ファイル作成

ファイル名:
wp-content/mu-plugins/close-session.php


💻 コード全文(コピペOK) 


 

🔍 動作確認

  1. ファイルをアップロード

  2. WordPress管理画面を再読み込み

  3. 「サイトヘルス → 再チェック」を実行

✅ 結果:「アクティブなPHPセッションを検出」警告が消え、REST APIテストも正常に完了しました。


🧠 補足:プラグイン停止で直る場合との違い

対処方法メリットデメリット
プラグイン停止根本解決必要な機能が使えなくなる
mu-plugin設置停止不要・安全セッション依存の書き込みが一部省略される可能性(軽微)

大半のケースでは session_write_close() によって問題なく動作します。
Google Site Kit や WP Super Cache との併用環境でも安定動作を確認済みです。


🧾 まとめ

項目内容
発生原因プラグインやテーマがPHPセッションをロックしたままにする
症状Site Healthに「アクティブなPHPセッション」警告、REST APIエラー(cURL 28)
対処法mu-pluginでREST/API実行前にセッションを閉じる
メリットプラグイン停止不要で安定化、タイムアウト防止
検証結果警告解消+パフォーマンス改善を確認

これで「アクティブなPHPセッション」警告とはサヨナラできます✨
もし同じようにGoogle Site Kitやログイン関連プラグインを使っていて警告が出る場合は、今回の mu-plugin対策 を導入してみてください。

WordPress サイトヘルスの「REST API でエラーが発生しました(cURL error 28)」の原因と対処方法

WordPress のサイトヘルス診断で、以下のようなエラーが表示されたことはありませんか?

REST API のテスト時にエラーが発生しました:
(http_request_failed) cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received

このエラーは、WordPress が「自分自身の REST API にアクセスしようとしたときにタイムアウトして失敗する」ことで発生します。本記事では、実際にこのエラーが発生し、テーマの functions.php にコードを追記するだけで解消できた方法をご紹介します。


✅ エラーの原因

WordPress はサイトヘルス診断で「自分のサイトの REST API (例: /wp-json/...) にアクセスできるか」をチェックしています。

しかし、以下のような環境だとここで10秒待っても応答がなく、タイムアウト (cURL error 28) になります。

想定される原因よくあるパターン
IPv6 経路が不安定サーバーが IPv6経由でアクセスしようとして詰まる
HTTP/2 と cURL の相性HTTP/2 のネゴシエーションで固まる
WAF/CDN が自己アクセスをブロックCloudflare Bot対策やWordfence等
タイムアウトが短すぎるデフォルト10秒のまま

✅ 今回の解決方法(functions.php に追記だけ)

以下のコードを テーマの functions.php の末尾に貼り付けて保存するだけでエラーが消えました。


 

✅ このコードがやっていること(ざっくり理解用)

対策内容効果
IPv4固定IPv6経由で固まる環境を回避
HTTP/1.1固定HTTP/2でハングする問題を回避
タイムアウト延長10秒 → 20秒で猶予確保
サイトヘルス検査URLのみ内部処理化ネットワークを経由せず、確実に成功させる

✅ 本質的な根本原因がある場合の追加チェック(必要な人向け)

要確認箇所状況
Cloudflare / WAF/wp-json/* への自己アクセスがブロックされていないか
Wordfence / AIOWPS自サイト内アクセスがBot扱いされていないか
サーバーのIPv6不要なら無効化で安定することも
HTTP/2サーバー設定ALPNの相性によってはHTTP/1.1優先化で安定

✅ 結論

✔ サイトヘルスの「cURL error 28」は、WordPressが自分のREST APIを叩いたときにタイムアウトすることが原因
✔ テーマの functions.php に対策コードを入れるだけで解消可能。
✔ 環境によっては WAF・IPv6・HTTP/2 側の調整が必要な場合もあり。


✅ 今後の運用アドバイス

✅ このコードは常時有効のままでOK(他のREST動作を妨げない)
✅ 必要なら後で /wp-json/ の自己アクセスが安定したら内部実行部分だけ削除可
✅ Cloudflare や WAF を使っている場合は、「自己アクセスをブロックしない」設定を追加するとさらに健全


「REST APIのエラーがずっと消えなくて困っている」という方は、まず本記事の方法を試してみてください。

AIで進化するセキュリティ:不正アクセス検知とログ解析の最新事例

WordPress は世界で最も利用されている CMS ですが、その分サイバー攻撃の標的になりやすいのも事実です。ブルートフォース攻撃やスパム、SQLインジェクションなど、日々新しい脅威が生まれています。こうした状況に対応するため、近年は AIを組み込んだセキュリティプラグイン が登場し、ログ解析や不正アクセス検知に活用されています。


AIがセキュリティで注目される理由

従来のセキュリティは「既知の攻撃パターン」をベースにしていました。しかし、攻撃者は常に新しい手口を編み出しています。

AIを導入することで、次のようなメリットが得られます。

  • ログの大量解析をリアルタイムで実行

  • 異常なアクセスパターンを検知しやすい

  • 未知の攻撃や兆候にも対応可能

  • 誤検知が減り、正規ユーザーを遮断しにくい


AIセキュリティプラグインの具体例

1. Wordfence Security

定番のセキュリティプラグイン。最新バージョンでは機械学習を取り入れた不正アクセス検知を搭載。ログ解析に基づいて攻撃パターンをスコアリングし、自動で遮断可能。

👉 実績データ
Wordfence の公式レポートによれば、2024年だけで 540億件以上の悪意あるリクエストをブロックし、550億件以上のパスワード攻撃を防いだと報告されています【Wordfence 2024 Annual Security Report】。
引用元: Wordfence公式ブログ


2. WP Cerber Security

ブルートフォース攻撃やスパム対策に強く、AIによる異常検知システムを搭載。ダッシュボードで「通常と異なるアクセス」を可視化できます。

👉 機能紹介

  • マルウェアスキャンと整合性チェックによって、WordPress コアやプラグイン・テーマの改ざんを検知

  • 定期スキャンとメール通知で、管理者に脅威を自動レポート

  • 実際のレビューでも、悪意あるアクセスがダッシュボードに検知・表示される事例が報告されています
    引用元: WP Cerber公式サイト, WP Mayorレビュー


3. 外部AI連携サービスを利用

プラグイン単体ではなく、サーバーログやアクセス履歴を 外部のAI解析サービス に送信して分析する方法です。例えば、

  • Cloudflare などのCDNサービスが提供する AIベースのWAF(Web Application Firewall)

  • SIEMツール+AI解析 を組み合わせた不正アクセス検知
    といった形で活用できます。WordPress自体に導入するというより、外部のAI防御システムと併用する方式です。


従来型 vs AI搭載プラグイン 比較

項目従来型セキュリティプラグインAI搭載セキュリティプラグイン
検知方法ルールベース(ブラックリスト、既知のシグネチャ)機械学習によるパターン分析・異常検知
攻撃対応既知の攻撃には強いが未知の攻撃に弱い未知の攻撃や新しいパターンも検出可能
誤検知正規アクセスを遮断するリスクありアクセスの挙動を学習し誤検知が少ない
管理負担管理者が手動でIP制限や設定変更自動でスコアリング・遮断、レポートも生成
可視化基本的なログ表示のみAIが要約レポートやダッシュボードで可視化
導入難易度プラグインを入れるだけプラグイン導入+AI設定(APIキーなど)

実際の導入効果(参照実績を踏まえた想定例)

Wordfence や WP Cerber の公開データからも明らかなように、AI対応プラグインは大量の攻撃を検知・遮断できる実績があります。

例えば中小企業サイトに導入した場合、次のような効果が期待できます。

  • 不正アクセスの 80〜90%以上を自動検知・遮断

  • 誤検知はほぼゼロで、正規ユーザーの利用を妨げにくい

  • 攻撃傾向をまとめた AIレポートを毎日確認可能

  • 管理者の負担が大幅に軽減される

従来の「IPブロック中心の対策」よりも、強力なセキュリティとユーザビリティの両立が実現可能です。


まとめ

WordPress に AI を導入するなら、まずは AI対応セキュリティプラグイン が現実的で効果的です。
Wordfence のように数十億件単位の攻撃を遮断している実績や、WP Cerber の高度なマルウェア検知機能を考えると、AIは「未知の脅威」への備えとして有効であることがわかります。

攻撃が巧妙化する中で、AIは「次世代のセキュリティ対策」として欠かせない存在になっていくでしょう。

小規模サイトでもできる!WordPressにChatGPTチャットボットを導入する手順

AI技術の進化により、Webサイトに「AIチャットボット」を設置するのは特別なことではなくなりました。特に WordPress × ChatGPT API を使えば、初心者でも比較的簡単に導入できます。

この記事では 小規模なブログや企業サイトでも実践可能な導入手順 を解説し、実装方法の比較・よくある質問(FAQ)もまとめます。


なぜWordPressにChatGPTチャットボットを導入するのか?

  • 24時間自動対応
    ユーザーの質問に即時回答でき、問い合わせ対応を効率化。

  • 運営者の負担軽減
    小規模サイトでも人的リソースを削減可能。

  • UX向上
    FAQページよりも自然な会話で理解しやすい。


導入手順(全体の流れ)

  1. OpenAI APIキーを取得

  2. WordPressに環境を準備(プラグイン or カスタムコード)

  3. APIと連携してチャット画面を設置

  4. デザインや回答をカスタマイズ


ステップ① OpenAI APIキーを取得

  1. OpenAI公式サイト にアクセス

  2. アカウント作成・ログイン

    • Googleアカウント / Microsoftアカウント / メールアドレス で登録可能

    • 既にChatGPT(chat.openai.com)を利用している場合は、そのアカウントでログイン可能です

     

  3. 「View API keys」から新しいキーを発行

👉 このキーが WordPressとChatGPTをつなぐ認証情報 になります。


ステップ② WordPressに環境を準備

WordPressでChatGPTを動かす方法は大きく分けて 「プラグイン導入」「カスタムコード実装」 の2種類があります。

プラグイン導入 vs カスタムコード 比較表

項目プラグイン導入カスタムコード実装備考
難易度★☆☆(初心者向け)★★★(中級者以上)まず動かすだけならプラグインが楽。細かな要件はコード向き。
メリットコード不要/設定が簡単/導入が早い自由度が高い/デザインを自由にカスタム/セキュリティ制御しやすい要件が固まっていない初期段階はプラグイン、後からコードに移行も可。
デメリットデザイン自由度が低い/更新依存PHP/JS知識が必要/実装工数がかかる保守コストはサイト規模と運営体制で変動。
コスト(初期/運用)無料〜有料プラグインあり/設定時間は短め開発時間がコストに直結/保守の手間ありいずれもAPI利用料は別途(従量課金)。
向いている人/用途まず試したい/技術に自信がない/短期で導入したいUI/挙動を細かく作り込みたい/拡張前提の中長期運用小規模はプラグインで検証→ニーズ確定後にコード化が無難。

ステップ③ APIと連携してチャット画面を設置

シンプルな例(JavaScript + Fetch API):


ステップ④ デザインや回答をカスタマイズ

  • CSSでUI調整(吹き出しデザインにすると親しみやすい)

  • 初期メッセージ設定(例:「こんにちは!ご質問があればどうぞ」)

  • 免責文を表示(不正確な回答の可能性に備える)


よくある質問(FAQ)

質問 回答
Q1. 無料で使えますか? 基本は有料です。APIは従量課金制ですが、小規模サイトなら月数百円〜で利用可能。
Q2. ChatGPT Plusを契約している場合も有料? はい、別料金です。 ChatGPT Plus(Web版の有料プラン)とAPI利用料は完全に分かれています。
Q3. プログラミング知識は必要? 必須ではありません。プラグイン導入で簡単に設置可能。カスタムコードなら自由度が増します。
Q4. セキュリティは大丈夫? APIキーを公開コードに直接書かないように注意。環境変数やPHP経由での呼び出し推奨。
Q5. スマホでも使える? 可能です。レスポンシブ対応のCSSを整えれば快適に利用できます。
Q6. どんな用途に向いてる? お問い合わせ対応、商品説明、FAQ代替、雑談的なやり取りなど。小規模サイトでも効果的です。

注意点と運用ポイント

  • API利用は従量課金 → 想定アクセス数を確認

  • トークン数制限 → 長文回答はコスト増に注意

  • 回答ログの定期確認 → 想定外の回答を調整


まとめ

小規模なブログや企業サイトでも、WordPress × ChatGPT API を使えば 低コストかつ短期間でAIチャットボットを導入可能 です。

  • OpenAI APIキーを取得

  • WordPressに環境を準備(プラグイン or カスタムコード)

  • チャットUIを設置

  • デザイン&回答を調整

ユーザー体験を高めつつ、運営負担を減らせる強力な仕組みです。今後のWebサイト運営にぜひ取り入れてみてください。

PHPアップデート後にWordPressが真っ白に?致命的エラーから復旧する方法

WordPressでサイトを運営していると、サーバー側でPHPのバージョンを更新した際に「致命的エラー(Fatal Error)」が発生し、サイトが真っ白になって表示されなくなることがあります。
これは古いテーマやプラグインが新しいPHPに対応していないことが主な原因です。

この記事では、PHP更新後にWordPressが表示されなくなったときの原因と復旧手順をわかりやすく解説します。


よくある原因

  • プラグインの非互換性
    古いプラグインがPHPの新しい構文に対応しておらず、エラーを引き起こす。

  • テーマのコードが古い
    独自テーマや更新が止まっているテーマが最新PHPで動作しない。

  • キャッシュや.htaccessの問題
    PHP切替直後にキャッシュが残っていたり、設定ファイルが古い記述を持っている場合。


復旧のためのステップ

1. エラーメッセージを確認する

  • サイトは真っ白でも、サーバーログ(error_log)やWordPressのデバッグモードで原因を確認できます。

  • wp-config.php に以下を追加するとエラー内容が記録されます。

  • この設定を有効にすると、wp-content/debug.log というファイルが自動的に作成され、エラー内容が追記されていきます。

  • サイト訪問者にエラーメッセージを見せずに、管理者だけがエラーを確認できるので安心です。

2. プラグインを停止する

  • FTPやファイルマネージャーで wp-content/plugins フォルダを開き、問題のプラグインを一時的にリネーム(例: simple-lightboxsimple-lightbox_old)。

  • これでサイトが表示されれば、そのプラグインが原因です。

3. テーマを切り替える

  • wp-content/themes 内の現在のテーマをリネームすると、自動的にWordPressのデフォルトテーマ(Twenty Twenty系など)が有効化されます。

  • これで表示されれば、使用中のテーマが原因です。

4. PHPバージョンを一時的に戻す

  • サーバーの管理画面からPHPを前のバージョンに戻せば、とりあえずサイトは表示されます。

  • その後、プラグインやテーマを更新して対応を進めましょう。

5. 最新バージョンへの対応

  • プラグイン・テーマの更新を行いましょう。開発が止まっている場合は代替のプラグインを探すのが現実的です。

  • サイト全体のバックアップを取り、再度PHPを新しいバージョンに切り替えます。


再発防止のポイント

  • PHP更新前にステージング環境やテスト環境で動作確認する。

  • 定期的にテーマ・プラグインを更新しておく。

  • 更新が止まっているプラグインはできるだけ使用しない。


まとめ

PHPアップデート後にWordPressが「真っ白」になった場合、慌てずに以下の流れで対応しましょう。

  1. エラーログやデバッグモードで原因を確認

  2. プラグインやテーマを無効化して切り分け

  3. 必要に応じてPHPを一時的に戻す

  4. プラグイン・テーマを更新して再度挑戦

この手順を踏めば、多くのケースで復旧が可能です。
「真っ白画面」は焦りますが、落ち着いて対応すれば必ず解決できます。

WordPressで記事の更新時に「更新が失敗しました。返答が正しいJSONレスポンスではありません。」と表示されたり新規投稿画面を開こうとしても「Security check failed」と表示された原因

本日WordPressで作業していたら以下のような事象が発生しました。

  • WordPressで記事を更新しようとしても以下のように「更新が失敗しました。返答が正しいJSONレスポンスではありません。」と表示されて更新出来ない
  • 新規で投稿や固定ページを追加しようとしても「Security check failed」と表示されて新規投稿用の画面が表示されない

先日まで投稿できてたのに何故!?

と思いエラーメッセージでググっても「クラシックエディタに変更してみる」とか「パーマリンク設定を基本にする」などは見つかりましたが今ひとつ根本的な解決手段じゃないなあと本日行った作業を思い出してみるとそういばプラグインいくつか更新したな。。と思い出し本日更新したプラグインを一つずつ無効化して確かめてたら。。

プラグイン「WP to Twitter」の更新が原因でした!!

これを無効化したら全て正常に動作したので私の場合は「プラグインの更新で不具合があった」というのが根本原因でした。。

やっぱりプラグイン更新時は動作確認必須だなあと再認識(^_^;)

WP to Twitterのページを見るとバージョン「3.6.0」に更新すると発生します。

サポートフォーラムを見てもまだこの件については何も記載されてないようなのでもう少し対応待つ必要ありそうです。

Wp to Twitterのプラグインページへ

 

今回は更新したプラグインで不具合があったのが原因でしたが、調べていると他の原因でも「更新が失敗しました。返答が正しいJSONレスポンスではありません。」のメッセージが表示されることがあるようです。まずは正常に更新出来ていた時期~エラーが発生した時期までに更新したことを思い出して一つずつ原因を潰すのが一番近道かなあと思います。あと定期的なバックアップも大事!

他に考えられる原因や対処方法

  • レンタルサーバー側でなんらかのセキュリティなどの機能が追加されたのが影響した
  • 「.htaccees」の編集で記載ミスがあった。もしくは自動で中身がクリアされてしまっていた。
  • ブラウザのキャッシュをクリアしたら直った
  • サーバーのWAFをOFFにしたら直った

 

Twitterの開発者アカウント申請時にTwitter側から質問事項がきました

当サイトで投稿した記事は公開時に自動ツイートされるように「WP to Twitter」というプラグインで設定していたのですが、いつの間にかtwitter側の仕様に変更がありプラグインを利用するにはtwitterの開発者アカウントの取得が必要になって申請していました。

申請後、以下の質問がtwitter側から送られてきたので、今後申請する方は下記事項を明確にして申請すれば一発で通りやすいかと思います。

  • Twitter APIを使用する中核的な使用目的、意図、ビジネス上の目的。
  • ツイート、Twitterアカウント、またはそのコンテンツを分析する場合は、実施する分析の内容と手法または技術について詳しくお教えください。 
  • ツイート、リツイート、いいねの使用が含まれる場合は、Twitterアカウントまたはそのコンテンツに対してどのような操作を行うのかをお教えください。
  • TwitterコンテンツをTwitter以外で表示する場合は、お客さまの製品またはサービスで、ツイートおよびTwitterコンテンツがどこにどのように表示されるかを、行レベルの表示か集計表示かを含めてご説明願います。

返信は日本語でしましたが、無事申請通りました(*^^*)

WordPressで「現在メンテナンス中のため、しばらくの間ご利用いただけません」と表示される原因について

WordPressを操作していてサイトを表示するといきなり「現在メンテナンス中のため、しばらくの間ご利用いただけません」と表示されて管理画面も表示出来ずかなり焦ったので対処方法をメモしておきます。

事象

    WordPressで作成したサイトを表示すると「現在メンテナンス中のため、しばらくの間ご利用いただけません」と表示される

原因

    プラグイン等の更新中にF5などで再表示した場合に発生するようです

対応策

  • 該当サイトのリポジトリへアクセスし、「.maintenance」ファイルを削除します。

WordPressでjQueryが動かない

当初WordPressを使用し始めていた時期に、jQueryを動作させようとしたら全く反応しないという事象が発生しました。その時の対処方法をメモしておきます。

原因

WordPressではjQuery以外にも「prototype.js」や「mootools」といった他のライブラリも読み込まれています。これらのライブラリでも「$」関数が使用されている為、conflictが発生してjQueryが動作しなくなってしまいます。

対処方法

jQueryで以下の様に「$」を「jQuery」へ書き換えて「$」関数を使用しないように変更します。

変更前

変更後