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

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

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

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

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

お知らせいただきありがとうございました。
内容を確認する限り、サーバー側やプラグインの問題ではなさそうですね。

それでは、試しに以下操作をお試しいただけますでしょうか？

① エラーが出ている画像以外のPNG画像をアップロードいただいて、エラーは起こりませんでしょうか？
② PNG以外の画像（JPEG画像など）でエラーは起こりますでしょうか？
③ 普段ご利用いただいているのとは異なるブラウザ・端末ではお試しいただいておりますでしょうか？
④ シークレットウィンドウ等の環境でアップロードいただいてもエラーは起こりますでしょうか？

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

サイトヘルスを確認しました。次の通りです。

使用中のプラグイン
https://imgur.com/cKLwUHQ

メディア処理
https://imgur.com/vMIsMmd
https://imgur.com/5FJhZ7Y

サーバー
https://imgur.com/eWsJ3il
https://imgur.com/0YZP2Wr

以上よろしくお願いします。

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

早速ご回答ありがとうございます。

次に、管理画面＞ツール＞サイトヘルス＞「情報」タブの画面を開いていただき、以下項目のスクリーンショットをご共有いただけますでしょうか？

1. 使用中のプラグイン
2. メディア処理
3. サーバー

なお、こちらのフォーラムでは直接画像を貼り付けることはできませんので、imgurなどの外部サービスをご利用いただけますと幸いです。

サイトヘルスについては、詳しくは以下をご確認ください。
https://ja.wordpress.org/support/article/site-health-screen/

どうぞよろしくお願いします。

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

ありがとうございます。回答させていただきます。

① 7.1.2にアップデートする前にご利用いただいていたWordPressのバージョンを教えていただけますでしょうか。
>>うろ覚えで申し訳ありませんが、Wordpress6.1だったと思います。PHP7.4でした。

② ご利用いただいているサーバーはどちらになりますでしょうか。
>>VALUE SERVER です。

③ 以下画像の赤枠からだと失敗して、青枠からだと成功するという理解でよろしいでしょうか？
>>そのとおりです。しばらく「アップロード中」のメッセージが出た後、「Webサーバーは……」というメッセージが出る感じです。

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

こんにちは。

原因の切り分けを行いたいため、以下のご質問にお答えいただくことは可能でしょうか？

① 7.1.2にアップデートする前にご利用いただいていたWordPressのバージョンを教えていただけますでしょうか。
② ご利用いただいているサーバーはどちらになりますでしょうか。
③ 以下画像の赤枠からだと失敗して、青枠からだと成功するという理解でよろしいでしょうか？

https://imgur.com/a/NqJJJHR.png

なお、ご参考までに、WordPress 6.8の時点で同様の不具合が起こる旨、不具合報告がなされておりますが、環境要因の可能性もあり、現時点で解決はしていないようです。
https://core.trac.wordpress.org/ticket/63294

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

初めて投稿します。

WordPress7.1.2に更新した後、ブロック「ギャラリー」に写真（png形式）をアップロードすると、「Web サーバーはこの画像に対してレスポンシブな画像サイズを生成できません。アップロードする前に JPEG または PNG に変換してください。」というメッセージが表示され、アップロードできません。

メディアライブラリに同じ写真（png形式）を追加すると、問題なくアップロードでき、ブロック「ギャラリー」に追加することができるのですが、何か対処方法はないでしょうか。

使用している状態
テーマ：Twenty Twenty
PHPバージョン：PHP 8.3
写真のサイズ：718KB

返信先: 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 等を使用することでメンテナンスをやりやすい方法を検討するかなと言う感じです
ちょっと脱線してしまったみたいで申し訳ない　(^_^;)

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

こちらこそ、早速ご返信ありがとうございます。

既にご確認いただいているとは思いますが、ヘルプページには総数制限が設けられている旨のみが記載されており、肝心の上限数値が書かれていないです。
そのため、例えばスマイルサーバ様の上位プランに変更することで制限が緩和されるかについては、一度お尋ねいただいても良いのではないかと思います。
あわせて、不要になったと思われるファイルを削除いただいて状況が改善しないかについても、一度お試しいただけますと幸いです。
ただし、以前は別用途で使われていたかもしれないとのことなので、もし前任者などと連絡がとれるようでしたら、WordPress以外のファイルの内容についてご確認いただけますでしょうか？

もしスマイルサーバ様のサポートからのご回答が要領を得ない、もしくはプランを変更しても上限が変わらないようであれば、いよいよ他社のサービスをご検討いただく必要があるかと思います。
その際には、エックスサーバー様やConoHa WING様など、「WordPress運用に定評がある」かつ「簡単移行サービスが標準で備わっている」ところを検討の中心にしていただくと良いのではないでしょうか。

それでも、最終的には Nishimura 様に決めていただくことですので、対応は慎重に進めていただけますと幸いです。

問題が解決することをお祈り申し上げます。

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

yinaba様

早速のご回答ありがとうございます。
容量制限よりも総数制限を疑うべきとのこと、ありがとうございます。
上記症状の要因を突き止められてはいないのですが、AIでも調べたところ「WordPressになる前の旧サイトのファイルが /wp/ の外側に残っている可能性があります。」という回答で、長年の変遷のなかで、このサーバーは過去に別の用途でも使われていた形跡があるようです。
そのほか、サーバー上のバックアップ、度重なる更新の残骸、そして大量のメールも関わっている可能性がございます。

改善策としては仰る別のサーバーへの移行とはスマイルサーバの別プランでも良いものでしょうか。
もしくは別会社のサービスに切り替えるということになりますでしょうか。
素人なので、移行に伴いサイトが崩れるなどの支障がリスクだと考えているので、移行よりも簡単なプラン変更で済むならそれに越したことはないと考えています。
メールもドメインもそのまま、手続きだけで完了というのが理想的だと思っておりまして。。
もしそのあたりご存知でしたらご教示くださいませ。

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

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

こんにちは。

「NTTスマートコネクト スマイルサーバ」様のヘルプページによれば、ディレクトリ数・ファイル数の総数に制限が設けられているそうです。もし総数制限に引っかかると、ご教示いただいている「Disk quota exceeded」のエラーが出るようになっているとのことです。
https://support.smileserver.ne.jp/ver5/03ftp/ftp01.html

したがって、「一時ディレクトリの容量制限」よりも、まずは総数制限を疑うべきです。WordPressは更新時に一時的にサーバ上に圧縮ファイルを展開しており、そのときに引っかかっているものと思われます。
WordPressは思った以上にファイル数が増えやすく、ファイル数100,000など、割とあっという間に達してしまいます。

今はテーマやプラグインの更新の方はうまくいっているとのことですが、恐らくですが現状の環境だとテーマやプラグインの更新すらままならなくなる可能性がございます。
WordPressのバージョンも6.4と少々古いため、お早めに総数制限の設けられていないサーバーに移行いただくことをおすすめいたします。

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