ひまわりさん
こんな感じだとどうでしょう？
.smf-action .smf-button-control__control {
background-color: #000;
background-image: initial;
color: #fff;
}
こちらでも確認しましたが、クラス名は .smf-action .smf-button-control__control で問題なさそうなので、これで適応されないとなると、他に要因があると思います。
しかし、このスクリーンショットではそれを推測することが難しいですね…
追伸：
①下記のCSSを記述して検証しましたがダメでした・・・。
height: autoは打ち消している様子なのですが、管理画面上で高さを設定していない状態だと、その分ズレてしまいました。(html上のwidth と heightが優先されない)
.wp-block-image img {
height: ●色々なパターン●;
width: ●色々なパターン● !important;
}
②もしかしたらですが(根拠はないのですが)、imgにloading=”lazy”(遅延読み込み)が自動付与されていますが、decoding=”async”(画像の非同期デコード)も自動付与されていることは関係ないでしょうか？
<figure class="wp-block-image aligncenter size-full sme-animation-fade-in sme-hidden-sm" data-sme-animation-duration="2">
<img loading="lazy" decoding="async" width="1000" height="409" src="http://●●.png" alt="●●" class="wp-image-623" style="object-fit:cover" srcset="https://●●.png 1000w, https://●●.png 300w, https://s●●.png 768w" sizes="(max-width: 1000px) 100vw, 1000px" />
</figure>
ご返信ありがとうございます。
CSS のほうで画像の幅も高さも auto にしている部分があれば、width と height があっても無効化されちゃうと思うので、
なるほど！！！！！
こちらの返信内容で、すごく腑に落ちたかもしれません。
現状、下記のコード最上部にあるCSSが効いており、.wp-block-imageクラス配下にある、すべてのimgに対してスタイルが設定(height: auto;)されているようなので。
これらの高さ＝autoとして設定してあるCSS群の設定を打ちけせれば(height: initial;等で？)、html上に記述された高さが優先＆認識されて、今回の症状が発生しないのかなと思いました。
(検証はしておらず、想定ですが。)
※管理画面上で高さを設定して症状が改善したのは、高さ設定→htmlタグにCSS直書きでオーバーライドされ→height: auto;が打ち消されたから。
(WP6.3以降の仕様じゃなかったら改善しなかった)
.wp-block-image img {
box-sizing: border-box;
height: auto;
max-width: 100%;
vertical-align: bottom
}
html :where(img[class*=wp-image-]) {
height: auto;
max-width: 100%
}
img,video {
height: auto;
max-width: 100%;
vertical-align: middle
}
②ちなみに、あまりよくない＆実際に試してはいないのですが、下記の記述等で画像の読込遅延(Lazy loading)の機能を停止するアプローチでも、今回の症状は改善される可能性はあるのでしょうか？
どうなんでしょう？ 基本的には width・height があれば画像が読み込まれていなくても画像の表示範囲は確保されているとおもているのですが、試してみるのも良いかもしれませんね。
③色々と検索してみたのですが、管理画面上で高さ(CSS)を設定しなくても、最初からhtml上で高さも幅も設定されているのに、画像の専有面積として認識されないのはなぜなのだろうと少し疑問に思ってしまいました。(勉強不足ですみません)
なんですかねー。CSS のほうで画像の幅も高さも auto にしている部分があれば、width と height があっても無効化されちゃうと思うので、もしそういう CSS を追加されているのであればそういう影響はあるかもしれません。
■ちゃんと値が設定されている
width=”330″ height=”365″
※PXでないから？
や、これはこれで問題無いはずです。
ご連絡ありがとうございます。
勉強になります・・・、6.3から仕様が変更になったのですね、確かにうろ覚えではありますが以前はwidth・heightの値が変わったような気がします。
①さっそく頂いた記述を、my-snow-monkey.phpに記述を追加させていただきました、ありがとうございます。
②ちなみに、あまりよくない＆実際に試してはいないのですが、下記の記述等で画像の読込遅延(Lazy loading)の機能を停止するアプローチでも、今回の症状は改善される可能性はあるのでしょうか？改善されたとしても今回のように高さを認識させるようにした方が最善でしょうか？
add_filter( 'wp_lazy_loading_enabled' , '__return_false' );
③色々と検索してみたのですが、管理画面上で高さ(CSS)を設定しなくても、最初からhtml上で高さも幅も設定されているのに、画像の専有面積として認識されないのはなぜなのだろうと少し疑問に思ってしまいました。(勉強不足ですみません)
■ちゃんと値が設定されている
width=”330″ height=”365″
※PXでないから？
【管理画面上で高さを設定してない＝style付与されてない】
<div class="wp-block-column is-vertically-aligned-bottom sme-animation-fade-in is-layout-flow wp-block-column-is-layout-flow" data-sme-animation-duration="2">
<figure class="wp-block-image aligncenter size-full plan1">
<img class="wp-image-638" src="●●.png" sizes="(max-width: 330px) 100vw, 330px" srcset="●●-2.png 330w, ●●-2-271x300.png 271w" alt="" width="330" height="365" />
</figure>
</div>
キタジマ様の意図する内容：管理画面上で幅と高さが設定されてない(自動)のもの。
私の認識：html上でwidth・heightが設定されていないもの。
あ、僕も「html上でwidth・heightが設定されていないもの」という認識でした。
管理画面上の高さが「style=”width:auto;height:355px”」にてhtml上に反映され、u-smooth-scrollの計算式に合算されるというニュアンスで合っていますでしょうか？
あーそうか、今の WordPress って style で width と height が入っちゃうのでした…。これ確か公式の issues でもレスポンシブ対応しようとすると画像が歪んだりするということで報告があっていた気がするので、そのうち良い感じに修正されたら良いなと思っています。コアで修正されるまでの一時的な感じにはなりますが、下記のコードを My Snow Monkey プラグインか子テーマの functions.php に追加すると、デフォルトよりは素直っぽい挙動になるかもしれません。
/**
* Remove width/height of style attribute at core/image.
* For WordPress 6.3.0. Fixed in 6.3.1.
*
* @see https://github.com/WordPress/gutenberg/issues/53555
*/
add_filter(
'render_block_core/image',
function( $block_content, $block ) {
$attrs = $block['attrs'] ?? array();
$w = $attrs['width'] ?? '';
$h = $attrs['height'] ?? '';
if ( $w && preg_match( '@^\d+@ms', $w ) && $h && preg_match( '@^\d+@ms', $h ) ) {
$w = str_replace( 'px', '', $w );
$h = str_replace( 'px', '', $h );
$size_style = "width:{$w}px;height:{$h}px";
$ratio = "{$w}/{$h}";
$block_content = str_replace( $size_style, "aspect-ratio:{$ratio}", $block_content );
}
return $block_content;
},
10,
2
);
別ページから、アンカーのある該当ページに移動する場合ですとズレが発生しなかったのですが、この差はページ内とページ外からのリンクで仕組みが異なるからでしょうか？
仕組みは違うのですが、画像が遅延読み込みで読み込まれず高さが保持されていない状態でアンカーに移動するとズレる、という部分は同じ気がするので、ちょっとわからないです…。
ご連絡ありがとうございます。
以下、検証いたしました。
①2024年2月23日 10:15 AMのキタジマ様が投稿された内容ですが私の理解不足にて齟齬があったかもしれません。
キタジマ様の意図する内容：管理画面上で幅と高さが設定されてない(自動)のもの。
私の認識：html上でwidth・heightが設定されていないもの。
管理画面上で、すべての画像の設定にてheight部分へ「自動」 → 「画像の高さ」を設定する事で挙動が改善されました。
管理画面上の高さが「style=”width:auto;height:355px”」にてhtml上に反映され、u-smooth-scrollの計算式に合算されるというニュアンスで合っていますでしょうか？
(逆に自動のままだと反映されない？)
※高さが固定になると、レスポンシブ調整がちょっと大変な気もします。
(object-fit等で調整してみようかと思いますが)
【高さを設定していないもの】
<div class="wp-block-column is-vertically-aligned-bottom sme-animation-fade-in is-layout-flow wp-block-column-is-layout-flow" data-sme-animation-duration="2">
<figure class="wp-block-image aligncenter size-full plan1"><img class="wp-image-638" src="●●.png" sizes="(max-width: 330px) 100vw, 330px" srcset="●●-2.png 330w, ●●-2-271x300.png 271w" alt="" width="330" height="365" /></figure>
</div>
【高さを設定したもの】
<div class="wp-block-column is-vertically-aligned-bottom sme-animation-fade-in is-layout-flow wp-block-column-is-layout-flow" data-sme-animation-duration="2">
<figure class="wp-block-image aligncenter size-full is-resized plan1"><img class="wp-image-638" style="width: auto; height: 355px;" src="●●.png" sizes="(max-width: 330px) 100vw, 330px" srcset="https:●●-2.png 330w, ●●-2-271x300.png 271w" alt="" width="330" height="365" /></figure>
</div>
②もう一つ補足・確認。
今回、同じページ内でアンカーへ移動する際のみにズレが発生したのですが。
管理画面上にて画像に高さを設定していない状態でも、別ページから、アンカーのある該当ページに移動する場合ですとズレが発生しなかったのですが、この差はページ内とページ外からのリンクで仕組みが異なるからでしょうか？
Snow Monkey Forms の画面遷移は REST API でおこなっているので、Snow Monkey Forms 以外のプラグインやテーマが何らかのエラーを出しているときはそれが影響していて REST API がコケる→画面遷移しない、ということが起こりえます。
当該箇所が PHP 8.1.22 で PHP Warning: Attempt to read property "post_content" on null というエラーを出しますと Table of Contents Plus の作者に連絡するのが確実かなと思います。
ちょっと書いてみました。数値は適当に書き換えてください。
@media (min-width: 640px) {
.c-entries-carousel .spider__canvas {
width: calc(100% + var(--entries--carousel--gap) * 4); // 4 は枚数 - 1
transform: translateX(-10%);
}
.c-entries-carousel .spider__slide {
max-width: calc(20% - var(--entries--carousel--gap));
}
}
ただ、やはり、現状 Swiper でいうアクティブなスライドを中央に配置するような機能が Snow Monkey のスライダーには無いので、無理矢理感はあるかなと思います。他に実現できるプラグインがあるようなら、それを使うほうが安定するのではないかと思います。
これは Table of Contents Plus プラグイン側での対応が必要になるように思えるので、GitHub で公開されているのであればプルリクを送ってみる、またはイシューで本現象を紹介し対応をお願いするなどされてみてはいかがでしょうか？
んーとなると width・height 以外の別の要因ですかねー。一旦コンテンツをガバっと消して、少しずつ戻していきながら都度都度スクロールが正しく動作するか確認していき、正しく動作しないものがでてきたらその場所が原因だとわかるので、さらに具体的に原因を追求していく、という感じで絞り込んでいくのが良いのかなと思います。
ご連絡ありがとうございます。
該当箇所と思われる、商品紹介部分の商品A、商品Bの2ヶ所の画像に横幅と高さを指定してみました。
その後、動作確認いたしましたが、状況に変化はありませんでした。
【該当箇所の記述】
<figure class="wp-block-image aligncenter size-full sme-animation-fade-in">
<img decoding="async" src="●●.png" alt="●●" width="916" height="492"/>
</figure>
※関係ないかもしれませんが、こちらの画像は、カスタムフィールドスイーツと連動させ、ショートコードにて表示させております。
ちなみに上記コードまだ試せていないのですが、特に条件分岐など無さそうなので上記コードですと全ての閲覧環境・全てのページで表示されるという理解でよろしいでしょうか？
そうですね、そうなります。
PCやタブレットなどデバイス別（メディアクエリ別？）で表示したり、トップページや特定のページのみ（ページidで指定でしょうか）表示させたいときの条件分岐の書き方など教えていただけると大変有難いです……
「PCやタブレットなど」は CSS でメディアクエリを使って出し分けるのが無難です。「トップページや特定のページのみ」については、WordPress の条件分岐タグを使えば良いです。下記は公式ドキュメント（英語）のページですが、ぐぐったらいろいろでてくるかなと思います！
width・height が指定されていない画像に、width・height を指定するとどうなりますか？
