返信先: WordPress更新後に500エラーが発生し、現在は403エラーになっている

最初に500エラーが発生したのは、それまでのテーマやプラグインがphp8.3では動かなかったためではないかと推測します。おそらく、相当長期間、PHPやWordPress、テーマ、プラグインなどを更新してこなかったのではないですか？

このような場合、一気に何もかも更新しようとすると、どれがトラプルの原因かわからなくなるので、最初にUpdraftPlus: WP Backup & Migration Pluginなどでバックアップをとってから、少しずつ進めるのがしあわせの道です。

ちなみに、UpdraftPlus: WP Backup & Migration Pluginは、PHPやWordPressの対応バージョンの範囲が広いので、使い勝手がいいです。

さて、「WordPress本体のファイルをバックアップからFTPで上書き」したにも関わらず元に戻らなかったのは、おそらくFTPでアップしたもののオーナー・グループやパーミッションが、Webサーバの動作に適さない形で上書きしてしまったためではないかと思います。バックアップから戻した後、そこを直せば、ひとまず元のようにはできるかなと思います。

WordPress更新後に500エラーが発生し、現在は403エラーになっている

WordPressの更新後に500エラーが発生し、さまざまな対応を試しましたが、現在もサイトが正常に表示されないため、原因と対処方法についてご相談させてください。

■ 発生までの経緯

1. PHPのバージョンを7.4から8.3（モジュール版）に変更
2. WordPress本体を最新版にアップデート
3. プラグインをアップデート
4. その後、サイトのトップページと管理画面で500エラーが発生

■ これまでに試したこと

• WordPress本体のファイルをバックアップからFTPで上書き
• プラグインを停止（プラグインフォルダ名を変更）
• 使用中のテーマ（Cocoon）を停止（テーマフォルダ名を変更）
• PHPを7.4（CGI版）に戻して確認したが、改善せず
• .htaccess のファイル名を変更して確認したが、改善せず。404エラーに変わったため、元のファイル名に戻した
• データベースのパスワードを変更し、wp-config.php も更新したが、改善せず
• wp-config.php に以下のデバッグ設定を追加したが、wp-content/debug.log は作成されなかった
  • WP_DEBUG
  • WP_DEBUG_LOG
  • WP_DEBUG_DISPLAY

■ ロリポップサポートへ問い合わせその回答と、その後の状況

ロリポップサポートから、.htaccess のパーミッションが「744」になっているため、「604」に変更するよう案内がありました。

指示どおりパーミッションを変更しましたが、500エラーは解消せず、403エラーに変わりました。

また、エラーの詳細を確認するため、ロリポップから案内された方法でエラーメッセージの表示を試しましたが、詳細なエラーメッセージは表示されませんでした。

■ 現在の状況

• 対象サイト：https://usei116.com/
• PHP：8.3（モジュール版）
• WordPress：最新版
• プラグイン・テーマ：停止中
• .htaccess のパーミッション：604
• トップページに403エラーが表示される
• WordPressの管理画面も正常に利用できない

■ 現在表示されているエラー

403 Error

現在、このページへのアクセスは禁止されています。

■ エラー発生日時

2026年11月2日 14時45分

今回の不具合について、原因として考えられるものや、確認すべき設定・ファイルなどをご教示いただけますと幸いです。

よろしくお願いいたします。

返信先: トップページ以外が404エラーになり、問い合わせページでリダイレクトループが発生する

今、お聞きした内容ですと、プラグインの干渉の可能性がありますね。セキュリティー系のプラグインをご利用ではありませんか？
「サイトヘルス」の機能を使って今一度、ご確認ください。

• WordPress 管理画面の左側のナビゲーションメニュー（黒い帯）
• 「ツール」->「サイトヘルス」に進んでください。
• 「情報」のタブをクリックしてください。そうすると、WordPress や サーバー、データベースという項目があります。ここに書かれている各バージョン情報を共有していただけますか？
• また、「サイト情報をクリップボードにコピー」をクリックすると、一括でクリップボードにコピーすることもできます。

サイトヘルス画面
https://imgur.com/a/5ctKSUx

参考記事: サイトヘルス画面

返信先: トップページ以外が404エラーになり、問い合わせページでリダイレクトループが発生する

浅川様

ご丁寧にご回答いただき、ありがとうございます。

ご指摘を踏まえ、改めて状況を確認しました。

WordPress内では固定ページが公開済みで、URLや書き換えルールも登録されていることを確認できました。

一方、一般の閲覧環境では404エラーが発生しており、Redirectionプラグインによる一時的な302転送も機能しませんでした。現在、この一時設定は無効にしています。

使用サーバーはmixhost（LiteSpeed）、テーマはLightningです。

