メインコンテンツへ移動

キタジマ タカシ

フォーラムへの返信

15件の投稿を表示中 - 1 - 15件目 (全7,472件中)
  • 投稿者
    投稿
  • アバター画像キタジマ タカシ
    参加者
    2586

    Advanced Custom Fields (ACF) プラグインを使って作成されたフィールドでしょうか?
    それとも、ACFを使わずにWordPressの標準機能で追加されたカスタムフィールドでしょうか?

    ACF ではなくて、register_meta() で追加したものです。

    Snow Monkey Search のクエリー操作を見直していて気づいたのですが、検索ボックスから特定のキーに対して複数の値が送信されてきたとき(例:チェックボックスで複数のチェックがされたとき)は、強制的に IN になるようにしてるみたいでした。

    なんで、チェックボックス検索にされているのならこれが影響しているのかも?これを消したらどうなるか一度試してみてください!

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    試してみましたが、僕の環境だと正しく LIKE になっているようでした。

    クエリーをカスタマイズするコードを既に追加されているのであれば、一旦それを全部消してみると変化があるか確認してみてください。

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    と、ここまで書いて気づきましたが、「3:Snow Monkey Search 「カスタムフィールド検索」ブロック」にかかれているように、「比較」は「LIKE」にされてるんですよね?

    それなのに SQL では IN になっちゃうというのであれば、Snow Monkey Search 側に不具合があるのかな…?

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    1: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 にネイティブに対応している検索系プラグインがあるようなら、それを使うほうがリスクは低いかもですね…。

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    んむー、なんでしょうね。

    管理画面で選択肢に表示するキーのリストは下記の部分で取得しています。

    具体的には、$wp_meta_keys というグローバル変数を参照して返却している感じです。register_meta() で登録したメタキーは $wp_meta_keys に追加されるので参照できるはずですが、ACF が内部的に register_meta() しているのかどうかは気になりますね。ACF に詳しくないためそのあたりは僕はわからないです…。

    試しに ACF を使わずに、accessregister_meta() で追加したらどうなるか確認してみると良いかもです。

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    iPhone でデフォルトが空欄になるのは仕様みたいです。

    初期値を設定すれば、その初期値がデフォルトで表示されるようにはできます。
    例えば、初期値として 2020-01-01 と入力すれば、空欄ではなく 2020-01-01 が表示されます。

    決め打ちではなくて動的に、例えばフォームを表示した時点の日付を表示したい場合はコードを書く必要があります。

    add_filter(
    	'snow_monkey_forms/control/attributes',
    	function( $attributes ) {
    		if ( isset( $attributes['name'] ) && '任意の name 属性値' === $attributes['name'] ) {
    			$attributes['value'] = wp_date( 'Y-m-d' );
    		}
    		return $attributes;
    	}
    );
    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    2つ目の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 では反映されない可能性が高いです。その点は考慮して独自に調整する必要があると思います。

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    WP Datepicker を使ったことがないのでわかりませんが、iPhone は Mac に繋げば Safari のインスペクターで状況が見れるので、それでエラーがでていないか、Datepicker の script が読み込まれているか等を確認してみると良いかもしれません。

    あと、PC では表示されているということなので関係ないかもですが、Snow Monkey Forms は非同期でフォームを読み込むので、jQuery で DOM をカスタマイズする場合は on() で処理されるものでないとちゃんと動かないです(多分)。自分で jQuery で書く場合はその点注意が必要です。

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    jQuery のライブラリの利用は推奨されないこと、承知いたしました。

    「Snow Monkey(と関連プラグイン)における jQuery ライブラリの利用を推奨していない」ということではなくて、あくまで、僕が長期でメンテナンスをする必要があるプロダクトでは、僕は極力使いたくない、という意味です。念の為。

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    Snow Monkey Forms の日付ブロックは、HTML 標準の <input type="date" /> を使っています。

    MW WP Form のときは入力しやすいようにと、jQuery のライブラリなんかを使って独自の実装をしていたのですが、ライブラリはメンテナンスされなくなることもあるし、不具合があったときに自分では対応できなかったりして、メンテナンスがかなりストレスになっていたので、Snow Monkey Forms では絶対に標準のものを使うと決めて実装しました。

    そういう理由で、日付ブロックを標準以外のものに変えることは考えていません。日付ブロックを使わないのであれば、普通のテキストフィールドを入れて class を付与し、独自にカレンダー的なものを実装するとか、そういう感じで実装する形になるのかなと思います。

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    snow_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;
    	}
    );
    1
    Who liked:
    アバター画像キタジマ タカシ
    参加者
    2586

    解決して良かったです!
    トピックのクローズをお願いしますm(__)m

    1
    Who liked:
    アバター画像キタジマ タカシ
    参加者
    2586

    ネットワークタブを確認していると、

    /wp-admin/post.php?post=15&action=editnet::ERR_HTTP2_PROTOCOL_ERROR 200 (OK) というエラーが確認できました。

    また、リロードしてエラーが出なかった場合も、ページの HTML のロードが途中で止まっていて、読み込み中のままになるようです(ブラウザのネットワークタブからページの HTML のプレビューをみると、途中までしか読み込まれていませんでした)。

    サーバーのサポートの方にこのエラーメッセージと現象についても問い合わせていただけませんか?

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    また、いただいた検証内容について、再現できる場合とできない場合があることが確認できました。

    すみません、どの項目がどうだったか具体的に教えてください!

    あと、Snow Monkey プラグイン以外のプラグインをすべて停止&テーマを TwentyTwenty◯◯に変更したときにどうなるかも教えてください。

    アクセスログについて、 JS ファイルの読み込みは正常に行われているかと思います。

    編集画面を操作しながらある程度リアルタイムで確認しないとちょっと確認が難しいですね…。
    あと、可能であればエラーログも見せてください!

    ーーー

    こちらの環境では再現できないため、こちらの環境でこれ以上の検証をすることは難しいです。
    現象が発生する GoDaddy のサーバーで直接コードを触ったり設定を変更して検証させてもらうことはできますか?
    本番サイトだと表示が崩れたりサイトが止まったりするとまずいと思うので、壊しても良い(現象が再現する)テスト環境を用意いただき、そこで直接コードを編集しながら検証させていただけると…。ご検討よろしくお願い致します。

    0
    Who liked: No user
    アバター画像キタジマ タカシ
    参加者
    2586

    エクスポートデータありがとうございます。

    Local で PHP 8.2.23 の環境をつくりインポートいたところ、固定ページは問題なく開けました。

    強いて言えばブロックの構造を最新にする変換処理がいくつか走っていましたが、この数でフリーズするということも無いとは思うので関係なさそうかなと思います。

    やはりそのサーバーでないと問題が再現できないので、色々試すしか無いと思います。

    ・特定のブロックを使用、保存してから編集をしようとするとページ全体がずっとロードされてしまい画面が白くなる
    ・現在はフロントページだけ問題が発生して下層ページでは事象は確認できない
    ・設定からSnow Monkey Blockのセクションの4項目をオフにすると事象は確認できない
    ・同様にテーマ・Snow Monkey Blockをオフにすると事象は確認できない

    とのことですが、例えば

    – 新規ページにセクションブロックを1つだけ入れて、何も設定変更せず、セクションブロックの中にも何もブロックを入れずに保存し、ページをリロードすると再現するか。
    – セクションブロック以外の Snow Monkey Blocks のブロックをすべて無効化し、↑の操作をすると再現するか。
    – Snow Monkey テーマ以外のテーマに変更し、セクションブロックだけのページをつくると再現するか。

    など…。

    これで再現するなら確実にセクションブロックが一因であると言えるかなと。ただ他の環境では再現できないので、その場合はやはり WAF に引っかかってしまっていると考えるのが一般的かなと思います。

    もしこれらでは再現しないとなればこれもやはりサーバーのメモリ上限が影響していると考えるのが一般的かなと思います。

    0
    Who liked: No user
15件の投稿を表示中 - 1 - 15件目 (全7,472件中)

ドキュメント

Snow Monkey の設定方法やマニュアルを掲載しています。

ドキュメント

フォーラム

Snow Monkey の使い方やカスタマイズについてのご質問・ご要望等はサポートフォーラムで行っています。サポートフォーラムは誰でも閲覧できますが、書き込みできるのは Snow Monkey 購入者のみとなります。

サポートフォーラム

よくあるご質問

Snow Monkey のサービスについて不明な点がある場合は、まずはよくあるご質問をご確認ください。

よくあるご質問

お問い合わせ

よくあるご質問を見ても解決しなかった場合、試用版の申請については問い合わせフォームからお願いいたします。

お問い合わせ

Snow Monkey は Gutenberg ブロックエディターに対応した 100%GPL の WordPress テーマです。拡張性を意識した開発をおこなっており、カスタマイザーとブロックでスピーディーにサイトを立ち上げるだけでなく、CSS やフックを駆使した高度なカスタマイズにも柔軟に対応できます。