WordPressの更新に失敗し、公開に失敗したエラーを修正する方法

公開: 2022-05-03

WordPressサイトのコンテンツを更新しようとすると、 「更新に失敗しました」または「公開に失敗しました」というエラーが発生しますか？あなたは正しい場所に来ました。これらの問題の根本的な原因を特定する方法と、それらを修正する方法を見てみましょう。

WordPressの更新と公開に失敗したエラーの原因は何ですか？

WordPressインスタンスがWordPressRESTAPI（WordPressブロック編集エクスペリエンスが依存している）と通信できない場合、WordPressで「公開に失敗しました」または「更新に失敗しました」というエラーが発生する可能性があります。

これが発生する理由はいくつかありますが、最も明白な理由は、インターネット接続が失われたことです。

接続が失われた場合、公開失敗エラーが発生する可能性があります。これが発生する可能性がある別の理由は次のとおりです。

サイトのURLに対する最近の変更
API呼び出しを防ぐサードパーティサービス
誤動作しているプラグイン

ほとんどの場合、これは簡単な修正です。

ステップ1-インターネット接続を確認し、パーマリンク設定を保存します

おそらく、このエラーが発生する最も一般的な理由は、インターネット接続が失われたときです。ブログ投稿の更新中に予期せず接続が失われた場合、WordPressはこのエラーを返す可能性があります。インターネットに接続していることを確認した場合は、新しいタブの編集ビューで投稿またはページを開き（または、ページから移動する前に変更をコピー/保存してください）、コンテンツの更新を再試行してください。

もう1つの一般的な解決策は、サイトのパーマリンク設定を再保存することです（通常、ホスティング構成に加えられた変更によって失われます）。これを行うには2つの非常に簡単な方法があります。最初に提案する方法はWPCLIを使用することです。

WPCLIを使用してパーマリンク設定を更新する

SSH経由でホスティング環境にアクセスできる場合、パーマリンク設定を更新する最も簡単な方法は次のとおりです。

1 –サーバーへのSSH

2 –WordPressインストールのルートディレクトリに移動します

3 –以下を実行して、既存のパーマリンク構造をフラッシュします。

 wpリライトフラッシュ

4 –パーマリンク構造を以前に使用していたものに更新します。

 wp書き換え構造'/％postname％'

注：これらのコマンドを実稼働環境で実行している場合は、パーマリンク設定を別の構造に変更すると（使用していたのと同じ構造に戻さずに）トラフィックが失われるため、注意して続行してください。

WordPress管理エリアのパーマリンク設定を更新する

または、以下に示すように、[設定]>[パーマリンク]からアクセスできるパーマリンク設定のWordPress管理エリアで直接この変更を行うこともできます。

ステップ2–RESTAPIがブロックされているかどうかを確認する

上記のように、WordPress Publishing Failedエラーが発生する可能性があるもう1つの一般的な理由は、RESTAPIが無効またはブロックされている場合です。ありがたいことに、WordPressには、RESTAPIのステータスを確認するために使用できる便利なツールがあります。

[ツール]に移動し、[サイトの正常性]を選択するだけです。 ここでは、WPのインストールに関連する一連のエラーが表示されます。 REST APIが正しく機能していない場合は、次のエラーが表示されます。

「RESTAPIで予期しない結果が発生しました。」

さらに、サイトヘルスレポートには、サイトにインストールしてアクティブ化した特定のプラグインによってREST APIがブロックされている場合など、トラブルシューティングの方法に関するヒントがいくつか表示されます。

サイトの特定の原因をデバッグする最良の方法は、ブラウザのコンソールログを確認することです。これにより、次の行に沿って何かが表示される可能性があります。

上記の場合、正確なエラーメッセージは「エラー更新に失敗しました。 エラーメッセージ：応答は有効なJSON応答ではありません。 」とエラーの原因は、CloudflareのファイアウォールがユーザーのIPによるWPJSONへのアクセスをブロックしていたことでした。

