フォーラムへの返信
-
あーすみません！ フックの構文をミスってました。
add_filter( 'snow_monkey_blocks_custom_field_value_カスタムフィールド名', function( $value, $post_id ) { return $value; // ここで好きなフォーマットに変換して返す }, 10, // コールバック関数の優先度 2 // 受け取る引数の数 );add_filter()で引数を2つ受け取る場合は、ちゃんと2つ受け取ると指示しないとだめなので、上記のようなコードになります。Who liked:あ！すみません、
var_dump( $args );は要らないので消してください！function custom_modify_related_posts_query( $args ) { $args['orderby'] = 'date'; $args['order'] = 'DESC'; return $args; } add_filter( 'snow_monkey_related_posts_args', 'custom_modify_related_posts_query' );Who liked:下記だとどうですかね？
function custom_modify_related_posts_query( $args ) { var_dump( $args ); $args['orderby'] = 'date'; $args['order'] = 'DESC'; return $args; } add_filter( 'snow_monkey_related_posts_args', 'custom_modify_related_posts_query' );Who liked:カスタムフィールドにはどのようなデータでも保存できるので、Snow Monkey Blocks のカスタムフィールドブロックでは表示したいカスタムフィールドの指定だけをして、シンプルにそれを出力する、という仕様にしています。
確かにフォーマットを選択できる UI があれば便利かなとは思いますが、あらゆるフォーマットを追加し続けないといけなくなりそうなので、どういう UI が適切か（または僕の技術力的に可能なのか）が難しいかなと感じます。
一応フィルターフックが通るようにはしているので、コードを書けば好きなフォーマットで出力することは可能です。
add_filter( 'snow_monkey_blocks_custom_field_value_カスタムフィールド名', function( $value, $post_id ) { return $value; // ここで好きなフォーマットに変換して返す } );Who liked:キタジマ様の意図する内容：管理画面上で幅と高さが設定されてない(自動)のもの。
私の認識：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 );別ページから、アンカーのある該当ページに移動する場合ですとズレが発生しなかったのですが、この差はページ内とページ外からのリンクで仕組みが異なるからでしょうか？
仕組みは違うのですが、画像が遅延読み込みで読み込まれず高さが保持されていない状態でアンカーに移動するとズレる、という部分は同じ気がするので、ちょっとわからないです…。
Who liked: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 の作者に連絡するのが確実かなと思います。Who liked:ちなみに上記コードまだ試せていないのですが、特に条件分岐など無さそうなので上記コードですと全ての閲覧環境・全てのページで表示されるという理解でよろしいでしょうか？
そうですね、そうなります。
PCやタブレットなどデバイス別（メディアクエリ別？）で表示したり、トップページや特定のページのみ（ページidで指定でしょうか）表示させたいときの条件分岐の書き方など教えていただけると大変有難いです……
「PCやタブレットなど」は CSS でメディアクエリを使って出し分けるのが無難です。「トップページや特定のページのみ」については、WordPress の条件分岐タグを使えば良いです。下記は公式ドキュメント（英語）のページですが、ぐぐったらいろいろでてくるかなと思います！
Who liked: No user