管理者ログイン中には正常に表示される場合がある一方、未ログイン環境やGoogle Search Consoleでは404になる事例があります。

なお、.htaccess の権限、LiteSpeedの書き換え処理、WAFについては、まだ直接確認できておりません。

現在、mixhostにも調査を依頼しておりますが、技術的な回答は届いていない状況です。

このような場合、WordPress側でさらに確認すべき点がございましたら、ご教示いただけますと幸いです。

お忙しいところ、具体的なご助言をいただき、誠にありがとうございます。

引き続き、よろしくお願いいたします。

返信先: トップページ以外が404エラーになり、問い合わせページでリダイレクトループが発生する

こんにちは。
すでにお試しなられたこと以外で考えられる原因をいくつか箇条書きにします。

• .htaccessファイルのパーミッションが、644 になっているか？
• セキュリティ系・リダイレクト系のプラグインを新しく有効化、またはバージョンアップした直後であれば、該当プラグインを一時的に停止して変化があるか確認してください。
• サーバーの mod_rewrite が有効か確認する
• ApacheなどのWebサーバーで、URL書き換えモジュール mod_rewrite が無効になっていると下層ページにアクセスできません。
• サーバー側のWAF（ウェブアプリケーションファイアーウォール）が有効になっている場合、一時的に無効にして変化があるかを確認してください。

もしお使いのサーバーや、エラー発生の直前に行った操作（サイトの移転やプラグインの更新など） が分かれば教えていただけますか？
もっと有効な助言ができるかもしれません。

トップページ以外が404エラーになり、問い合わせページでリダイレクトループが発生する

WordPressで学習塾のサイトを運営しています。

現在、トップページは表示されますが、下層ページの多くが404エラーになります。また、お問い合わせページではリダイレクトループが発生し、アクセスできません。

固定ページの編集時には503エラーも発生しました。

これまでにパーマリンク設定の再保存、.htaccess、LiteSpeed、SSL、Redirectionプラグインなどの確認を試みましたが、問題が再発しています。

既存の本文・画像・SEO設定を保護したまま、安全に復旧したいと考えています。

考えられる原因と具体的な調査・修復手順について、専門的なご助言をいただけますでしょうか。

よろしくお願いいたします。

返信先: ブロック「ギャラリー」に写真がアップロードできない

ご連絡ありがとうございます。
こちらこそ、解決いただいたようで何よりです！

また何かありましたら、ご遠慮なくご質問くださいませ。

返信先: ブロック「ギャラリー」に写真がアップロードできない

ご連絡ありがとうございます。

試してみる項目を拝見した結果、「他の端末からのアップロード」は試していなかったので、端末を準備してアップロードを行いました。
すると、問題なくアップロードできました。

私が使用しているパソコンは、３２ビットパソコンなので、６４ビットパソコンとは動作結果が違うようです。
ブラウザのバージョンは同じでしたが、３２ビット版と６４ビット版で動作結果が違うということなのでしょう。
原因は私のパソコンにありました。

お忙しい中、お手数をおかけし申し訳ありませんでした。
対応ありがとうございました。

返信先: 本体更新時に Disk quota exceeded が出る（容量には空きあり）

ご連絡ありがとうございます。
解決いただいたようで何よりです！

また何かありましたら、ご遠慮なくご質問くださいませ。

返信先: 本体更新時に Disk quota exceeded が出る（容量には空きあり）

本件、ご丁寧にお返事くださりありがとうございました。

スマイルサーバーの担当者さんから、「ディレクトリの変更は、サイトマネージャーより、php.ini を
編集する必要があります。」とのことで、ご指示通りに行い、wordpressのversionを無事に更新することができました。

現在問題解決しています。
この度は誠にありがとうございました。

返信先: theme.jsonの一部が反映されない

失礼しました。

Create Block Theme プラグインは、テーマのひな型を作成するだけでなく、グローバルスタイル、サイトエディター上のテンプレートの変更をテーマファイルに書き戻し、DB上のグローバルスタイル設定をリセットする、という操作が可能です。そのため、現在もCreate Block Themeを使ってそのような操作をおこなっていないか、原因の切り分けのために確認したかった次第です。

しかし、現在はもう使われていないとの事ですので、私のコメントは無視していただいて構いません。

返信先: theme.jsonの一部が反映されない

Aki Hamano 様

補足です。
理由は既に私が上で申し上げているとおり、本事象は theme.json よりもデータベース上の値が優先されるためでございます。
Create Block Themeを使わずとも、サイトエディター上で一度保存操作をすれば、データベース上に値が保存されますよね？　それ以後に theme.jsonの内容を書き換えても、基本的にはデータベース上の値が優先されるようになっています。
his様（および私）はそのことを言っています。