したがって、問題がWP JSONから403（禁止）ステータスコードを取得している、またはREST APIエラーであると思われる場合は、実施しているセキュリティ対策（Webアプリケーションファイアウォールなど）が適切であることを確認してください。ユーザーがWordPressWebサイトのコンテンツを公開または更新できないようにする、これらのディレクトリへのアクセスを意図せずにブラックリストに登録しないでください。

ステップ3–Webアプリケーションファイアウォールサービスを確認する

Cloudflareは、コンテンツ配信ネットワーク（CDN）サービス、DDoS保護、インターネットセキュリティ、およびDNSサービスの世界最大のプロバイダーです。

私たちはここServeboltでCloudflareの大ファンです– Cloudflare最適化パートナーとして、ServeboltとCloudflareの間のより良いネットワーキング接続を提供します。私たちは、ServeboltCDNやAcceleratedDomainsサービスなど、インフラストラクチャのさまざまな部分にCloudflareEnterpriseを使用しています。

サイトでCloudflareを使用している場合、サービスがRESTAPI呼び出しをブロックする可能性があります。ファイアウォールフィルターがトリガーされ、CloudflareがIPアドレスを疑わしいと見なした場合、すべてのREST APIリクエストがすぐにブロックされ、WordPress管理領域で「更新に失敗しました」または「公開に失敗しました」というエラーが発生する可能性があります。

その場合、先に進む前に、簡単な修正としてIPアドレスをホワイトリストに登録し、IPが独自のWAFによってブロックされた理由を特定するために、Webアプリケーションファイアウォールの分析をチェックして、どのファイアウォールルールがトリガーされたかを確認します。

ステップ4– PHPエラーログを確認し、WordPressでデバッグモードを有効にする

WPデバッグを有効にして、WordPress独自のデバッグシステムを使用する前に、Serveboltを使用しているユーザーはPHPエラーログに簡単にアクセスできます。

デフォルトでは、Servebolt Cloudで実行されているすべてのサイトは、 ErrorLogとAccessLogの2つのログを生成します。これらはすべて、サイトのルートの/ logsフォルダー（つまり、 / publicディレクトリと同じレベル）で丸めることができます。

ErrorLogファイルには、ランタイムエラーを生成するサイトで実行されているコードに関する情報が含まれます（これには、サイトを破壊せず、バックグラウンドでサイレントに失敗し続けるエラーが含まれますが、場合によっては失敗します）。

また、これでエラーの原因に関する詳細情報が得られない場合は、WordPressでデバッグモードを有効にできます。デバッグモードに入ると、WordPressは受信したPHP応答をdebug.logという新しいファイルに自動的に記録します。

この新しいファイルはwp-contentディレクトリに表示されるため、問題の原因となっている可能性のあるサーバー側の応答を確認する必要があります。

デバッグモードに入るには、wp-config.phpファイルを開き、最後の行の直前に次の行を追加します。

 //WP_DEBUGモードを有効にします
define（'WP_DEBUG'、true）;

///wp-content/debug.logファイルへのデバッグログを有効にします
define（'WP_DEBUG_LOG'、true）;

//本番サイトでエラーを公開しないようにします（宣言されていない場合、これはデフォルトでtrueになります） 

define（'WP_DEBUG_DISPLAY'、false）;

debug.logファイルを確認したら、このコードをwp-config.phpファイルから削除して、デバッグモードを終了できます。

Serveboltを使用すると、ErrorLogやAccessLogなどのPHPエラーログにデフォルトでアクセスできます。リクエストに応じてサポートチームに連絡して利用できるSlowQueryLogに加えて。ただし、WordPress独自のデバッグシステムはエラーを特定するのに最適であるため、コードベースを制御しながら、タイトな船を走らせることができます。

