キタジマ タカシ この記事は Snow Monkey アドベントカレンダー 2021、25日目の記事です。
メリークリスマス！なんとか間に合いました！
今年もアドベントカレンダーをやりますと告知はしたものの、今年は Snow Monkey 人気も上がり調子ではない（？）し、もしかしたら僕の1人アドベントカレンダーが再来してしまうのでは…でもネタ全く無い…というのもあって、匿名質問箱を用意してその質問に答えることで埋めていこうと考えていたのですが、ほとんど質問がこず撃沈しました（白目）
一応2つ質問をいただいたのでそれには答えつつ、最後の記事なのにボリューム不足になるとアレなので、Snow Monkey アドベントカレンダーに参加いただいた皆さんの記事を読んでみて気になったポイントについて勝手に取り上げていきたいなと思います。
匿名質問箱で頂いた質問
ということで匿名質問箱でいただいた質問。
Snow Monkey にできないことはないと聞いたものです。Snow Monkey だけで、Yahoo！や Excite のような、ポータルサイトって作れますか？
うーーーーーん、どうなんでしょう、一言で答えるとすれば「できるかもしれないけどできないかもしれない」という感じでしょうか…。
まず「ポータルサイト」の定義ってなんなのですかね？僕はその辺疎いのでよくわからず申し訳ないのですが、メディアサイトとはまたちょっと違うのかな…？メディアサイトなら WordPress の得意ジャンルって感じがするけどポータルサイトっていうと WordPress の得意ジャンルではない気がする…。
余程シンプルなサイトで無い限り、だいたいは素の WordPress と Snow Monkey テーマだけではつくれないと思います。やっぱりなんらかのカスタマイズが必要かなと。簡単なものは CSS の追加だけかもしれないし、難しいものはプラグインを追加したりプログラミングしないといけないかもしれない。「できないことはない」と言われた方がどこまでを含んでそのように発言されたのかはわかりませんが、コードを追加してのカスタマイズまで含んだ発言なのであればできることの幅はかなり広がります。PHP / JavaScript / HTML / CSS でできることであれば何でもできる、ということになるので。ただそうなるともう WordPress とか Snow Monkey という話でもなくなってきますし、ポータルサイトとなるとインフラの問題もでてくると思うので…ということでもっと情報がないとバシッと回答するのが難しいです、すみません。
この人に Snow Monkey を使ってもらいたい！という方はいますか？
「特定の誰か」ということでしょうか。そういう意味では特にいないというか、考えたことがないですねー。「使ってもらいたいジャンルの方」ということであれば、制作会社につくってもらった WordPress サイト（クラシックエディター）を使っている方に使ってみてもらいたいですね〜。そして率直な感想を聞きたい。
Snow Monkey アドベントカレンダーに参加いただいた皆さんの記事を読んでみて気になったポイントを勝手に取り上げてみる
はい、ということで、ここからはアドベントカレンダーの記事を読んでみて気になったところを見ていきたいと思います。
オリジナルで作らないんですか？と聞かれたら
めがねさんが書いてくださった「クライアントのサイト制作において、Snow Monkeyの利用する場合のポイント」。
その中に「オリジナルで作らないんですか？と聞かれたら」という章があって、
そんな場合には、以下のようなメリットをお伝えします。
・Snow Monkeyは基本的なWebサイトの要素を提供がメインなので、デザインのカスタマイズも、もちろん可能です。
・WordPressは継続的なアップデートが必要です。特に昨今はブロックエディターの更新の速度が速く、テーマ側で追従していくことは簡単ではありません。そういった部分をSnow Monkeyでは継続的に対応し続けてくれる可能性が高いです。
・プロトタイプを確認いただきながら、制作を進められるので、進捗が出しやすいです。
どれもさすがの着眼点！という感じなのですが、特に「継続的に対応し続けてくれる「可能性が高いです」」というところがめがねさーん！ﾀﾞｲｽｷという感じですね〜。適当な人だと「継続的に対応し続けます」って言っちゃうと思うんですよね。そこを可能性が高いとちゃんと伝えてくれるというのはさすがだな〜と感じました。
メディアクエリの mixin
みしまさんが書いてくださった「Snow Monkeyの好きなところと、現在の制作の流れ」。
メディアクエリを mixin で呼びだすくだりが書いてあったのですが、Snow Monkey もメディアクエリを mixin で呼びだしているので、それを使っても良いのかなと。ブレイクポイントの調整をしなくても良くなるので。ただ、ビルド環境は調整が必要かもしれません（動作未確認）。
@import 'PATH/TO/themes/snow-monkey/src/css/app/core/core';
@include _media-min(lg) { ... } // PC サイズ以上
@include _media-max(md) { ... } // タブレットサイズ以下
@include _media-only(md) { ... } // タブレットサイズのみ基本文字色と基本フォントの指定
Naifix さんが書いてくださった「WordPressテーマ「Snow Monkey」カスタマイズTIPS」。
サイトの基本文字色・基本フォントをカスタマイズする CSS を書かれていました。
body {
color: #202124;
font-family: "Helvetica", Arial, "Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif;
}Snow Monkey は CSS カスタムプロパティで基本文字色と基本フォントを設定しているので、それを上書きしたほうが細かいところまで正しく反映されます（ただし、IE11…）
:root {
--_color-text: #202124;
--_base-font-family: "Helvetica", Arial, "Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif;
}inc2734_ ではじまるフックについて
marushuhei さんが書いてくださった「Snow Monkey テーマカスタマイズをやってみて感じた「ここまで準備してるなんて最高です！」というポイント」。
inc2734_wp_oembed_blog_card_block_editor_template フィルターフックを使ったカスタマイズについて書かれていますが、ここは snow_monkey_oembed_blog_card_block_editor_template フィルターフックを使ったほうが安定性が高いと思います。
実は snow_monkey_oembed_blog_card_block_editor_template は inc2734_wp_oembed_blog_card_block_editor_template を単純にラップしただけの関数なので、できることは全く同じです。なぜわざわざそんなことをしているかというと、inc2734_ ではじまるフィルターフックは僕が Packagist で配布しているライブラリに含まれているもので、Snow Monkey はそのようなライブラリの組み合わせでできています。ライブラリは Snow Monkey よりもっと頻繁に更新されて仕様も変わることがあるのですが、フックについては Snow Monkey 側でラップすることでその変更を吸収できるようにしているのです。なので inc2734_ ではじまるフックを使うより、snow_monkey_ ではじまるフックを使うほうが安定度が高いということになります。
Snow Monkeyの「メタ」のカスタマイズについて、いろいろ調べました
うぇびんさんが書いてくださった「Snow Monkeyの「メタ」のカスタマイズについて、いろいろ調べました」。
その中の一節。
Snow Monkeyのプラグイン前提の仕様は正直驚きです。扱う人によっては、my-snow-monkey.phpに数千行のスパゲッティコードが書かれた、子テーマより闇が深いサイトが生まれてしまうのでは…という危惧があります。PHPを書けるWordPressにおいて、それは子テーマでも同じことなのですが。
生まれるでしょうね笑
サポートフォーラムでは「My Snow Monkey に貼り付けてください」と案内してます。毎回毎回細かくプラグインとは？という話をして理屈とコピペの指導をするのも大変なのでそのように案内しているわけですが、My Snow Monkey はただの空のプラグインなので、実務的には機能ごとにプラグインをわけて、必要に応じてオンオフできるようにしておいたほうがメンテナブルで良いと思います。
子テーマの場合でもコードを書く PHP ファイルを分けることはできますが、コメントアウトという形をとらないとオフにはできないので、個人的にはプラグインの形のほうが管理しやすくない？と思いますね。
サポートフォーラムについて
譜乃謡 詩哥さん、Kmix39 さん、言ノ葉 テナさんが書いてくださった「Snow Monkey でも、制作速度を上げることよりたくさん大切なことはある」。
サポートフォーラムについての言及が熱いポイント。
サポートフォーラムには日々、新しい質問が来る。引き出しが作れていく。そうして、やりたいことの答えがすぐに解る状態になっていく……。
例え、自分が開発していなくても WordPress や Snow Monkey は常にアップデート更新がされ、安心して安定に使えるって思ってんだろうね。自分以外の誰かが、自分とは関係なく開発してくれていると思いながら使用し続けているんだろうね。それって間違いだと早めに認識して欲しい。WordPress や Snow Monkey を使用するのであれば、要望提出や不具合報告とかが必要なことと解って欲しい。何故かと言えば、不具合報告や要望と言った意見交換をすることで成長しているオープンソースだから。なので、サポートフォーラムで意見交換して成長させてくださいってお願いしたい。
Snow Monkey は僕が1人でプログラミングしている個人プロダクトであるので最終的なジャッジは僕がやることにはなるんだけど、良いプロダクトにするためには実際に使用されている方々の多様な意見が集まって、ディスカッションして、っていうところが絶対に必要だと思っています。
こういう言い方はアレだけど、アンオフィシャルな場所で文句だけ言っていても、そのプロダクトが理想的なものにはならないですよね。ちゃんとオフィシャルな場所でディスカッションして説得なり納得させるなりさせないと。Snow Monkey はかなりフォーラムが活用されているほうだと思うけど、ハードルが高くて書き込めないという意見をいただくこともちょいちょいあるので、そう思っている方はもっと気軽に書き込んでみてもらえればと思います。
もちろん「Snow Monkey とは何か」という核の部分にそぐわない要望は却下することになりますが、それは別にその要望は Snow Monkey に合わないという判断になっただけで、要望自体がダメなものだったとか、その人がダメだったとか全くそういうことではないので。ディスカッションはフォーラムより Slack のほうがやりやすいかなーと思うときもあるので、要望や不具合報告についてはとりあえず Slack ということでも良いかなと思ったりしています。
現在は、サポートフォーラムについての誤解もかなり解けているのも良くなったよね。
Snow Monkey のサブスクリプションで得られる特典の 1 つは、サポートフォーラムでサポートしてもらう権利ではなく、サポートフォーラムを使用できる権利 なのをきちんと理解しているユーザーが多い。
あんまり公にこういうことを言うと怒る人もいるかもだけど、まさに上記のように考えています。開発元がちゃんと全部対応しろ！と思うのはもっともだし一般的にはそういうものなのかもだけど、キャパ的に限界があるし、僕がやめちゃったらそれで終わりになるけどそれってどうなの？っていう。サポートの人員を雇用して云々という話もあると思うけど、うーん、結構難しいと思うんですよね。一度そうしちゃうとユーザーどうしてのサポートの場というのは二度と実現しないでしょうし。サポートフォーラム運営やっている人同士で雑談したい。
私がサポートフォーラムで返信対応したら、聞いて終わりにして、その質問者が依頼者からサポートフォーラムで聞いた対応のコードを入れた程度で多額な別料金をサポート依頼料として取っていたりしたんだよね。お前、大した対応してねーだろって…。その対応料金を払った依頼者から後に聞けたんだけどね…。結果的に、質問してきた本人も含めて全員の気持ちがマイナスになる結果になった。
これも難しい問題ですよね。どこまでを「サポート」と呼ぶのかという定義の問題。「テーマに関する問題だけで、CSS や WordPress そのものに関する話題等は NG」とバッサリやっちゃうこともできるけど、個人的にはそういうふうにはしたくない。でもそうすると定義の問題があやふやになっちゃうので、仕事で請けたものを文字通り「そのまま」フォーラムに投げて解決しようとする。個人的にはそういうのはサポートの範疇ではないと思っているんだけど、じゃあどう言語化するかといったらうまく言語化できないんですよね…。これは考えるたびにいつもうーーんとなっちゃいます。
ブロックにカスタムフィールドを埋め込む方法について
いっぺえさんが書いてくださった「【完全版】Snow Monkeyでカスタム3兄弟を実装する」。
「Snow Monkeyブロックにカスタムフィールドを埋め込む」という章で snow_monkey_template_part_render_template-parts/content/entry/content/content フィルターフックを使ってコンテンツ内のブロックを str_replace で書き換える方法が書かれていました。一応それで動くことは動くと思うのですが、置換対象が大きいため Snow Monkey Blocks のアップデートで HTML 構造が変わるたびにコードの変更が必要になります。ちょっとそれはしんどいと思うので、個人的にはフックで対応するのではなくショートコードをつくって、それをブロックの中に埋め込むのが良いのではないかなと思いました（動作未確認）。
add_shortcode(
'display_year_field',
function() {
return get_field( 'year' );
}
);とした上で、セクションブロックを記事に挿入してタイトル部分に [display_year_field] と入力する、みたいな。
最後に
今年はなんと21名の方に参加いただいて、僕もほとんど記事を書かなくても大丈夫でした。ありがたい！！！そしてすごく参考になる濃い〜記事が多かったですね。みなさんの Snow Monkey や仕事への向き合い方が見て取れてとても刺激をもらいました。なんか僕の手を離れたような感覚というか、本当にいろいろな現場で使われるようになったんだな〜というのを感じました。
さぁ、来年は WordPress 5.9 もリリースされ、本格的にフルサイト編集がはじまるわけですが、WordPress を使った受託現場や Snow Monkey はどうなるのでしょうか…いろいろと状況を見極めながら、ディスカッションしながら、取り残されないように頑張っていければなと思います。
ということで、アドベントカレンダーに、ご参加いただいた皆様、記事をお読みになった皆様、ありがとうございました〜！
