返信先: WordPressにログインしようとしたら、「このページにアクセスする権限がありません。」と出てきました。

こんにちは。
大変お世話になっております。

お忙しい中、ご返信いただき誠にありがとうございます。

現在、ご質問いただいた件につきまして確認を進めておりますが、詳細の確認にもう少しお時間をいただく見込みです。
ご連絡までお時間をいただいてしまい大変恐縮ですが、確認が取れ次第、改めて詳細をご連絡させていただきます。

ご迷惑をお掛けして大変申し訳ございませんが、何卒ご理解賜りますようお願い申し上げます。

返信先: WordPressにログインしようとしたら、「このページにアクセスする権限がありません。」と出てきました。

ご確認ありがとうございます。

すみません。
PHP のバージョンアップをした時、変更前と変更後のバージョンを教えていただけますか？

PHPバージョンが高すぎる／低すぎる場合、 WordPress本体や使用中のテーマ・プラグインが新しいPHPバージョン（PHP 8.2〜8.4など）に完全に対応していない場合や、古いWordPressのままPHPを上げた場合に発生します。

返信先: WordPressにログインしようとしたら、「このページにアクセスする権限がありません。」と出てきました。

こんにちは。
お世話になっております。

お忙しい中、ご確認・ご返信いただき誠にありがとうございます。
ご返信につきましては、お時間をいただいても問題ございませんので、お手数をおかけいたしますが、引き続きよろしくお願いいたします。

WordPressサイトに複数のユーザーアカウントが存在するか確認いたしましたが、他のアカウントはございませんでした。

また、不具合が発生した経緯について、改めてご説明いたします。
PHPなどのバージョンアップを行った後、通常どおりWordPressサイトを使用していたところ、更新操作を行った際に「このページにアクセスする権限がありません。」というエラーメッセージが表示されました。
その後、再度ログインを試みましたが、同様のエラーメッセージが表示され、現在もログインできない状態が続いております。

なお、他のユーザーアカウントが存在しないため、ご提示いただいた変更作業などは行っておりません。

お手数をおかけいたしますが、状況をご確認のうえ、ご対応いただけますと幸いです。
何卒よろしくお願い申し上げます。

返信先: WordPressにログインしようとしたら、「このページにアクセスする権限がありません。」と出てきました。

お返事が遅くなって申し訳ないです。

細かい部分にこだわるようですが、重要な点ですので、確認させてください。

基本的に一人で運用しております。

WordPress サイトで複数のユーザーアカウントがある場合、管理者権限の方は、他のアカウントの権限を変更できます。
「このサイトでの権限なし」とすることで、アカウントは残るけど、サイトにログインできない、状態となります。

参考
https://imgur.com/a/dcM9bal

このような変更がされていないか、社内でご確認いただけますか？
もちろんそれ以外の要因でログインできない可能性もありますが、まずこの部分で問題の切り分けをしたいです。

返信先: WordPressにログインしようとしたら、「このページにアクセスする権限がありません。」と出てきました。

こんにちは。
お世話になっております。

お忙しい中、ご確認ご返信いただき誠にありがとうございます。

ご質問いただいた内容につきまして、以下のとおり回答させていただきます。

・該当のWordPressサイトはお一人で運用されていますか？
→ 基本的に一人で運用しております。

・直近で、サーバー側のアップデートを行いましたか？（PHPバージョン切り替えやデータベースのバージョン切り替え）
→ PHPのバージョンアップを行った記憶はございます。ただし、現在WordPressにログインできないため、詳細を確認できておりません。

・同様にWordPressのアップデートやテーマ、プラグインの追加・削除を行いましたか？
→ WordPressにログインできなくなる前に、アップデートやテーマ、プラグインの追加・削除などを行った記憶がございます。

・お使いのサーバーはどちらですか？
→ futureshopのCMSサーバー（VPS）を契約しておりますが、こちらが該当するサーバーでお間違いないでしょうか。

お手数をおかけいたしますが、ご確認ご対応のほど何卒よろしくお願い申し上げます。

返信先: WordPressにログインしようとしたら、「このページにアクセスする権限がありません。」と出てきました。

こんにちは。
複数の原因が考えられますので、お手数ですが以下の点を確認の上、共有いただけると助かります。

• テーマやプラグインが起因と思われる不具合の可能性
• WordPress ユーザーアカウントの権限の喪失
• パーマリンクの破損や.htaccess ファイルのエラー

質問

• 該当のWordPress サイトはお一人で運用されていますか？
• 直近で、サーバー側のアップデートを行いましたか？（PHPバージョン切り替えやデータベースのバージョン切り替え）
• 同様にWordPress のアップデートやテーマやプラグインの追加、削除を行いましたか？
• お使いのサーバーはどちらですか？

WordPressにログインしようとしたら、「このページにアクセスする権限がありません。」と出てきました。

突然失礼いたします。
お世話になります。

現在運用中のWordPressですが、「このページにアクセスする権限がありません。」と出てしまい、ログインできない状態となっております。
管理サイトの方でバージョンアップなどを行った結果と考えられます。

【試みたこと】
・Cookie の有効化
・プラグインの無効化
・テーマの無効化
・ログイン画面用ファイルの新規作成

【使用環境】
サーバ設定の詳細（MySQL と PHP のバージョン他）：不明
パソコンのオペレーションシステム / OS：Windows
使っているブラウザ：Google Chrome
問題が発生している WordPress のバージョン：不明（数年間更新していませんでした）

【状況】
ログイン画面サイトは開けますが、ユーザー名とパスワードを入力してログインすると、「このページにアクセスする権限がありません。」と出てしまいます。

ほぼ初心者で専門的な知識があまりなく、どこから手を付ければよいかわからず困っています。
考えられる原因と具体的な調査・修復手順について、ご助言をいただけますでしょうか。

お手数お掛け致しますが、何卒よろしくお願いいたします。

返信先: ワードプレスが表示されない

お世話になります。

「QR Redirector」のフォルダ名を元に戻し、再有効化しました。

通常通り、閲覧できています。

お2人には、大変お世話になりました。

ありがとうございます。

返信先: ワードプレスが表示されない

こちらこそ、解決いただいたようで何よりです。

お手すきの際に「QR Redirector」のフォルダ名を元に戻して再有効化いただくとともに、本トピックを解決済みになさってくださいませ。

返信先: ワードプレスが表示されない

Vektor,Inc.様、yinaba様、ご多忙の中、ご丁寧・ご親切なアドバイス、誠にありがとうございます。

おかげさまで、復旧しました！

このホームページを活用して、頑張ってまいります。

ありがとうございました。心より感謝申し上げます。

※この一週間、右肩が痛かったのですが、一気に痛みが吹き飛びました。

返信先: 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様や上記の反対意見者のような意見が募って提案の形になれば、将来検討し直されることがあるかもしれません。