これは言うまでもありませんが、 wp-config.phpファイルに変更を加える場合は、慎重に進めてください。サイトのバックアップに役立ちます。 Servebolt Cloudで実行されているWebサイトは、1日2回バックアップされます。日中のバックアップ（3日間保存）と夜間のバックアップ（30日間保存）を実行します。

WordPressサイトを自分でバックアップすることもできます。バックアップを復元するには、サポートチームに連絡するだけで、追加費用なしで最新のバックアップを復元できます。

ステップ5–すべてのWordPressプラグインを無効にして、もう一度確認する

エラーがサイトのWordPressプラグインによって引き起こされている疑いがある場合、1つのオプションは、すべてのプラグインを無効にして、問題が解決するかどうかを確認することです。

これを行うには、プラグインに移動し、[インストール済みプラグイン]を選択します。次に、すべてのプラグインを選択し、[一括操作]ドロップダウンを使用して一度に非アクティブ化します。

次に、画面に戻り、WordPressの更新または公開に失敗したエラーが引き続き発生するかどうかを確認します。そうでない場合は、サイトで実行されているプラグインがエラーの原因であることがわかります。この段階での力ずくの方法は、プラグインを1つずつ再アクティブ化し、エラーが再度発生したときに確認することです。また、削除のプロセスにより、障害のあるプラグインを特定できるようになります。

問題を見つけたら、プラグインの作成者に連絡して、デバッグする必要のある情報を入手するように提案することを強くお勧めします。これにより、プラグインはあなた（および他のすべてのユーザー）の製品を改善できます。明らかに非常に面倒で時間がかかることを考えると、これはデバッグに関しては確かに私たちの最初の選択肢ではありません。

一時的な回避策：Classic Editorプラグインをインストールします（解決策ではありません）

WordPressバージョン5.0の導入は、Gutenbergエディターの導入を示しました。つまり、今日私たち全員がブロックと広く呼んでいる概念です。

これは一時的な回避策にすぎませんが、GutenbergエディターからClassicエディターに切り替えると、投稿を保存および更新できる場合があります。

注：これは明らかに解決策ではないため、一時的な回避策としてのみ使用する必要があります。

グーテンベルクからクラシックエディターに切り替えるには、クラシックエディタープラグインをダウンロードしてサイトでアクティブ化します。有効になったら、編集していた投稿（またはページ）に戻るだけで、通常どおりに更新または公開できるようになります。

ステップ7–サポートチームに連絡する

上記のいずれも問題が解決せず、WordPressサイトをServebolt Cloudでホストするという賢明な決断を下した場合は、遠慮なくサポートチームに連絡してください。チャットとメールでご利用いただけますので、ご連絡いただければ、この問題の原因を調査させていただきます。

結論

エラーが発生した場合、特に作業を保存したり、作業中の新しいコンテンツで公開を押したりすることができない場合は、誰もが望んでいることではありません。そのため、簡単な修正と一時的な解決策が推奨されますが、問題の原因を特定して、再発しないように対策を講じることを強くお勧めします。

経験的に高速なマネージドホスティングに興味がありますか？ Serveboltの方法を試してください：

スケーラビリティ：実際のユーザーワークロードテストでは、Serveboltの平均応答時間は65ミリ秒で、2番目に優れた応答時間の4.9倍でした。
最速のグローバル読み込み時間： 1.26秒の平均ページ読み込み時間は、グローバルWebPageTest結果のリストの一番上にあります。
最速のコンピューティング速度： Serveboltサーバーは、これまでにないデータベース速度を提供し、平均の2.44倍のクエリを処理し、2番目に優れたものの2.6倍のPHPを実行します。
完璧なセキュリティと稼働時間：すべてのモニターで100％の稼働時間、SSL実装でA +の評価により、サイトがオンラインで安全であることが保証されます。

すべて私たちの専門家チームによって支えられています。 今日、無料のテストボルトでServeboltを試してみる準備はできましたか？