【お使いの Snow Monkey のバージョン】
【お使いの Snow Monkey Blocks のバージョン】
【お使いの Snow Monkey Editor のバージョン】
【お使いのブラウザ】
グーグルクローム
【当該サイトのURL】
https://magokorohome.net/construction/
### 実現したいこと
アイキャッチ画像をきれいにしたい。
### 発生している問題
最初は投稿する記事のアイキャッチ画像は綺麗でしたが最近ボケてしまします。記事の画像に関してはきれいに載っているので何が原因かわかりません。
### 試したこと
画像を変えてみてアップしましたがボケて何も変わらない状態です。
もし良かったら下記試してみてください！（本番環境への反映は推奨できませんが…
1. 下記から zip をダウンロード
2. plugins/snow-monkey-blocks/dist/packages/spider の中身を (1) でダウンロードした zip の中身に差し替え
もしこれで解消されるようであれば Snow Monkey Blocks の次のリリースで反映しようと思います！
【お使いの Snow Monkey のバージョン】最新版
【お使いの Snow Monkey Blocks のバージョン】未使用
【お使いの Snow Monkey Editor のバージョン】未使用
【お使いのブラウザ】Chrome （アポロスのデバッグツールをブラウザモードで実行させる拡張機能下で動作）
【当該サイトのURL】みせれないよ！（AA略）
### 発生している問題
読み込んでいる script が、
..../wp-content/plugins/snow-monkey-bbpress-support//assets/js/app.js?ver=.....
snow-monkey-bbpress-support//assets となっているので、空ディレクトリを参照していると言う Call Warning が検出される。（アポロスのデバッグツールをブラウザモードで確認）
### 試したこと
wp_enqueue_script あたりのパス指定にスラッシュが余分に入ってるんとちゃう？
知らんけど
追記：CSS の方も Warning でてるわ。
WooCommerce、Event Organiser、The Event Calendar など、カスタム投稿タイプが使われていて、かつプラグイン内のページテンプレートを呼びだすようにしていたり、あるいは独自にクエリを書き換えたりしているものとは Snow Monkey は相性がわるいんです…。そして、どれも個別に対応しないと対処できないところがやっかいなところでして…。
他のカスタム投稿で発生するのであればコアの方でも実装できれば。
北島さんではないですが、少し回答します。
何で今回このような問題が起こっているかというと…
3D FlipBook のプラグインは、プラグイン内に仕込まれている React と React dom などの javascript ライブラリを強制的に呼び出してるんです。
それで、Snow Monkey で読み出してる Font Awesome の javascript で使われている処理を、このプラグインの強制的に呼んでいる React dom とかの処理が競合動作をして正しく動作しないような状態にさせてたんですね。
なかなか癖の悪いプラグインなので…このような問題に対してテーマでオールマイティに対応するよは個々で条件を付けてカスタマイズした方が良いと思います。
他のカスタム投稿タイプに対応させる場合は
‘3d-flip-book’ の所をカスタム投稿タイプに合わせて条件を変更していただく形で対応するのが良いと考えられます。
そもそも、プラグイン側で PDFビューアの投稿タイプを 3d-flip-book 以外にすると正常に動作しないコード構造で実装されてますので…3D FlipBook のプラグインを独自カスタマイズされない限りは大丈夫という気がします。
v6系にはsnow_monkey_template_part_render_{slug}のフックがまだ無かった頃ですね。
なので… snow_monkey_template_part_render
を使用する形になります。
add_filter(
'snow_monkey_template_part_render',
function( $html, $slug, $name, $vars ) {
if ( $slug === 'template-parts/content/share-buttons' ) {
元々のフックの間のコードをここに記述してください
}
},
10,
4
);
で一度試していただけますか？。
少し、v6.2.1ピッタリ + PDFボタンが動作するような環境構築を今直ぐにできなかったので、v6系の似たような環境で確認しました程度になってます。
もし、上手くいかない場合は再度返信の形でお願いしますー。
はい！承知しました。
これが正しいのか分かりませんが、以下のように追加CSSに書くことで思い通りの場所に配置することが出来ました。
img#shopicon {
position: fixed;
top: 220px;
right: 0;
z-index: 9999;
width: 15%;
margin: 0 0 0;
}
position: fixed; は基準が要素ではなくて画面になるので top: 0 だと画面上に張り付きますね。
他のユーザーさんが同じことで悩んでいる場合の参考にもなるので、良かったらどうやって解決したか書き込んでいただけると嬉しいです！
snow_monkey_taxonomy_posts_widget_args はすべての任意のタクソノミーの投稿のクエリを書き換えるフック名になりますが、snow_monkey_taxonomy_posts_widget_args_任意のid はその id 属性を持つ任意のタクソノミーの投稿のクエリだけを書き換えることができます。
id 属性は任意のタクソノミーの投稿のインスペクター（設定パネル）の高度な設定にある HTML アンカーから設定できますので試してみてください。
スタートアップガイドをちょこちょこ更新しているのでたまに見返してもらうと良いかと思います！
keipro さん
フォーラムでどこまで対応するかは難しい問題で、いまはその当たりをふわっとさせています。というのはこのフォーラムやユーザー同士のコミュニケーションの場でもあり、全然関係のない話題はともかくとして、「カスタマイズ」のような文脈にそっている投稿を管理者が厳密に制限してしまうのはどうなのだろう…という思いがあるからです。
ただ、ページが全く見れない状態で、Snow Monkey のブロックやコンポーネント以外の部分（実際は Blocks なのかもしれないけどそれがわからない）についてのカスタマイズについては回答するのが難しいので、フォーラムを「確実に答えがえられる場」として捉えられている方がそういう投稿をされると非常に厳しいです（keipro さんがそうだという意味ではなくて、フォーラムをみて、ここはそういう場なんだなと勘違いされる方がでた場合、という意味です）。
そういう意味でオレインさんが書かれているように僕も思いますし、ただ、書き込むハードルがめちゃめちゃ上がってしまうのも違うと思うので、
– 解決したら良いなぐらいの気持ちで気軽に書き込める
– 解決したらどうやって解決したかを書き込む
– 同じ問題で困っている人はそれをみて解決できる
という場になれば良いなと願っています。
その場合、子テーマのstyle.cssで、親テーマのstyle.cssを全部上書きされるのでしょうか
それとも子テーマのCSSが追記されるのでしょうか？
「親テーマのstyle.cssを全部上書きされる = 親テーマの style.css は無しになって、全部子テーマの style.css に書かなければいけない」
「子テーマのCSSが追記される = 親テーマの style.css はイキ、それに子テーマの style.css が追加」
ということでしょうか。だとすると、これはご本人次第ですね。普通にやれば後者ですが、好みで前者にされる方もいないことはないと思います。
WordPressの関数、最初のほうは、パスを関数として定義するように記述する風に受け取ったのですが、認識に間違いないですか？ 後者のほうも、コードの書き方がちがうけど、同様なのかなとおもいました。これ、functions.phpに記述します？
My Snow Monkeyに記述します？
PHP や WordPress の関数の書き方について詳しく指南するのはこのフォーラムの存在意図とは外れるので割愛しますが、functions.php か My Snow Monkey かについてはこちらもご本人の好みの問題になります。上ではられている My Snow Monkey の記事をみてご自身で判断するのが良いかなと思います。
キタジマ様
ご回答ありがとうございます！
解決できました。助かりました。
Olein_jp様
キタジマ様
Snow Monkey以外の質問をしてしまい申し訳ございません。
フォーラムの使用方法を誤って認識しておりました。
Olein_jp様の言われるように、現在学習の身でございます。
このフォーラムの使用方法は改め、多方面から問題解決できるようにします。
申し訳けありませんでした。
確かに、子テーマで素直に設定するという方法もありそうですね。
その場合、子テーマのstyle.cssで、親テーマのstyle.cssを全部上書きされるのでしょうか
それとも子テーマのCSSが追記されるのでしょうか？
WordPressの関数、最初のほうは、パスを関数として定義するように記述する風に受け取ったのですが、認識に間違いないですか？ 後者のほうも、コードの書き方がちがうけど、同様なのかなとおもいました。これ、functions.phpに記述します？
My Snow Monkeyに記述します？
とはいえ、プラグインディレクトリーに格納し、My Snow Monkeyに記述することを推奨するキタジマさんの記事がありました。
これがベストプラクティスのような気がします。ググれば答えが見つかるのですね。どうでしょう