子テーマか親テーマか、プラグインを使って作成されたテーマかは全く関係ありません。his様がご確認いただいているとおり、デフォルトテーマでも容易に再現可能です。
親テーマのtheme.jsonよりも子テーマのtheme.jsonの値の方が優先されるという違いはありますが、データベース上の値の方がさらに優先度は高いです。

従って、以下は全くの見当違いになります。

Create Block Themeを使わず、直接theme.jsonを含むテーマファイル一式を一から構築してみてはどうでしょうか。

投稿いただく前に、スレッドに書き込まれている内容を今一度ご確認のほどよろしくお願いします。

返信先: theme.jsonの一部が反映されない

Aki Hamano 様
ありがとうございます。

Create Block Themeは、テーマの雛形を作成する目的で初回に使用しただけで、その後は使用していません。現在はプラグイン自体もインストールしておらず、theme.jsonを含むファイルは直接編集しています。

また、他のテーマやTwenty Twenty-Fiveなどのデフォルトテーマでも同じ問題が再現されたことから、テーマファイルを直接一から構築した場合でも、今回のfont-sizeが更新されない問題については同じ状況になると考えています。

返信先: theme.jsonの一部が反映されない

こんにちは。

Create Block Themeでテーマを作っており、theme.jsonを頻繁に更新しています。

まずここの大前提について確認なのですが、Create Block Themeプラグインの基本的な使い方は、「サイトエディターやグローバルスタイルで行った変更をテーマディレクトリに書き戻す」ことを繰り返しながら、テーマを構築していきます。テーマそのものを作ることが目的のプラグインであるため、そもそもデータベースにグローバルスタイルを保存する、ということは行いません。theme.jsonを直接編集することも基本的にありません。

サイトエディター上では、calc()やカスタムプロパティなどが入力できないため、不可となります。

これはつまり、やりたいことがCreate Block Themeプラグインでできる事の範疇を超えていることを意味します。Create Block Themeを使わず、直接theme.jsonを含むテーマファイル一式を一から構築してみてはどうでしょうか。

返信先: theme.jsonの一部が反映されない

補足情報です
おそらく今回の事象は yinaba 様がおっしゃるとおり仕様通りの優先度による問題と思われますが
対応としては、スタイルをカスタムして使用するのを可能な限り避けるのが良いのではないかと思います
theme.json や style.css 等のファイルとして管理する
色・タイポグラフィ・レイアウトなどをカスタムしたい場合は、スタイルセットを切り替える仕組み
スタイルバリエーションを使用する

スタイルバリエーションは、twentytwentyfive 等のテーマが使っているやつです
styles ディレクトリに切り替え用の json ファイルを作成します

theme.json
styles/
blue.json
green.json
dark.json

これでいろいろなスタイルセットから切り替えことができるようになります
ただ、注意点もあります
バリエーションによるグローバルスタイルの切り替えはリセット動作を含んでいます
バリエーション毎にユーザーの追加カスタマイズを自動保存・復元する機能は持っていないので切り替えるとカスタムしたデータは失われてしまいます
２０２２年から指摘されていて未だ未対応で、このような問題もあるのでバリエーションを持たす場合はスタイルをUIでカスタムしないほうが問題を避けれます

https://github.com/WordPress/gutenberg/issues/38333

私ならこの場合どう対応するかなと考えると、スタイルのカスタムや追加CSSは使用せずにtheme.json やバリエーション、style.css 等を使用することでメンテナンスをやりやすい方法を検討するかなと言う感じです
ちょっと脱線してしまったみたいで申し訳ない　(^_^;)

返信先: theme.jsonの一部が反映されない

Global Settings / Styles のキャッシュは、基本的にリクエストをまたいで永続化しないようになっています

自分の記憶では永続化してた気がしたので wp_get_global_stylesheet() のコードを見てみたらオブジェクトキャッシュですね
オブジェクトキャッシュのプラグインを入れてなければ永続化しませんね

不一致が生じる場合の一例として、プラグイン等が高速化のためにグローバルスタイルをキャッシュしてプラグインがそれを使用することで発生した経験はあります
これまた、今回の事象には当てはまらなそうですが一応紹介まで

その時は、DB上のグローバルスタイルデータの更新日時を適切なフックを使用してアップデートし、プラグイン側に更新を検知させてプラグイン側のキャッシュの更新を促して解消させました
ちょっと特殊な例ですが、全プラグイン停止やテーマの変更で違いがでるか確認してみては

    $post_id = WP_Theme_JSON_Resolver::get_user_global_styles_post_id();
    if(!empty($post_id)){
        wp_update_post( ['ID' => $post_id] );
    }

返信先: theme.jsonの一部が反映されない

