フォーラムへの返信
-
投稿者投稿
-
あ、すみません、今気づいたのですが、最近の投稿ブロックの各項目は
a
要素で囲ってあるから、タグにリンクを貼ることはできないですね。HTML の仕様的にa
は入れ子にできないので。なのでリンクさせるのはやめてこういう形にしたほうが良いかなと思います。<a href="<?php echo esc_url( get_term_link( $post_tag_term ) ); ?>"><?php echo esc_html( $post_tag_term->name ); ?></a>
↓
<span><?php echo esc_html( $post_tag_term->name ); ?></span>
リプライするときに整形されるから?なのかコードが崩れているので整形してみました。
あと、コードの途中にちゃんとタグの情報が取得できているか確認するために
var_dump(...);
を追加してみました。ちゃんと取得できているならタグの情報が画面上に表示されるはずです。表示されないなら紐づけができていないか、名前が間違っている可能性がありそうです。add_filter( 'snow_monkey_template_part_render_template-parts/loop/entry-summary/title/title', function ($html) { // カスタムフィールドで設定したフィールド名を代入 $acf_name_area = get_field('name_area'); $acf_region_area = get_field('region_area'); $acf_specialty_genre = get_field('specialty_genre'); // テンプレートのh3タグの後に <div class="property-info">を追加 $acf_property_info = '</h3><div class="property-info">' . '<div class="property-body">' . '<div class="property-content">' . '<dl class="name_area"><span>【代表者名】</span> <dt>' . esc_html($acf_name_area) . '<dt></dl>' . '<dl class="region_area"><span>【地域】</span> <dt>' . esc_html($acf_region_area) . '<dt></dl>' . '<dl class="specialty_genre"><span>【取扱業務】</span> <dt>' . esc_html($acf_specialty_genre) . '<dt></dl>' . '</div>' . '</div>' . '</div>'; // テンプレートパーツのh3タグの後ろにdivタグを追加する $html = str_replace( '</h3>', $acf_property_info, $html ); return $html; // テンプレートパーツのh3タグの後ろにdivタグを追加する $html = str_replace( '</h3>', $acf_property_info, $html ); // 記事に紐づいている post_tag の各タームのアーカイブページへのリンクを表示する $post_tag_terms = get_the_terms(get_the_ID(), 'administrative_scrivener_tag'); var_dump( $post_tag_terms ); // テスト用 ob_start(); if (is_array($post_tag_terms)) { foreach ($post_tag_terms as $post_tag_term) { ?> <a href="<?php echo esc_url( get_term_link( $post_tag_term ) ); ?>"><?php echo esc_html( $post_tag_term->name ); ?></a> <?php } } $administrative_scrivener_tags = ob_get_clean(); var_dump( esc_html( $administrative_scrivener_tags ) ); // テスト用 $html = $html . $administrative_scrivener_tags; return $html; } );
その記事に紐づく任意のタクソノミーのタームを取得する関数
get_the_terms()
を使う形になると思います。// テンプレートパーツのh3タグの後ろにdivタグを追加する $html = str_replace( '</h3>', $acf_property_info, $html ); // 記事に紐づいている post_tag の各タームのアーカイブページへのリンクを表示する ob_start(); $post_tag_terms = get_the_terms( get_the_ID(), 'post_tag' ); if ( is_array( $post_tag_terms ) ) { foreach ( $post_tag_terms as $post_tag_term ) { ?> <a href="<?php echo esc_url( get_term_link( $post_tag_term ) ); ?>"><?php echo esc_html( $post_tag_term->name ); ?></a> <?php } } $html = $html . ob_get_clean();
「News」と「お知らせ」2つのカテゴリーを割り当てているのではなく、「お知らせ」がスラッグということですかね?
基本的には割り当てているカテゴリーのうちの1つが表示されるようになっているので、何らかのカスタマイズが影響している可能性があるのではないかと思います。My Snow Monkey プラグインや子テーマの
functions.php
等に、独自のコードを追加している場合は、一度全部消してみたらどうなるか確認してみてください!♥ 0いいねをした人: 居ません変更を入れたバージョン(v10.0.0 Beta1)を共有します!
内部のデータの持ち方を変えないといけなかったので、いきなりアップデートして互換性的に問題があるとまずいので、一旦こちらで共有させてください。1つ目のラジオボタンの UI で必須にしていて2つ目では必須にしていないというときに、2つ目の設定で上書きされて必須チェックが何も通らなくなるので、
一応、完全に上書きされるとやっぱりわかりにくいので、UI と実際のバリデーションが(できる範囲で)一致するように調整してみました(同じ name を持つ中で post された順で判定するようにしています)。
確認お願いします!
これ確か入力以外の画面は name に紐づいてデータを管理しているのに、入力だけ違ってたので統一させた、という感じだったと思います。だから複雑さを減らしてわかりやすくしたりメンテナンスしやすくするという意味では正しい変更だと考えているのですが、まぁそういう配置にしたいという場合ってありますよね…うーん。
とりあえずなるべく今の実装を活かしたまま、同名の入力項目を設置できるようにできないか試してみたいと思います。
が、一点、バリデーションについては name に紐づくので、同名の入力項目を設置した場合、一番後の入力項目に設定したバリデーション設定で他の同名の入力項目のバリデーション設定は上書きされてしまう、という挙動にはなると思います(多分 6.2.0 段階でもそうだったはず)。
一応差分貼っときます。
子テーマで普通にテンプレートパーツを上書きすることももちろん可能ですが、今後のメンテナンスを考えると My Snow Monkey プラグインか、子テーマを使っているなら子テーマの
functions.php
にコードを書くのが良いです。下記でどうでしょうか?
add_filter( 'snow_monkey_get_template_part_args_template-parts/header/site-branding', function( $args ) { $args['vars']['_title_tag'] = 'p'; return $args; } );
返信に気づかず遅くなってしまいました、すみません。
/wp-includes/rest-api/index.php
にアクセスがあったけどファイルが存在しない、というエラーなのかなと。ただ、/wp-includes/rest-api/index.php
というファイルはそもそも存在しないみたいなので、今回の件とは多分関係ない気がします。「APIについてのエラー」とのことですが、API とは一見関係なさそうなエラーが関係あったりすることもあると思うので、エラーが発生した日時付近(時間までわからないければその日)に発生したエラーは全部確認したほうが良いのかなと思います。
♥ 0いいねをした人: 居ませんエックスサーバーで問い合わせフォームから送信できないという現象についてぐぐってみると、どれも REST API の制限解除で送信できるようになったと書いてありますね…。下記の例は Contact Form 7 ですが、内部的には Snow Monkey Forms と同じ WordPress 本体のメール送信関数を使っていると思うので、理屈としては同じだと思います。
例:
REST API アクセス制限を解除しても送れないとなるとちょっとわかりませんが、エラーが発生したときにサーバーのエラーログにもう少し詳細なログが残っているかもしれないので、エラーログを確認してみてください。
♥ 0いいねをした人: 居ません購入者側でカスタマイズが全くされていない場合は、エラーを1つずつ修正していく必要はないということでしょうか?
全くされていない場合は必要ありません。
ただ、アップデートにバグが含まれている場合、かつ、そのバグを修正するアップデートも実行できない場合は、管理画面からのワンクリックアップデートではなく zip ファイルアップロードによるアップデートをお願いする、のような対応をお願いすることはあり得ます。
あと、ブロックについてはプラグインやテーマのアップデートだけでは HTML 構造をアップデートすることができない(WordPress の仕様)ため、ブロックの HTML 構造のアップデートが必要な場合は、プラグインやテーマのアップデートの後にページの編集画面を開き、更新ボタンを押してください(WordPress の仕様で、編集画面を開いた段階でそのページ上のブロック HTML 構造がアップデートされる)、とご案内することもあり得ます。
テーマのアップデートの際にファイルの更新が必要な個所を教えてください。
アップデートのたびに、どの箇所に変更や修正が入ったか、お知らせ記事を書いています。
例えば、v14.0.0 へのアップデートの場合、
Framework\Helper::has_category_thumbnail()
が廃止されてFramework\Helper::has_term_thumbnail()
に変わることを案内しています。なのでアップデート前に記事を確認して、独自に追加しているコードの中でFramework\Helper::has_category_thumbnail()
を使用している場合はFramework\Helper::has_term_thumbnail()
に書き換える必要があります。また、Snow Monkey テーマと Snow Monkey Blocks などのプラグインは全てのコードの変更履歴を GitHub で公開しています。お知らせ記事に全てのコードの変更履歴を書くのはわかりにくいので概要を書いていますが、独自のゴリゴリにカスタマイズしている場合は概要だけでは必要な全てがわからない場合がありえます。そういう場合は GitHub の変更履歴を見ると細かいところまで全て確認できます。
※右側の「745d533」などの英数字の羅列の部分をクリックすると、その時点のコードレベルでの変更履歴が確認できます。
♥ 0いいねをした人: 居ません前提として、Snow Monkey ChildはSnow Monkeyのテーマには不要なもので、
「Snow Monkey を動作させるため」には必須ではありません。
他のテーマの場合、テンプレートを上書きする場合には子テーマが必須です。
Snow Monkey は子テーマがなくてもテンプレートの上書きや出力される HTML を書き換えることができる機能があるので子テーマは必須ではありません。必須ではない、という意味で言えば不要ですが、にテンプレートの上書きをする場合は「一般的には」子テーマでおこなうものなので、Snow Monkey 独自の方法を使わずに、自分がわかりやすい方法でやりたいということで子テーマを使われる方はいらっしゃると思います。そういう意味では、子テーマも使えるようにしておく、という意味では不要とは言い切れないです。
Snow Monkey公式が作ったものではないので関与しません(ただし善意で相談には乗りますよ)ということなのでしょうか?
基本的にはそのようなスタンスになります。
細かく言えば、子テーマを使わずに Snow Monkey をカスタマイズするための My Snow Monkey プラグインは僕がつくって公開しているものですが、そこにユーザーさんが独自に追加したコードについて僕が責任を負うことはありません(制限なくなんでも自由に書けるから、そもそも負うことができません)。だから「Snow Monkey 公式が作ったものではない」から、というよりは、「ユーザーさんが独自に追加したファイルやコードだから」というのがより正確な表現になります。
購入者側でカスタマイズしたものを除く部分でも都度子テーマ内の記述の変更が必要なのであれば、
前述したように、ユーザーさんが独自に追加したファイルやコードはカスタマイズになります。僕にはなぜそのファイルを追加したのか、そのコードを書いたのかはわからないので…。また、「都度」変更の必要はありません。変更しなければならいときだけ変更することになります。
繰り返しになりますが、「Snow Monkey Child から不要(= 上書きする必要がない)なファイルを削除する」のが先決だと思います。もし必要なファイルが少しだけなら変更作業も減らせることになります。
どこをカスタマイズ(Snow Monkey からファイルをコピーしてきて書き換え)されたかはご自身がわかっていると思うので、前述の手順で作業をおこない(手順はあくまで「僕ならこうする」というものなのです)、Snow Monkey Child から不要なファイルを削除してみてください(もとに戻せるように必ずバックアップは残しておいたほうが良いです)。♥ 0いいねをした人: 居ません -
投稿者投稿