wordpresswordpress関連RSS

お気に入り登録
wordpress
プラグイン
プラグイン
プラグイン
プラグイン
テーマ
テーマ
プラグイン
wordpress
wordpress
プラグイン
テーマ
プラグイン
wordpress
wordpress
プラグイン
テーマ
テーマこんにちは。
複数の原因が考えられますので、お手数ですが以下の点を確認の上、共有いただけると助かります。
質問
突然失礼いたします。
お世話になります。
現在運用中のWordPressですが、「このページにアクセスする権限がありません。」と出てしまい、ログインできない状態となっております。
管理サイトの方でバージョンアップなどを行った結果と考えられます。
【試みたこと】
・Cookie の有効化
・プラグインの無効化
・テーマの無効化
・ログイン画面用ファイルの新規作成
【使用環境】
サーバ設定の詳細(MySQL と PHP のバージョン他):不明
パソコンのオペレーションシステム / OS:Windows
使っているブラウザ:Google Chrome
問題が発生している WordPress のバージョン:不明(数年間更新していませんでした)
【状況】
ログイン画面サイトは開けますが、ユーザー名とパスワードを入力してログインすると、「このページにアクセスする権限がありません。」と出てしまいます。
ほぼ初心者で専門的な知識があまりなく、どこから手を付ければよいかわからず困っています。
考えられる原因と具体的な調査・修復手順について、ご助言をいただけますでしょうか。
お手数お掛け致しますが、何卒よろしくお願いいたします。
(2026-11-10)お世話になります。
「QR Redirector」のフォルダ名を元に戻し、再有効化しました。
通常通り、閲覧できています。
お2人には、大変お世話になりました。
ありがとうございます。
(2026-11-7)こちらこそ、解決いただいたようで何よりです。
お手すきの際に「QR Redirector」のフォルダ名を元に戻して再有効化いただくとともに、本トピックを解決済みになさってくださいませ。
(2026-11-6)Vektor,Inc.様、yinaba様、ご多忙の中、ご丁寧・ご親切なアドバイス、誠にありがとうございます。
おかげさまで、復旧しました!
このホームページを活用して、頑張ってまいります。
ありがとうございました。心より感謝申し上げます。
※この一週間、右肩が痛かったのですが、一気に痛みが吹き飛びました。
(2026-11-6)ありがとうございます。
最低限、使用を止めるべきなのは以下4点になります。
・Archives Calendar Widget
・WP Social Bookmarking Light
上記2つはセキュリティ上の問題で公開停止、最終更新も相当に古いです。
「instagram-for-wordpress」とあわせてご利用を止めていただき、他の代替プラグインへの移行を強くおすすめします。
こちらも「検証済み最新バージョン:6.4.14」となり、今はもう使えません。
PHP8.0との互換性チェッカーとなっており、既にプラグイン自体がお役御免と考えられますので、こちらも無効化いただくことを強くおすすめします。
まず上で言及した4つの使用を止めていただき、改めてPHP 8.3に変更いただいてもよろしいでしょうか?
その後は @vektor-inc 様のおっしゃる通りにしていただけると良いかと思います。
っていうか、とりあえず PHP7.4にして、プラグイン全部停止して、PHP8.3 くらいに上げて、
それからプラグイン1つずつ有効化していけば、問題のあるやつは有効化できないからそれで良いのではないかなと思います。
8.3にしたところ、同じエラーがでました。
使用中のプラグイン下記のとおり表示されました。
よろしくお願い申し上げます。
○使用中のプラグイン(20)
Advanced Editor Toolsバージョン 5.10.1 (作者: Automattic) | 自動更新無効
Akismet Anti-spam: Spam Protectionバージョン 5.7.2 (作者: Automattic – Anti-spam Team) | 自動更新無効
All in One SEOバージョン 5.0.5 (作者: All in One SEO Team) | 自動更新無効
Archives Calendar Widgetバージョン 1.0.15 (作者: Aleksei Polechin (alek´)) | 自動更新無効
Classic Editorバージョン 1.7.0 (作者: WordPress Contributors) | 自動更新無効
Contact Form 7バージョン 6.1.7 (作者: Rock Lobster Inc.) (最新バージョン: 6.2.4.1) | 自動更新有効
Google Analytics for WordPress by MonsterInsightsバージョン 11.3.0 (作者: MonsterInsights) | 自動更新無効
Instagram for WordPressバージョン 2.1.6 (作者: jbenders) | 自動更新無効
Jetpackバージョン 16.4 (作者: Automattic) | 自動更新無効
OptinMonsterバージョン 2.17.1 (作者: OptinMonster Popup Builder Team) | 自動更新無効
PDF Embedderバージョン 5.0.2 (作者: PDF Embedder) | 自動更新無効
PHP Compatibility Checkerバージョン 1.6.3 (作者: WP Engine) | 自動更新無効
SiteGuard WP Pluginバージョン 1.8.10 (作者: JP-Secure) | 自動更新無効
Smash Balloon Instagram Feedバージョン 6.15.1 (作者: Smash Balloon) | 自動更新無効
Social Feed Galleryバージョン 5.0.13 (作者: QuadLayers) | 自動更新無効
Social Media Feed Gallery for Instagramバージョン 1.5.1 (作者: A WP Life) | 自動更新無効
VK All in One Expansion Unitバージョン 9.124.0 (作者: Vektor,Inc.) | 自動更新無効
WP Mail SMTPバージョン 4.10.3 (作者: WP Mail SMTP) | 自動更新無効
WP Multibyte Patchバージョン 2.9.4 (作者: Seisuke Kuraishi) | 自動更新無効
WP Social Bookmarking Lightバージョン 2.0.7 (作者: utahta) | 自動更新無効
○停止中のプラグイン (1)
QR Redirectorバージョン 2.1.0 (作者: Nikki Blight <nblight@nlb-creations.com>) | 自動更新無効
(2026-11-6)横からすみません。
instagram-for-wordpressは最終更新が11年前かつ既に公開停止となっており、現在のPHPの仕様に適合していない可能性が高いです。
おそらくPHP8.3に切り替えても同じエラーが出てくるかと思います。
他に同じようなプラグインがある可能性が高いので、一旦PHP7.4に戻していただき、ご利用いただいているプラグインを全てお知らせいただけますでしょうか?
※ご利用いただいているプラグインの一覧はサイトヘルス>「情報」タブ>「使用中のプラグイン」から取得可能です。
https://ja.wordpress.org/support/article/site-health-screen/
よろしくお願いいたします。
(2026-11-6)instagram-for-wordpress に問題がありそうですね。
8.3 にしてみてください。
失礼しました。
Create Block Theme プラグインは、テーマのひな型を作成するだけでなく、グローバルスタイル、サイトエディター上のテンプレートの変更をテーマファイルに書き戻し、DB上のグローバルスタイル設定をリセットする、という操作が可能です。そのため、現在もCreate Block Themeを使ってそのような操作をおこなっていないか、原因の切り分けのために確認したかった次第です。
しかし、現在はもう使われていないとの事ですので、私のコメントは無視していただいて構いません。
(2026-9-29)Aki Hamano 様
補足です。
理由は既に私が上で申し上げているとおり、本事象は theme.json よりもデータベース上の値が優先されるためでございます。
Create Block Themeを使わずとも、サイトエディター上で一度保存操作をすれば、データベース上に値が保存されますよね? それ以後に theme.jsonの内容を書き換えても、基本的にはデータベース上の値が優先されるようになっています。
his様(および私)はそのことを言っています。
子テーマか親テーマか、プラグインを使って作成されたテーマかは全く関係ありません。his様がご確認いただいているとおり、デフォルトテーマでも容易に再現可能です。
親テーマのtheme.jsonよりも子テーマのtheme.jsonの値の方が優先されるという違いはありますが、データベース上の値の方がさらに優先度は高いです。
従って、以下は全くの見当違いになります。
Create Block Themeを使わず、直接theme.jsonを含むテーマファイル一式を一から構築してみてはどうでしょうか。
投稿いただく前に、スレッドに書き込まれている内容を今一度ご確認のほどよろしくお願いします。
(2026-9-29)Aki Hamano 様
ありがとうございます。
Create Block Themeは、テーマの雛形を作成する目的で初回に使用しただけで、その後は使用していません。現在はプラグイン自体もインストールしておらず、theme.jsonを含むファイルは直接編集しています。
また、他のテーマやTwenty Twenty-Fiveなどのデフォルトテーマでも同じ問題が再現されたことから、テーマファイルを直接一から構築した場合でも、今回のfont-sizeが更新されない問題については同じ状況になると考えています。
こんにちは。
Create Block Themeでテーマを作っており、theme.jsonを頻繁に更新しています。
まずここの大前提について確認なのですが、Create Block Themeプラグインの基本的な使い方は、「サイトエディターやグローバルスタイルで行った変更をテーマディレクトリに書き戻す」ことを繰り返しながら、テーマを構築していきます。テーマそのものを作ることが目的のプラグインであるため、そもそもデータベースにグローバルスタイルを保存する、ということは行いません。theme.jsonを直接編集することも基本的にありません。
サイトエディター上では、
calc()やカスタムプロパティなどが入力できないため、不可となります。
これはつまり、やりたいことがCreate Block Themeプラグインでできる事の範疇を超えていることを意味します。Create Block Themeを使わず、直接theme.jsonを含むテーマファイル一式を一から構築してみてはどうでしょうか。
(2026-9-29)補足情報です
おそらく今回の事象は yinaba 様がおっしゃるとおり仕様通りの優先度による問題と思われますが
対応としては、スタイルをカスタムして使用するのを可能な限り避けるのが良いのではないかと思います
theme.json や style.css 等のファイルとして管理する
色・タイポグラフィ・レイアウトなどをカスタムしたい場合は、スタイルセットを切り替える仕組み
スタイルバリエーションを使用する
スタイルバリエーションは、twentytwentyfive 等のテーマが使っているやつです
styles ディレクトリに切り替え用の json ファイルを作成します
theme.json
styles/
blue.json
green.json
dark.json
これでいろいろなスタイルセットから切り替えことができるようになります
ただ、注意点もあります
バリエーションによるグローバルスタイルの切り替えはリセット動作を含んでいます
バリエーション毎にユーザーの追加カスタマイズを自動保存・復元する機能は持っていないので切り替えるとカスタムしたデータは失われてしまいます
2022年から指摘されていて未だ未対応で、このような問題もあるのでバリエーションを持たす場合はスタイルをUIでカスタムしないほうが問題を避けれます
https://github.com/WordPress/gutenberg/issues/38333
私ならこの場合どう対応するかなと考えると、スタイルのカスタムや追加CSSは使用せずにtheme.json やバリエーション、style.css 等を使用することでメンテナンスをやりやすい方法を検討するかなと言う感じです
ちょっと脱線してしまったみたいで申し訳ない (^_^;)
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] );
}(2026-9-24)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 はキャッシュされていたはずなのですぐに反映されていないのでは?
テーマ開発時は wp-config.php に define( ‘WP_DEVELOPMENT_MODE’, ‘theme’ ); を記述してキャッシュを無効化してすぐに反映させていたと思います
キャッシュ時間等細かいことは覚えていないのでなんとも言えませんが、WP_DEVELOPMENT_MODE あたりを調べるとなにかわかるかもしれません
ありがとうございます。
theme.jsonに設定した値のとおりに手入力で1つ1つ設定いただくことは可能でしょうか?
サイトエディター上では、calc()やカスタムプロパティなどが入力できないため、不可となります。
「空値のプロパティ」という状況で登録されているようです。
誤って数値を編集してしまった場合、元のtheme.jsonに設定されている数値へ戻せなくなるというのは、一般ユーザーからすると結構大きな問題だと思うんですが、このあたりが今後どのように議論されているのか、後で追いかけて確認してみます。
少し工数がかかるのと、機能の性質上、データベースを操作するコードとならざるを得ず、通常は有償対応にてご依頼いただく内容になるかと思います。
はい、データベースから該当箇所を削除、数値の編集を行えばサイトエディターに反映はされます。
ただ、おっしゃるように、工数や、安全性、利便性の観点から、テーマの仕様変更でフォントサイズの追加や数値の変更などががあるたび、データベースを操作すると言うのは現実的ではないですよね。
ブロックテーマはまだ深く触れていないので、もう少し探ってみます。
(2026-9-22)連投失礼します。
《参考》
フォントサイズプリセットについても、実装検討時には、他の設定内容同様に個別で「リセット」を設ける案もあったようです。
しかし、「値は 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様や上記の反対意見者のような意見が募って提案の形になれば、将来検討し直されることがあるかもしれません。
(2026-9-22)
お気に入り登録