- このトピックには12件の返信、2人の参加者があり、最後に
により3年、 2ヶ月前に更新されました。
-
投稿
-
【お使いの Snow Monkey のバージョン】13.1.1
【お使いの Snow Monkey Blocks のバージョン】10.3.0
【お使いの Snow Monkey Editor のバージョン】 4.0.1
【お使いのブラウザ】Google Chrome
【当該サイトのURL】https://slowbiyori.com### 発生している問題
任意のタクソノミーの投稿で「カスタム投稿タイプ」を読み込んだとき、
以前までは投稿タイプのスラッグ名が「c-entry-summary–posttype」のように出力されていたかと思うのですが、最近のアップデートあたりから「post」判定になってしまうようです。### 試したこと
▼添付が該当するページになります。
◎ページURL
▼また、カスタム投稿タイプの「アーカイブページ」ではスラッグ名が反映されました。
◎ページURL
テスト環境にテーマ（12.1.3）、snow monkey blocks（10.0.1）の環境があるのですが、
そのどちらにも投稿タイプスラッグが出力されている状態でした。スラッグ名を基にCSSでデコレーションをすることがあるため、調査いただけるとうれしいです。
どうぞよろしくお願いいたします！いいねをした人: 居ませんあーなるほどです。この部分、v13 から挙動が少し変わっていて、カスタマイザー → カスタム投稿アーカイブ設定 → ビューテンプレートで「投稿（= post）」を選んでいる場合は
.c-entry-summary–-postになるようになりました。ビューテンプレートを「投稿」にしたということは、一覧部分の表示も投稿に合わせたいという需要のほうが多いだろうという意図でした。元にもどしたら戻したら不都合がある方もいると思うので、
.c-entry-summary–-{ビューテンプレートで選んだ投稿タイプ} .c-entry-summary--type-{実際の投稿タイプ}のように変更しようかなと思います。次のアップデートで変更を入れようと思うのでしばしお待ちください…！いいねをした人: 居ませんご返信ありがとうございます！
通常の「投稿」では1カラム（スリム）を選んでいまして、スリムな状態なのですが、このままですとカスタム投稿タイプでもスリムになってしまうことから、
デザインの事情もあり、カスタム投稿タイプで表示するテンプレートをフックで「one-column」に設定している状態です。また、カスタマイザーの方ではとくに設定せず「デフォルト」でした。
add_filter( 'snow_monkey_layout', function( $layout ) { if ( is_singular( 'feature' ) ) { return 'one-column'; } return $layout; } );▼添付
いいねをした人: 居ませんなるほど！
ということはビューテンプレートとは違うところでなにか不具合があるかもですね。「投稿」に feature のタクソノミーのブロックを挿入されているので、もしかしたら元の記事の投稿タイプ（= post）が任意のタクソノミーブロックに反映されてしまう、的な不具合があるのかもしれません。調査してみます！いいねをした人: 居ません調査ありがとうございます！
Bookshelf、pickup、aboutについてですが、
投稿記事にブロックで配置しているのではなくフックで挿入しております。挿入方法は下記のサンプルとほとんど同じように設置している状態です。
◎ページURL
＜投稿の場合に挿入＞
◎Bookshelfについて
「snow_monkey_append_contents」フックにて固定ページを読み込んでおります。◎pickupについて
「snow_monkey_append_contents」フックにて固定ページを読み込んでおります。＜すべてのページに挿入＞
◎aboutからSNSの横一列について
「snow_monkey_append_contents」フックにて固定ページを読み込んでおります。▼添付 ① bookshelfの読み込み部分
■念のためのこちらも
カスタム投稿タイプの作成には「Custom Post Type UI」をつかい、特に設定などせず標準のまま、
タグ (WP コア)をくっつけております。—
すこし別の方法なのですが、固定ページでつくっている「企業ページ」で同じように読み込んで表示してみましたところ、やはり「post」になるようでしたので、シングルページの場合だけに発現するのではないように思いました。
ご参考になればと思います。
▼添付 ① 管理画面
▼添付 ② プレビュー
いいねをした人: 居ませんあーなるほど、この情報でわかりました。詳しくありがとうございます！
直接的な原因としては、カスタム投稿タイプで「タグ (WP コア)」を使っているのが原因です。
- カスタム投稿タイプ feature に「タグ（post_tag）」を割り当て
- タグ（post_tag）側にも関連する投稿タイプ（object_type）として feature が割り当てられる
- その結果、タグ（post_tag）に関連する投稿タイプ（object_type）は「post」と「feature」の2つになる
- 任意のタクソノミーの投稿で「タグ（post_tag）」を選択
- タクソノミーが post_tag、投稿タイプが post・feature なクエリで投稿が取得される
- （各投稿ごとではなく）一覧の表示時にビューテンプレートの判定がおこなわれる
- 投稿タイプが複数指定されている場合は最初の投稿タイプが利用される
- つまりそれは post
- 結果として、
.c-entry-summary--postが付与される
という流れになっているようです。
簡単な解決策は「タグ (WP コア)」を使わずに、feature 用のカスタムタクソノミーを別につくってそれを使用することです。ということで、前述したように
.c-entry-summary–-{ビューテンプレートで選んだ投稿タイプ} .c-entry-summary--type-{実際の投稿タイプ}という class になるようにしてしまうのが一番ベターかなと思うので、その方向で進めたいと思います。いいねをした人: 居ませんありがとうございます。
すごい、、こういう仕組みになっているのですね、解決できそうで嬉しいです。
当初、カスタム投稿タイプは使わずに作ろうとは思っていたのですが、
デザイン的な事情でどうしても使わないといけないなぁと思い、このような仕組みにしていまして、
カスタムタクソノミーも考えたのですが、シンプルにタグをくっつけて対応しようとなったのでしたclassが付くようであれば、簡単に修正が効くと思うのでアップデートをお待ちしています。
いいねをした人: 居ません素早いご対応ありがとうございます！
ただいまアップデートし、修正されていることを確認いたしました。
投稿・固定ページで使用しても問題なく表示されるようになりました。いろいろ調査いただきまして、本当にありがとうごうございました。
いいねをした人: 居ません - カスタム投稿タイプ feature に「タグ（post_tag）」を割り当て
- トピック「任意のタクソノミーの投稿でカスタム投稿タイプの投稿を読みこむと、entry-summaryのレイアウトが「post」判定になってしまう。」には新しい返信をつけることはできません。