ご返信有難うございます。
$hierarchyを追加する形で、ビューファイルなどがあれば、それを見る、なければ次の$hierarchyのパスを見ていくって訳ですね。
そう言うことは、配列の最初の方がrootの優先度は高く見られるって事で良いでしょうか？
また、追加した後には、array_uniqueでパスの重複を排除した方が、余計な重複も減らせそうな感じがしますので、array_uniqueを入れて使うようにしてみます！
snow_monkey_template_part_root はもう非推奨でも良いのではと思うのですが、すでに使っている方もいると思うので残しています。
思ったのですが、優先度が配列の最初が高い順であれば、$hierarchyの最初に値を入れるようにすればどうでしょうか？
ちょっとおかしくなりますか？
例えばこんな感じです。
add_filter(
'snow_monkey_template_part_root_hierarchy',
function( $hierarchy, $slug, $name, $vars ) {
$hierarchy[] = __DIR__ . '/templates';
return $hierarchy;
},
10,
4
);
snow_monkey_template_part_root はもう非推奨でも良いのではと思うのですが、すでに使っている方もいると思うので残しています。処理的には、snow_monkey_template_part_root が使ってある場合は、 snow_monkey_template_part_root_hierarchy が使ってあっても無視されて強制的に snow_monkey_template_part_root で指定されたルートが適用されます。
そもそもtemplate_partsのフックしたhtmlって複数のプラグインで結果を共有して置換出来ない
後から優先度の問題だったことに気づきまして、複数のプラグインでも結果を共有した形で置換出来ました。
上書きする際は優先度を9999など高くして一番最初に上書きさせる、カスタマイザーなどの場合や置換の場合など10より低くしたりする事で、先にSnow Monkeyが読み込んでいるフック処理などを実行させるなどする事で正しく反映が出来ました。
こちら、多数のプラグインで結果を上書きできるのを確認できましたので、こちらの問題はスルーしてください。。。
また5.3.0からのsnow_monkey_template_part_root_hierarchyフックの追加、ありがとうございます。
そのフックと、検索ボックスのテンプレートパーツとして呼び出すアップデートとカスタム投稿ではtemplates/view/content-XXX.phpが呼び出される仕様などから、
template_partsにプラグインからもっと上手くフックを使って色々出来ないかとか試したい事も増えましたので、
色々と試したいと思います。試した結果などは、今後何らかの形でお伝えできればと思います。
ほぼ解決できたのではないかと思えるので、一度このトピックを閉じさせていただきます。
Snow Monkey は、投稿の場合は templates/view/content-post.php が使用されます。このビューファイルは
シェアボタンやアイキャッチ画像などが表示されるリッチなものになります。カスタム投稿の場合は templates/view/content.php が使われます。こちらはシェアボタンなどがないシンプルなビューファイルです。
カスタム投稿タイプは定義した人によって投稿と同じように表示したいのか、固定ページと同じように表示したいのか、あるいは全く別な形で表示したいのかがまちまちです。そのため基本はシンプルな形で表示し、カスタマイズは独自におこなってください、というスタンスです。
投稿と同じように表示する方法は下記のトピックを参照してください。
わたしは最新版の1.4.4を利用しています。
有料版はないので、同じはずです。
もしかすると設定をきちんとしないと現れないのかもしれません。
この件に関しては、さほど困っているわけでもないため、他の方でお困りの方がいればまたご確認いただくかたちでも問題ありません。
Amazon API問題のついでに分かればと思いましたので。
丁寧にご対応いただきまして、ありがとうございました。
勝手ながら、補足させていただきます。
・SnowMonkeyBlocksが使える
Gutenbergエディタを有効にする為に、参考記事の通り、
'show_in_rest' => true,
を追加しましょう。
最新の英語の方の公式リファレンスでは書いてますが、日本語のサイトだと書いてないのが多いので（＾＾；
参考記事：
結論からいうと、カスタム投稿タイプを管理するアドオン（プラグイン）をオフィシャルに提供することはありません。
- すべてをアドオンで設定できるようにすると膨大な設定項目が必要になってくること
- 細かいことをやろうとする、あるいはテンプレートをカスタマイズしようと思うと結局コードを書かなければいけなくなること
- 細かいことをしないのであれば Custom Post Type UI で済んでしまうこと
という理由からです。設定項目が増えれば増えるほどバグの発生確率はあがります。アドオンをつくったとして、恐らくコードを書くより場合よりもそのアドオンを使っていることで不具合がおこる可能性のほうが僕は高いのではないかと思います。
・１カラムや右サイドバーなどのテンプレートが通常の投稿と同じように選べる
下記を試してみてください！
・SnowMonkeyBlocksが使える
特に制限はしていないので、普通に使えると思います。
・検索ウィジットで検索ができる
こちらも多分普通にできると思います（ただ、投稿や固定ページと混ざって検索結果に表示されます）。
・カテゴリ、タグ設定ができる
標準のカテゴリーやタグをカスタム投稿タイプに割り当てると、たまに「ん？」という挙動になることがあるので、独自にカスタムタクソノミーをつくって割り当てるのが良いと思います。
・デザイン・レイアウトなどもすべて同じ
下記ご参照ください。
・最新の投稿ウィジットなどが使える
「Snow Monkey: 最近の投稿」にカスタム投稿タイプを表示させたいということですかね？下記が参考になると思います。
うーん、こちらでは再現しないですね…。
- _self + 全体リンク
- _self + ボタンリンク
- _blank + 全体リンク
- _blank + ボタンリンク
のパターンを入れてみましたが、いずれも壊れませんでした。古いバージョンのときから入れていたブロックじゃなくて、新規に追加したブロックでも発生する、ということですよね？なんでだろう…。
スクショありがとうございます。
ただ、なぜか僕のにはでてないです…。
Rinker プラグインに詳しくないのですが、有料版のようなものをお使いだったりしますか？
ご返信ありがとうございます。
Rinkerのプラグインは、レイアウト要素から選択することができます。
他のテーマでも同様のエラーはでますでしょうか？もし他のテーマでもエラーが出るのであればプラグイン側/Amazon側の問題だと思いますのでこちらではわかりません…。
他のテーマを使用している方でも同様の症状が出た人がいました。
やはりテーマには無関係のようですので、こちらについては忘れてください。
以上、よろしくお願いいたします
ありがとうございます。
CSS修正だけでは駄目でしたが、Snow Monkey Heading Widget Areaのアップデートで表示されるようになりました。
ウィジェットについてはひとまずカスタムHTMLでうまくいってるので、修正まではこのまま行きたいと思います。
Snow Monkey Heading Widget Area v1.0.3 をリリースしました。アップデートしていただくと、 max-width: 〜 は不要になるはず…！です。なので最終的にはこれだけ書いていただく感じですね。
.l-heading-widget-area {
display: block !important;
}
WordPressのGutenbergを利用してRinkerのプラグインを利用しようとするとポップアップが開かないようです。
他のテーマでは開くようですが、snow-monkeyでは対応していないでしょうか。
Rinker、使ったことがなく、とりあえずダウンロードして入れてみたのですが、どのように Gutenberg に追加するのかがわかりませんでした。ショートコードではなくてブロックがある、ということですよね？どのブロックカテゴリーに何という名前で入っているか教えていただけると助かります…。
商品を追加する場合に検索をかけるのですが、Amazonで検索すると以下のエラーが表示されます。
【parser Error】XMLが正しくありません XML parser Error
作成者に問い合わせたところ、Amazon側が不正値を返してきているため、分からないとのことでした。
他のテーマでも同様のエラーはでますでしょうか？もし他のテーマでもエラーが出るのであればプラグイン側/Amazon側の問題だと思いますのでこちらではわかりません…。
追記です。追加する CSS、どうも最大幅の指定もつけておかないと PC のときにはみでちゃうみたいです。
.l-heading-widget-area {
display: block !important;
max-width: 824px;
}
指定する幅はサイトに寄って異なると思うので、これは今後の Snow Monkey Heading Widget Area のアップデートで幅指定なしにできないか調査します。
「最初の見出しウィジェットエリア」は、最初非表示で HTML の読み込みが終わり見出しが見つかったら云々して表示、みたいな処理になっているのですが、この最初の非表示状態のときに Adsense 広告が読まれると、Adsense は「表示するところがないよ！」とエラーを吐いて処理をやめてしまうみたいです。なので、CSS で強制的に「最初の見出しウィジェットエリア」を最初から表示状態にしてあげるといけそうです。
下記をカスタマイザー > 追加 CSS、もしくは子テーマの CSS に追加してみてください。
.l-heading-widget-area {
display: block !important;
}
ちなみに「WPAW:Googleアドセンス」で「リンクユニット」を設定するとモバイルで両端が少し切れてしまいます。リンクユニット用には向かないウィジェットでしょうか。
これをみて気づいたのですが、「WPAW:Googleアドセンス」って「リンクユニット」の選択肢を用意してなかったですね…。次のアップデートで追加するようにします。とりあえずカスタム HTML ウィジェットを使ってください。両端切れる問題は、Adsense コードの data-full-width-responsive="true" を、 data-full-width-responsive="false" にするとどうでしょうか？