enomoto celtislab 様

症状からは、ちょっと違っているかもしれませんが、theme.json はキャッシュされていたはずなのですぐに反映されていないのでは？

調べてみましたが、theme.jsonの読み取りは、通常はリクエストごとの判定になるため、リロードやスーパーリロード等行えば基本的にはファイル更新後の値が採用されますね。

また、既に私が上で申し上げている通り、まずは theme.json よりもデータベース上の値が優先されます。そして、実際にデータベース上に値が残っていたため、本事象が発生しておりました。

もう1点、仮にtheme.jsonのキャッシュが残っていたのだとすれば、 "defaultFontSizes": false が更新後に反映される事象とも矛盾が生じるかと思います。

以上のことから、キャッシュ云々は本事象にはあまり関係がありません。

—

Core の実装を見ると、theme_json グループの Global Settings / Styles のキャッシュは、基本的にリクエストをまたいで永続化しないようになっています。そのため、「theme.json を変更したものの、キャッシュの有効期限が切れていないため古い値が残っている」という種類のものではなさそうです。
https://github.com/WordPress/wordpress-develop/blob/6b08132f3f0fd92d813af07247f349d30200071d/src/wp-includes/class-wp-theme-json-resolver.php#L104

また、今回の場合は「スタイルをリセット」すると新しい theme.json の fontSizes が反映されることと、データベース内の Global Styles から該当する fontSizes の値を削除した場合にも反映されることを確認しています（his様が既にお伝えいただいているとおりです）。

テーマ開発時は wp-config.php に define( ‘WP_DEVELOPMENT_MODE’, ‘theme’ );　を記述してキャッシュを無効化してすぐに反映させていたと思います
キャッシュ時間等細かいことは覚えていないのでなんとも言えませんが、WP_DEVELOPMENT_MODE あたりを調べるとなにかわかるかもしれません

おっしゃる通り、define( ‘WP_DEVELOPMENT_MODE’, ‘theme’ ); は theme.json 関連のキャッシュを回避する用途では有効です。

ただし、Global Stylesやデータベース上に保存されたユーザー設定そのものを無効にしたり、theme.json 側の値を優先させたりするものではありません。
そのため、いずれにしても、今回の fontSizes の件については挙動は変わらないのではないかと思います。

返信先: theme.jsonの一部が反映されない

症状からは、ちょっと違っているかもしれませんが、theme.json はキャッシュされていたはずなのですぐに反映されていないのでは？
テーマ開発時は wp-config.php に define( ‘WP_DEVELOPMENT_MODE’, ‘theme’ );　を記述してキャッシュを無効化してすぐに反映させていたと思います
キャッシュ時間等細かいことは覚えていないのでなんとも言えませんが、WP_DEVELOPMENT_MODE あたりを調べるとなにかわかるかもしれません

返信先: theme.jsonの一部が反映されない

ありがとうございます。

 theme.json に設定した値のとおりに手入力で1つ1つ設定いただくことは可能でしょうか？

サイトエディター上では、calc()やカスタムプロパティなどが入力できないため、不可となります。

「空値のプロパティ」という状況で登録されているようです。

誤って数値を編集してしまった場合、元のtheme.jsonに設定されている数値へ戻せなくなるというのは、一般ユーザーからすると結構大きな問題だと思うんですが、このあたりが今後どのように議論されているのか、後で追いかけて確認してみます。

少し工数がかかるのと、機能の性質上、データベースを操作するコードとならざるを得ず、通常は有償対応にてご依頼いただく内容になるかと思います。

はい、データベースから該当箇所を削除、数値の編集を行えばサイトエディターに反映はされます。

ただ、おっしゃるように、工数や、安全性、利便性の観点から、テーマの仕様変更でフォントサイズの追加や数値の変更などががあるたび、データベースを操作すると言うのは現実的ではないですよね。

ブロックテーマはまだ深く触れていないので、もう少し探ってみます。

返信先: theme.jsonの一部が反映されない

連投失礼します。

《参考》
フォントサイズプリセットについても、実装検討時には、他の設定内容同様に個別で「リセット」を設ける案もあったようです。

しかし、「値は Backspace で消せる」「プリセット自体を削除することもできる」といった運用上の理由から、結局は「リセット」を設けない案が採用されたようです。
https://github.com/WordPress/gutenberg/pull/62328#issuecomment-2160082112
https://github.com/WordPress/gutenberg/pull/62328#issuecomment-2178595658

ただし、実装当初も反対意見がなかったわけではありません。
https://github.com/WordPress/gutenberg/pull/62328#issuecomment-2178527702

そのため、今後、his様や上記の反対意見者のような意見が募って提案の形になれば、将来検討し直されることがあるかもしれません。