500 Internal Server Error

いろはに様

お世話になっております。
JIN:R運営チームのRyotaと申します。

詳細な状況と、すでにお試しいただいた内容をご共有いただきありがとうございます。

ご記載いただいた内容を拝見する限り、JIN:Rテーマ自体を停止しても500エラーが継続していたこと、また`.htaccess`を再作成し、W3 Total Cacheを停止した後はエラーが発生していないことから、今回の原因はJIN:R本体というよりも、W3 Total Cacheによるキャッシュ設定、または`.htaccess`への追記内容が影響していた可能性が高いかと存じます。

JIN:R公式としては、キャッシュ系プラグインは基本的に使用せず、ConoHa WINGなどレンタルサーバー側の高速化機能をご利用いただくことをおすすめしております。

特にW3 Total Cacheのような高機能なキャッシュプラグインは、設定によっては`.htaccess`やキャッシュファイルに複雑な記述が追加されることがあり、テーマ更新・WordPress更新・サーバー設定との組み合わせによって今回のような500エラーにつながるケースがあります。

そのため、現在W3 Total Cacheを停止した状態でサイトが安定しているようでしたら、無理に再有効化せず、停止したまま運用いただくのが安全かと思います。

表示速度対策については、まずは以下のような形でご対応いただくのがおすすめです。

・ConoHa WING側の高速化機能を利用する
・画像圧縮にはEWWW Image Optimizerなどを利用する
・不要なプラグインはできるだけ減らす
・キャッシュ系プラグインは基本的に使用しない

なお、現在サイトが正常に表示されている場合でも、念のためConoHa WING側のバックアップ機能や、必要に応じてUpdraftPlusなどでバックアップを取ってから作業されることをおすすめいたします。

今後また500エラーが再発する場合は、サーバー側のエラーログをご確認いただくことで、より正確な原因の特定が可能です。その場合はConoHa WING側にもあわせてご相談いただくとスムーズかと思います。

ひとまず現状では、W3 Total Cacheは使用しない方針で問題ないかと存じます。

いろはに様

ご連絡ありがとうございます。
各項目について、以下の通り回答させていただきます。

① ConoHa WING側の高速化機能について
はい、基本的にはConoHa公式サポートに記載されている推奨設定に沿って運用いただく形で問題ないかと存じます。

JIN:R公式としても、W3 Total Cacheのようなキャッシュ系プラグインは使用せず、レンタルサーバー側の高速化機能をご利用いただくことをおすすめしております。

ConoHa WINGをご利用の場合は、JIN:Rマニュアル上でも「WEXAL」をONにする運用をご案内しております。

なお、ConoHa公式サポートにも記載がある通り、WEXALと「コンテンツキャッシュ」は併用できない仕様となっております。そのため、WEXALをONにする場合は、コンテンツキャッシュはOFFの状態で問題ございません。

ブラウザキャッシュについては、JIN:R側で一律にON/OFFを指定しているものではないため、基本的にはConoHa公式の案内に沿って設定いただければと思います。ただし、設定後に表示崩れや更新内容が反映されないなどの症状が出る場合は、一度OFFにして挙動をご確認いただくのが安全です。

② バックアップ取得の考え方について
ご認識の通りです。
以下のような、サイト構成や動作に影響する作業前にはバックアップ取得をおすすめいたします。

・JIN:Rのテーマ更新
・プラグイン更新
・WordPress本体アップデート
・PHPバージョン変更
・高速化、キャッシュ関連の設定変更
・functions.phpや.htaccessなどの編集
・大きなデザイン変更

一方で、通常の記事投稿や軽微な文章修正などの日常的な更新については、毎回個別にバックアップを取得する必要性は高くないかと存じます。

ただし、長文記事の編集や大きな固定ページの修正など、作業量が多い場合は、WordPressの下書き保存やリビジョンに加えて、必要に応じてバックアップを取っておくとより安心です。

③ ConoHaバックアップについて
ConoHa WINGの自動バックアップでは、過去14日間分のバックアップが保持される仕様となっております。
そのため、万が一トラブルが起きた場合でも、発生前の日付のWebデータ・DBデータへ戻せる可能性があります。

ただし、「不具合が発生してからバックアップを取得する」というよりは、「不具合が発生する前の状態に戻せるようにしておく」ことがバックアップの目的になります。

また、復元時にはWebデータとDBデータの日時がずれると、画像・記事・設定内容などに差異が出る可能性があるため、復元を行う場合は基本的に同じ日付のWeb・DBを使用するのが安全です。

大きな作業前には、ConoHaの自動バックアップだけに頼らず、UpdraftPlusなどで手動バックアップを取得しておくとより安心かと思います。

④ 今回のケースについて
現在サイトが正常に表示されており、W3 Total Cacheを停止した状態で安定しているようであれば、必ずしも不具合発生前日のバックアップへ戻す必要はないかと存じます。

今回のように、原因と思われるプラグインを停止し、.htaccessの再作成後に正常表示へ復旧している場合、過去のバックアップに戻すことで、逆に現在の正常な状態やその後の更新内容が巻き戻ってしまう可能性もあります。

そのため、現時点では「復元する」のではなく、現在の正常な状態であらためてバックアップを取得しておくのがおすすめです。
今後の運用としては、以下の形が安全かと思います。

・W3 Total Cacheは停止したまま運用する
・ConoHa WING側ではWEXALを中心に高速化設定を行う
・WEXAL利用時はコンテンツキャッシュはOFFで運用する
・JIN:Rのテーマ更新や大きな設定変更前には手動バックアップを取得する
・日常的な記事投稿や軽微な修正では毎回の手動バックアップまでは不要
・万が一500エラー等が再発した場合は、サーバー側のエラーログ確認とConoHaサポートへの相談もあわせて行う

ひとまず現在は正常表示に戻っているとのことですので、過去バックアップへの復元は行わず、現在の正常な状態をバックアップとして残していただく形がよいかと存じます。