フォーラムへの返信
-
試してみましたが、僕の環境だと正しく
LIKEになっているようでした。
クエリーをカスタマイズするコードを既に追加されているのであれば、一旦それを全部消してみると変化があるか確認してみてください。
Who liked: No userと、ここまで書いて気づきましたが、「3：Snow Monkey Search 「カスタムフィールド検索」ブロック」にかかれているように、「比較」は「LIKE」にされてるんですよね？
それなのに SQL では
INになっちゃうというのであれば、Snow Monkey Search 側に不具合があるのかな…？Who liked: No user1：Snow Monkey Search の「カスタムフィールド検索」ブロックは、ACFの複数選択チェックボックス（値がシリアライズされた配列としてDBに保存される）の値を、上記のような LIKE 検索で正しく絞り込むための標準的な設定方法（「タイプ」や「比較」の適切な組み合わせなど）はございますでしょうか。
本来だと同じキーのメタデータが複数登録された状態になるので、シリアライズして保存するというのが ACF の独自仕様なんですよね。なのでこれをどうにかする標準的な方法というのはなくて（強いて言えば標準的な形でメタデータを保存するプラグインに乗り換える）、基本的にはご想像の通りフックでクエリーを書き換えるという形になるのかなと思います。
Snow Monkey Search の場合だと
pre_get_postsよりsnow_monkey_search_pre_get_postsを使うほうが良いです。僕もやったことがないのでわからないのですが、
meta_queryの部分を参照して、書き換えた必要なメタキーが含まれていたら書き換えるというアプローチになるのかなぁと想像します。が、Snow Monkey Search の他に ACF にネイティブに対応している検索系プラグインがあるようなら、それを使うほうがリスクは低いかもですね…。
Who liked: No userんむー、なんでしょうね。
管理画面で選択肢に表示するキーのリストは下記の部分で取得しています。
具体的には、
$wp_meta_keysというグローバル変数を参照して返却している感じです。register_meta()で登録したメタキーは$wp_meta_keysに追加されるので参照できるはずですが、ACF が内部的にregister_meta()しているのかどうかは気になりますね。ACF に詳しくないためそのあたりは僕はわからないです…。試しに ACF を使わずに、
accessをregister_meta()で追加したらどうなるか確認してみると良いかもです。Who liked: No user２つ目のURLがリンク切れで閲覧できません 汗
すみません、貼り直しました。
いえ、それもそうなのですが、シンプルにSM formの日付ブロックを設置すると、スマホブラウザで閲覧できないのです。
日付ブロックを入れたフォームをつくり、iPhone (iOS 18.4)の Safari と Chrome で閲覧してみました。テキストフィールドが表示され（初期値未入力のため空欄で表示されています）、クリックするとカレンダー UI がポップアップ表示されました。
別トピックでも書きましたが、これは HTML 標準の日付フィールドであり、もしこれが表示されないのであれば、Snow Monkey Forms の不具合ではなく、HTML やブラウザの仕様、あるいは他の独自に追加している JS や CSS の干渉の可能性が高いと思います。
別トピックで書いたことの繰り返しになりますが、MW WP Form のときは入力しやすいようにと、jQuery のライブラリなんかを使って独自の実装をしていたのですが、ライブラリはメンテナンスされなくなることもあるし、不具合があったときに自分では対応できなかったりして、メンテナンスがかなりストレスになっていたので、Snow Monkey Forms では絶対に標準のものを使うと決めて実装しています。なので Snow Monkey Forms の日付ブロックが HTML 標準ではないリッチなものにすることはありません。
ググったら独自にリッチな入力 UI になるようにカスタマイズしている事例がいくつか確認できました。必要に応じて、それを参考に実装してみてください。
なお、これも繰り返しになりますが、jQuery を使っていて、かつ古い記事だと
on()を使っていない場合があり、その場合は現行の Snow Monkey Forms では反映されない可能性が高いです。その点は考慮して独自に調整する必要があると思います。Who liked: No usersnow_monkey_template_part_render_footerフィルターフックでフッターの HTML をカスタマイズできます。同期パターンの場合は
apply_filters( 'the_content', '<!-- wp:block {"ref":19703} /-->' )という形でテンプレートから呼び出せます。これを組み合わせて、下記のようなコードでフッターの上部に同期パターンを呼び出せるかなと。My Snow Monkey プラグインにコードを追加して試してみてください！
※
refのところの番号はご自身の環境にあわせて変えてください。僕は記事の編集画面で表示したいパターンを配置して、コードエディターに切り替えて確認しました。add_filter( 'snow_monkey_template_part_render_footer', function( $html ) { return apply_filters( 'the_content', '<!-- wp:block {"ref":19703} /-->' ) . $html; } );Who liked:エクスポートデータありがとうございます。
Local で PHP 8.2.23 の環境をつくりインポートいたところ、固定ページは問題なく開けました。
強いて言えばブロックの構造を最新にする変換処理がいくつか走っていましたが、この数でフリーズするということも無いとは思うので関係なさそうかなと思います。
やはりそのサーバーでないと問題が再現できないので、色々試すしか無いと思います。
・特定のブロックを使用、保存してから編集をしようとするとページ全体がずっとロードされてしまい画面が白くなる
・現在はフロントページだけ問題が発生して下層ページでは事象は確認できない
・設定からSnow Monkey Blockのセクションの4項目をオフにすると事象は確認できない
・同様にテーマ・Snow Monkey Blockをオフにすると事象は確認できないとのことですが、例えば
– 新規ページにセクションブロックを1つだけ入れて、何も設定変更せず、セクションブロックの中にも何もブロックを入れずに保存し、ページをリロードすると再現するか。
– セクションブロック以外の Snow Monkey Blocks のブロックをすべて無効化し、↑の操作をすると再現するか。
– Snow Monkey テーマ以外のテーマに変更し、セクションブロックだけのページをつくると再現するか。など…。
これで再現するなら確実にセクションブロックが一因であると言えるかなと。ただ他の環境では再現できないので、その場合はやはり WAF に引っかかってしまっていると考えるのが一般的かなと思います。
もしこれらでは再現しないとなればこれもやはりサーバーのメモリ上限が影響していると考えるのが一般的かなと思います。
Who liked: No user
