フォーラムへの返信
-
投稿者投稿
-
んむー、なんでしょうね。
管理画面で選択肢に表示するキーのリストは下記の部分で取得しています。
具体的には、
$wp_meta_keys
というグローバル変数を参照して返却している感じです。register_meta()
で登録したメタキーは$wp_meta_keys
に追加されるので参照できるはずですが、ACF が内部的にregister_meta()
しているのかどうかは気になりますね。ACF に詳しくないためそのあたりは僕はわからないです…。試しに ACF を使わずに、
access
をregister_meta()
で追加したらどうなるか確認してみると良いかもです。♥ 0Who liked: No useriPhone でデフォルトが空欄になるのは仕様みたいです。
初期値を設定すれば、その初期値がデフォルトで表示されるようにはできます。
例えば、初期値として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; } );
♥ 0Who liked: No user2つ目の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 では反映されない可能性が高いです。その点は考慮して独自に調整する必要があると思います。♥ 0Who liked: No userWP Datepicker を使ったことがないのでわかりませんが、iPhone は Mac に繋げば Safari のインスペクターで状況が見れるので、それでエラーがでていないか、Datepicker の script が読み込まれているか等を確認してみると良いかもしれません。
あと、PC では表示されているということなので関係ないかもですが、Snow Monkey Forms は非同期でフォームを読み込むので、jQuery で DOM をカスタマイズする場合は
on()
で処理されるものでないとちゃんと動かないです(多分)。自分で jQuery で書く場合はその点注意が必要です。♥ 0Who liked: No userjQuery のライブラリの利用は推奨されないこと、承知いたしました。
「Snow Monkey(と関連プラグイン)における jQuery ライブラリの利用を推奨していない」ということではなくて、あくまで、僕が長期でメンテナンスをする必要があるプロダクトでは、僕は極力使いたくない、という意味です。念の為。
♥ 0Who liked: No userSnow Monkey Forms の日付ブロックは、HTML 標準の
<input type="date" />
を使っています。MW WP Form のときは入力しやすいようにと、jQuery のライブラリなんかを使って独自の実装をしていたのですが、ライブラリはメンテナンスされなくなることもあるし、不具合があったときに自分では対応できなかったりして、メンテナンスがかなりストレスになっていたので、Snow Monkey Forms では絶対に標準のものを使うと決めて実装しました。
そういう理由で、日付ブロックを標準以外のものに変えることは考えていません。日付ブロックを使わないのであれば、普通のテキストフィールドを入れて class を付与し、独自にカレンダー的なものを実装するとか、そういう感じで実装する形になるのかなと思います。
♥ 0Who 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; } );
ネットワークタブを確認していると、
/wp-admin/post.php?post=15&action=edit
でnet::ERR_HTTP2_PROTOCOL_ERROR 200 (OK)
というエラーが確認できました。また、リロードしてエラーが出なかった場合も、ページの HTML のロードが途中で止まっていて、読み込み中のままになるようです(ブラウザのネットワークタブからページの HTML のプレビューをみると、途中までしか読み込まれていませんでした)。
サーバーのサポートの方にこのエラーメッセージと現象についても問い合わせていただけませんか?
♥ 0Who liked: No userまた、いただいた検証内容について、再現できる場合とできない場合があることが確認できました。
すみません、どの項目がどうだったか具体的に教えてください!
あと、Snow Monkey プラグイン以外のプラグインをすべて停止&テーマを TwentyTwenty◯◯に変更したときにどうなるかも教えてください。
アクセスログについて、 JS ファイルの読み込みは正常に行われているかと思います。
編集画面を操作しながらある程度リアルタイムで確認しないとちょっと確認が難しいですね…。
あと、可能であればエラーログも見せてください!ーーー
こちらの環境では再現できないため、こちらの環境でこれ以上の検証をすることは難しいです。
現象が発生する GoDaddy のサーバーで直接コードを触ったり設定を変更して検証させてもらうことはできますか?
本番サイトだと表示が崩れたりサイトが止まったりするとまずいと思うので、壊しても良い(現象が再現する)テスト環境を用意いただき、そこで直接コードを編集しながら検証させていただけると…。ご検討よろしくお願い致します。♥ 0Who liked: No userエクスポートデータありがとうございます。
Local で PHP 8.2.23 の環境をつくりインポートいたところ、固定ページは問題なく開けました。
強いて言えばブロックの構造を最新にする変換処理がいくつか走っていましたが、この数でフリーズするということも無いとは思うので関係なさそうかなと思います。
やはりそのサーバーでないと問題が再現できないので、色々試すしか無いと思います。
・特定のブロックを使用、保存してから編集をしようとするとページ全体がずっとロードされてしまい画面が白くなる
・現在はフロントページだけ問題が発生して下層ページでは事象は確認できない
・設定からSnow Monkey Blockのセクションの4項目をオフにすると事象は確認できない
・同様にテーマ・Snow Monkey Blockをオフにすると事象は確認できないとのことですが、例えば
– 新規ページにセクションブロックを1つだけ入れて、何も設定変更せず、セクションブロックの中にも何もブロックを入れずに保存し、ページをリロードすると再現するか。
– セクションブロック以外の Snow Monkey Blocks のブロックをすべて無効化し、↑の操作をすると再現するか。
– Snow Monkey テーマ以外のテーマに変更し、セクションブロックだけのページをつくると再現するか。など…。
これで再現するなら確実にセクションブロックが一因であると言えるかなと。ただ他の環境では再現できないので、その場合はやはり WAF に引っかかってしまっていると考えるのが一般的かなと思います。
もしこれらでは再現しないとなればこれもやはりサーバーのメモリ上限が影響していると考えるのが一般的かなと思います。
♥ 0Who liked: No userホスティングには問題がなく、解決につながるようなご返答は得られませんでした。
つまり、WAF に引っかかった形跡や、メモリー不足が発生した形跡はなかったということですかね?
あと、真っ白なままになるのはエディターの描画が完了していない(多分)からなので、エディターの js ファイルのリクエストとレスポンスが完了していないのではないかと疑っています。正しくリクエストされていればアクセスログに記録されると思うのですが、そのあたりはどうでしょうか?
ーーー
先日、
こちら容量を上げてみましたが、エラーが解消しませんでした。
とのことでしたが、上げたのは
max_input_vars
だけでしょうか?
max_input_vars
はinput
の数とか送信するパラメーターの数を云々するものなので、今回の事象とは関係がない気がします(カスタムフィールドをめっちゃ使っているとかなら関係あり)。メモリーが大きい環境だと動作したと書かれていたので、
memory_limit
を上げることが可能であれば試したほうが良いと思います。ーーー
All in One WP Migration プラグインでエクスポートしたデータを共有して頂くことは可能でしょうか?
それが可能であれば、一応こちらの環境ではどうなるか試してみたいです。もしこちらの環境でも再現するようなら詳しく調査ができるので。
♥ 0Who liked: No userURL ありがとうございます。現状のサイトを確認すると、ページヘッダー(
.c-page-header
)が入っていて、それが余白のように見えてしまっているようです。消すときれいに表示されるようになります。デフォルトだとトップページには入らないはずですが、何かカスタマイズが設定をされてたりしますかね?ヘッダーをオーバーレイにすると、スクロール時添付1のように色付きのバーが発生するので、
こちらもイメージ通りではないのです。。。現状は「オーバーレイ」ですよね?
「オーバーレイ(上部固定/スクロール時背景白)」にするとスクロール時にヘッダーの色が白になります。
「オーバーレイ(上部固定)」だとスクロール時も白くなりません。♥ 0Who liked: No userんーヘッダーは普通に全ページ共通のヘッダーですかね?
Snow Monkey はコンテンツにヘッダーを重ねたい場合はカスタマイザーで「ヘッダー位置」をオーバーレイに設定します。
なので「ナビゲーションの次の要素として入れ込むことになるから」は直接的な原因ではないはずです。
「ホームページのコンテンツエリアに上下余白を追加する設定」にチェックが入っていると余白が追加されてしまいますが、その設定はどうなっていますか?
チェックが外れているのに余白が入っている場合は独自のカスタマイズや他の CSS が影響している可能性も考えられるので、実際にページをみて確認必要があるかなと思います。
-
投稿者投稿