逆引きゴリラ

News
2021/01/12 設定値の解説記事を 2 件追加しました。
  1. ホーム
  2. ゴリラゴリラな記事

ゴリラゴリラな記事

当記事は、Snow Monkey Advent Calendar 2020 - 初日の書き下ろし記事です。

お詫び

ゴリラゴリラな記事にしようと頑張っていたのですが、普通の記事になってしまっていまいました。
飼育に失敗したようです。飼育員一同、謝罪します。

記事の内容

本記事は「Snow Monkey 公式リファレンスのフック一覧」の作成の経験と、その後「逆引きゴリラ」の制作…
私なりの「0 ベースからフック一覧を作成」、また「解説メディアの作成」を簡単に書いてます。

もし、同じように Snow Monkey のフックについて調べたい人や、解説メディアを作りたいと考えている方に役に立つような記事になれば幸いです。

Snow Monkey 公式リファレンスについて

Snow Monkey の公式リポジトリの Wiki で公開されているフックの一覧は、どうやら Snow Monkey 公式リファレンスと言われているようです。

Snow Monkey 公式リポジトリ (Wiki)

Snow Monkey 公式リファレンスは公式でもあるが、非公式でもある

フック一覧を作ることについて触れる前に、公式リファレンスについて整理しておきたいです。 公式リファレンスが、公式が作っているもの と思われているような誤解が生まれているので、それに思うことが幾つかあります。

まず、すべての解説は公式によって作られていません。
これもコントリビュートの形で成り立っている成果物です。

フックの解説文なども、すべて Snow Monkey 開発者であるキタジマ氏が書いているものでもありません。

なので、間違いもあります(汗)

公式リファレンスの記載協力者について

初期からフックの解説文を記載してるのは、公式開発者でも、Snow Monkey エキスパートでも、なんでもない野良なゴリラ飼育者。
私(ケミ)と葉月の二人でやっている、ウェブ・アプリなどのシステム開発・制作チーム Kmical Lights です。(旧:NotWiz)

この記事を書いてる…そう、私たちです。

権利問題

公式が作っているもの だからと言う理由で、何も考えず自由に使用されている人も居ますので、最初に少しだけ書いておきます。

記載した人にも権利があると言うことです。
フックの解説文章も、そう言った権利が 法的にあります。

  • Snow Monkey のフックの命名、それらに関する権利は Snow Monkey 開発者のキタジマ氏にあります
  • Snow Monkey のフック一覧内のフック説明やサンプルコードは、記載者にも 法的な 権利があります

しかし、 きつく権利を主張するのはマイナスと考えています。

フック一覧を権利物にするのはマイナスか?

Snow Monkey のフックをまとめるに当たって、当時(2019 年)は非公式なサイト(NotWiz)でカスタマイズの解説をしていましたし、やろうと思えば非公式にフック一覧をまとめることが可能でした。

しかし、フック一覧を公式とは違うサイトでまとめてしまうと権利問題はよりややこしくなりますし、自由な解説メディアの広がりを阻害してしまいます。

難しい問題として、プログラミング言語的なモノの説明と言うのは、誰が説明を書いてもほぼ同じ文章になりやすいです。
先に解説メディアを作り、その作った人の権利物になってしまうと、他の方が解説をしたい場合に幾つかの難しい問題となりやすいケースがあるのです。
または、フックの説明が開発者の思想と違う紹介をされた場合でも、他の開発者に障害が出てしまったり…そういった場合、後々ややこしい問題に繋がってしまうケースもあります。

Snow Monkey のフックと言うのは、 Snow Monkey のテーマ・システムの大きな質を持つ代表的な機能の 1 つです。
ですから、非公式なカスタマイズ例とは違う質を持っています。

「非公式サイトで先に Snow Monkey カスタマイズの根本に当たるフックの一覧や説明を作るべきではない」と、権利問題を踏みました。

権利の破棄…

フック一覧と言うコンテンツの性質からすれば、誰でも自由に編集や引用をできる形であるのが、そのプロジェクトにとって良い結果を与えられると考えています。

Snow Monkey の公式リファレンスを基にした、解説・説明コンテンツ、またはサービス…新しいフック一覧…その他… Snow Monkey と言うプロジェクトを広げる為には 個人が権利を持つ媒体ではなく、自由に活用可能な公式的なコンテンツで生成する必要性でした。

非公式な形で解説するよりも先に Snow Monkey の公式上の形式として自由に使える形にするには…を考えました。

フック一覧を作られる前に、可能であれば、利用者の害とならない、またはそのプロジェクトのより良くなる形で権利問題を考えて解決すると良いと思います。

檻の中で飼わないために

解説メディアを作成する場合、先駆者の説明の取扱いや参考文献の権利問題って実は色々ややこしいですね…。

ですから、Snow Monkey はそう言う権利問題を抜きにして、自由に展開して広げていけるプロジェクトであれ…と。
フック一覧や解説メディアでも、「権利という檻に縛られない猿であれ」。

そして、それもオープンソースが掲げている意味の 1 つでもあるはず。

Snow Monkey のフック一覧について、実は「Snow Monkey 公式リファレンス(Wiki)内の文章も 100% GPL で頼みます」などの事を、Snow Monkey 開発者であるキタジマ氏と(一応ですが)合意済みです。
(2019 年頃に軽く話しただけです。 100% WKA忘れられている 可能性 アリ

…まあ、自由に使って問題ないのです。

本題:フック一覧の制作

フック一覧の制作の本題に入ります。

準備

フック一覧を作る為に…まずは必要な条件を揃えましょう。

  • 常に最新のソースコードの情報を取得するアンテナ(アップデートで変更があった場合などに、追記や文章の変更などのメンテナンスも必要なため)
  • 開発者のソースコードを読む力(開発者の思想と異なった解説をしてはならないですし、解説するためにもソースコードをしっかり読まなければならないため)
  • やる気(何をするにも必要)
  • 時間(相当な時間をかけて調べなければなりませんので、結構長い時間が必要です)
  • ボランティア精神
なぜ、ボランティア精神?(本音を含め)

基本的に、フック一覧を作る事も無償の活動と思います。

公開したフック一覧を利用する方であれば、新しいサービスなどを作り、恩恵を得られるかもしれません。
しかし、フック一覧を作る行為は、恩恵や金銭を得ることと直接繋がるかと言うと疑問を感じます。

有料のフック一覧を誰が求めるのでしょう?ややこしい問題も起こります。
フック一覧を作ったところで、それで直接金銭を得る方法としてはウェブ内広告…くらいだと思います。

「逆引きゴリラ」は、広告欄の予定だけをしています。
現在は広告枠を用意してはいますが、広告を付けていません。ガチガチに広告収入をするとかそういうのも難しいと思いますね。
制作時間や機械学習コストとして大赤字真っ最中なので、せめてマイナス分は無くしたいですが…。
(NotWiz の時は、閲覧者の半数以上は広告ブロック環境にあった事もあって一銭にもなりませんでしたので諦めてはいます…)

どちらかと言えば、「こんなの作りました・作れます」と言う見本にして案件を得る方が可能性として高いです。
なかなか難しい事かも知れませんが。 ポートフォリオが無い、ネタも無いから案件が取れないと言う初心者であれば、フック一覧を作る事は 1 つの制作実績を作る手かもしれませんね。

何のためにフック一覧を作るのか

さて、長々と書いてしまってますが…次に何のためにフック一覧を作るのか考えていきます。

では、Snow Monkey にフック一覧が無かった頃。2018 年中の Snow Monkey の公式サポートフォーラムを追ってみましょう。
ちらほらと下記のことが出てくるはずです。

同じ質問のように「Snow Monkey のフックがどこに仕込まれてるか分かる一覧みたいなもの」「Snow Monkey のフックを…」「どのようなフックがあるか知りたい」などの発言を何度かされていることが解ります。

どんなフックが存在しているか一目で理解するため

WordPress のカスタマイズ案件で、あるある問題として「◯◯をするためのフックは無いか」を調べることも多いと思います。
フック一覧は「どのようなフックがテーマに存在しているか不明」な問題の解決方法として役に立ちます。

フック一覧を制作する 1 つの理由としては、その問題を解決することです。

カスタマイズの幅を広げるため

どのようなフックが存在しているか、そのフックがどういう事をできるのか理解できることで「こういう事もできるかもしれない」と言うアイデアを産むキッカケにもなりやすいです。

フック名を洗い出す

では、どのようなフックが存在しているか知ることをはじめましょう。
最初にやる事として、すべてのフック名を調べます。

2018 年の頃、フック一覧の制作の事について何もしていなかった当時のキタジマ氏の発言で 「(フック一覧は)存在していない」と言うような回答に続き、「do_actionapply_filters と一括検索して調べてます ^^;」と回答されています。

なお、当本人(キタジマタカシ氏)は「僕もすべてのフックを覚えていないです」や「どこに仕込んだかも検索して調べています」などと供述しており……

しかし、do_actionapply_filtersをそのまま検索したところで Snow Monkey とは関係のないフック名まで出てしまいます。
どうすれば良いのか?

WordPress のテーマやプラグインのほとんどは、開発者が設定したプレフィックスから始まるようにフック名を統一して命名してくれています。
Snow Monkey テーマのフックであれば、 snow_monkey_ からはじまるように、ほぼ統一されています。

※ 当時のキタジマ氏によれば inc2734_ から始まるフックもあると回答アリですが、現在では、ほぼ snow_monkey_ からはじまるように同一のフックが仕込まれています。

なので、まずはそのコマンドを元にして、do_action( 'snow_monkey_apply_filters( 'snow_monkey_grep してみました。

しかし、結果として 同一のフック名がいくつか結果に表示される、またはいくつかのフックは結果に表示されないフック名でない(関数名など)結果が表示されてしまう など問題がありました。 同一のフック名に関しては、同一結果を 1 つにだけに絞れば良いのですが、後者 2 つはやや問題です。

Snow Monkey のソースコード内には、 do_action( の後に改行がある場合と改行がない場合もあるなど、一度にすべてのフック名を出力させることが難しいのでした。

私が行った最終的なフック名の調査方法

何度も grep のルールを適用しても grep コマンド単体では洗い出しが難しかったことから ag (The Silver Searcher) といった除外ルールを記述できる grep コマンドの強化版のようなものなどの使用をしました。

ag より良いコマンドもいっぱいあるので、自分が使いやすいコマンドでやろう。

そのコマンドに除外ルールを適用し、必要なファイルのみを検索対象とする改行に関する正規表現ルールを適用する includerequire と言ったファイル順で再起検索させる とした独自ルールを設定して算出するようにしました。
それらは、ag コマンドのみでは難しいので、Mac OS の標準アプリである Automator と連携させ、他にも コメントは無視する廃止となっている処理文は非推奨と見なす …などのプログラムを swift 言語で書いたものを適用して検索しています。

その際に結果を do_action の結果ならアクションフック、apply_filters の結果ならフィルターフックと分別させておきます。

そうすることで、一通りのフック名の一覧を精査でき、フック名の一覧が完成しました。

フック名の一覧ができても…

フック名の一覧のみで「どのようなフックが存在するのか」の問題がすべて解決できたと言えません。
それぞれ、「そのフックはどのような役割を持つのか」は、不明なままだからです。

フック名の一覧を公開する

実際にフック一覧を制作されるのであれば、フック名の一覧ができた時点でフック名だけでも公開すると良いと思います。
どのようなフックが存在しているのか、それだけでも伝えられることに意味があるからです。

2019 年 02 月 〜 03 月頃に Snow Monkey 関連のフック名の一覧を、キタジマ氏にテキストファイルで渡し、権利問題の事もあるので「公開について」と「説明の編集」について相談をしました。

多分、「公式サイトの一部のページの編集権限をください(超意訳)」とか、ちょっと何言ってるかわからない 要望をしたりしてましたね…すみませんでした(笑)

最終的に GitHub リポジトリの Wiki を使う形になって、現在の公式リファレンスとなった流れです。

フック名の一覧から、フック一覧へ進化させる

フック名の一覧に解説を付けていき、フック一覧の形式へ進化させていきました。

説明文章などの記述フォーマットを決める

可能な限り、フックの説明は統一したフォーマットで記載されている方が読みやすいはずですので、ここで記述のフォーマットを決定しました。

Snow Monkey のフック一覧では、キタジマ氏に先に幾つか(結果は3つだったけど…)のフックの説明文章を書いてもらい、それをフォーマットにして、それ以外のフックも説明をつけていく事にしました。

もし、フック一覧を作る場合に元のソースコードの制作者、または開発者に記載していただくのが可能であれば、記述フォーマットを作ってもらうのも良いと思います。
制作者が記述しやすいフォーマットであれば、制作者もフック一覧の修正が容易になる…はずだからです(多分)

フックの為のサンプルコードなどの記述フォーマットも作成する

フックの説明をまとめる前に、フック名の一覧をまとめているものから各フックの引数と返却値を洗い出すようにしました。

1 つのフックでこんな形にまとめています。

例えば snow_monkey_prepend_body でしたら

name: ‘snow_monkey_prepend_body’,
type: ‘action’,
argument: null,
return: null,

のようなものです。

これを作成した記述フォーマット変換プログラムで処理すると、自動的に

snow_monkey_prepend_body.md

snow_monkey_prepend_body

アクションフック

<?php
add_action(
  'snow_monkey_prepend_body',
  function() {
  }
);

のようなフック名やサンプルコードの初期コードが記述されたファイルを生成するようにしました。

そうする事でサンプルコードの記述が楽にできるからです。

目次を作る

2019年04月にフックの説明を 15個ほどに増やした時点で、一覧のフックを探して編集が大変になってきていました。
そこで、各フックに飛べる目次を上部に設定しました。

フック一覧を作る場合、フック名と簡単な説明だけであっても目次を作ろう!各フックへ移動できると編集時の整理もできるのでオススメ!

Snow Monkey フック一覧の場合、キタジマ氏によってページ内リンクの修正をしてもらった結果、現在は使いやすくなっています。

アクションフックとフィルターフックのページを別々にする

Snow Monkey 公式リファレンスでは、編集の面倒さを無くす事から最初は1ページで書いてしまっていたのですが、 見やすさも考えた上でキタジマ氏が2ページに分割してくれています。

フック一覧を制作する場合であれば、見やすさを優先して別々に一覧化する方が良いと思います。

「逆引きゴリラ」では、編集のシステムを優先し、アクションフックとフィルターフックはタブで分離しているだけです……。

何のフックがどの順番で使用されているかを調査する

WordPress のフックはすべて $wp_filter に代入されるのですが、実行されるたびに remove されていきます。

ですが、フックには all と言ったアクションフックがあり、実行されているフック情報は、すべて all を処理します。

WordPress の フックを実行した際に、優先度、フック名、引数、呼び出された PHPファイル名、呼び出される表示URL…を all で検出するように処理を書く事で、それらのフックが何処でどう呼ばれているかを楽に調査できます。

実際に、メタ項目を表示する snow_monkey_entry_meta_items フックは、テーマ内部でも幾度か呼ばれており、優先度によって表示される位置などが異なりますので、呼び出され方を調査しておくのは重要です。

この方法は Snow Monkey 以外のプラグインのフック処理を調べるのにも役に立ちますな!

コードの解読・サンプルコードの記述・動作確認…ひたすらに繰り返します

出力したフック情報を基に、 echoprint_r などを使用して引数と返却値や表示位置などを確かめます。

一度だけのフック実行では網羅するのは難しいです。
優先度が異なる事で表示場所が異なるフックも存在しますし、いくつかの懸念が存在します。
それらは補足説明とする形にまとめたり、またはメモに書いてまとめていきます。

実際に幾つものサンプルコードを記述し、カスタマイザーの設定などによって異なる動作にもならないかなど、動作確認も繰り返します。

この作業はすごく時間がかかり、なかなかメンテナンスできないです。可能な限りメンテナンスしやすい確認用コードを書いた方が良いと後から思いました。
公式リファレンスは、Snow Monkey v5〜7辺りで動作を確認しているので一部古いままです。
最新の動作確認状況は、Happy Snow Monkey が一部のフックについてDEMO表示も含めた状態でやってくれているはずなので、そちらを参考にしてください。

不明なフックも幾つか出てきます。不明点を解決していく必要があります。

アクションフックの場合、そのフックで起こすアクションがどのような表示を行うか、またデザインを崩してしまわないかも注視します。
フィルターフックの場合、上記で調べたメモなどを基にして前後の処理を見ながら返却値が変更される事で及ぼす変化をブレークポイントを記述して調査します。

調査した結果はすべてメモしておきましょう。アップデート時のフック解説をメンテナンスしていく際にも使用します。

フック自体に不具合や想定されない使い方が見つかった場合

その場合、フックを処理しているテーマやプラグインに不具合報告や質問などが可能であれば気軽に行うようにします。

実際に Snow Monkey では、フックの調査を基にした懸念を質問や報告をしたことで、幾つかの不具合解決や、より良い形を生み出す結果に繋がっています。

区切りをつける

Snow Monkey のフック一覧では 2019 年 03 月 19 日にフック一覧の記述を開始し、2019 年 06 月頃にほとんどのフックの説明を書きました。
一部のフックは不明なままだったので記述できていませんでしたが。(逆引きゴリラでは解説を予定)

フック一覧の完成や、解説についての終わりと言うのは無いと思いますが、公式リファレンス(Wiki)の Snow Monkey フック一覧の編集はその時点を一区切りとしています。
ここまででも約 3 ヶ月ほど掛かっています。フック一覧の調査作業と言うのはきちんとした調査を地道に行うしかありません。

そして広がり…

公式リファレンスの一部のフックの場所を一目で理解できるようにされていたり…。

  • サポートフォーラム

フック一覧の該当のフックにリンクが貼られることで、フックの回答がしやすくなったり…。

  • Youtube などの Snow Monkey 解説動画での紹介

幾つかの動画で、公式リファレンスのフックの説明文章を動画内で引用されたり…。

より良い解説って…?

公式 Wiki にフック一覧をまとめたことで、様々な人がどのようなフックがあるかを知り、 フォーラムでも幾つかの問題解決に繋がっていき、新しい解説メディアや動画も誕生していきました。

しかし、「解りにくい」「開発者向け」「一部のフックの説明が不明(または間違っている)」と言う声があります。 また公式 Wiki である事から、実際のフックを使用したカスタマイズ例をまとめにくい欠点なども見えてきました。

それと共に、声にあるようにその後のメンテナンスをしっかりとしていないせいか説明との差異も起こっていたフックもあります。調査不足を感じ始めます。

より良いフック解説って何だ

とは言うものの、解説をよりよくするにはどうすれば良いのか。
もっと理解できるフック説明…と言う形で方向性を取り、それを行うにはどうするか…を考えてみることにしました。

公式リファレンスをコピー

まずは…せっかく制作したものですし、悪い部分を理解する必要もありますので公式リファレンスを基にしていきます。公式リファレンスをコピーしました。

アイコンを付けてみました

公式リファレンスでは付けようがないので、そのままですが、「逆引きゴリラ」はアクションフックかフィルターフックかを一目で解りやすくする為に、アイコンを設定するようにしました。

アクションは動きを見せると言うことから走る人、フィルターはそのままフィルターを表すアイコンです。

海外のフック一覧サイトなどを参考に調整

Hookr.io と言うサイトがあります。

パラメータの書き方や、その他のフォーマットの参考にしてみました。

WooCommerce Account Page Visual など、ビジュアルでフックの表示位置を確認できるものがあります。
しかし、 Happy Snow Monkey がビジュアルでフックの表示位置など解説されており、非常にまとまってもいますので、私はビジュアルな解説はしない事にしました。

フックが記述されている該当の PHP ファイルや箇所を記載されているケースも海外では多かったです。
それを記載するか迷いましたが、Snow Monkey の更新頻度から…多分やりません(システム的にも大変ですから)

国語辞書を作っていた方に話を聞いた

良い解説文章にまとめたい…為にも、実際に国語辞典を作る仕事をしていた方に、言葉の意味を説明する為に行った事を取材しました。
これは非常に刺激的な体験でした。もしフック一覧を作ろうとか思っていなかったら体験していなかった事だと思います。

すべてのフック説明文章などを見直してみた

Snow Monkey 公式リファレンスのフックを書いたのが 2019 年前半であり、v5 〜 v7 のソースコードを基にしていることもあり、 それからアップデートされたものは記載のない部分が幾つかあります。また、フックの方向性にも若干差異や変化した部分もあります。

そこで、すべてのフックの説明文章を見直し、補足説明なども当時のメモも基にして付けてみることにしました。
間違い箇所を可能な限り直しています。まず、現在のバージョンを対象にして正確にするのが第一の区切りと考えています。
公式リファレンスに書いていない情報量もすでに幾つか増やし中です。(年内に一区切りまで対応します。お待ちを)

例えば、snow_monkey_before_header_site_branding_column は「ヘッダーロゴの左に…」とありますが、カスタマイズによっては「左」になりません。
なので、当サイトでは「ヘッダーロゴが表示される位置の前」と言う文章に直したりしています。

公式リファレンスの記述当時では自動表示がされていたので、説明に違和感がなかった snow_monkey_child_pages_title なども、説明に不明点が出てしまっていたので、 ただしく調査した上で説明を追加しています。

この校正では、最新の Snow Monkey のソースコードを常に自動監視プログラムで監視しながら、自動で追加の記述が必要かフックの判定する仕組みを自作して導入しています。

今後、公式のアップデート情報内でフックの追加や変更が通知されていた場合、PHP の差分から該当フックのdo_actionapply_filters の変更を監視して対応するために独自の仕組みを作った。

コピーしただけの確認が充分に取れていないフック説明については、まだ公開をしていません。それらについては年内の完了を目標に進めています。
この記事の公開時点に間に合わせようとしましたが…、11 月 27 日には初音ミクシンフォニー、同月 29 日には初音ミク マジカルミライ 2020 in Osaka を楽しみすぎてしまい…。 また機械学習システムの調整に時間かかっており…間に合わず状態です。

この記事も現在、必死に書いてます(12 月 01 日…当日…)

文章の修正に関しましては、元ITスクール講師 の 葉月さんを含めた講師チームが現時点で追加対応を行っており、 元塾教師(国語担当)の 03 氏や Snow Monkey テーマカスタマイズを個人的に教えている弟子たちに不明な部分をどうしたら理解可能かなど協力していただいてます。
2021 年中にはさらに充実した逆引きされた説明記事が公開されていくようになるはず…です。引き続き協力をお願いします。(謝辞とプレッシャーの付与)

さまざまな自動化も行う

コロナ禍でもあり、お金にならないことをする余裕はないので、記事の編集も可能な限り人力ではなく自動化する方向で進めています。
さらにいくつかの自動化について…語ってみます。

NotWiz の詳細解説は、すべて人力で、1記事20〜25時間ほど詳細に調査して書き下ろしていました…。結果、時間的コスト含めると大赤字化へ。

説明文章校正を自動で行ってみる

説明文章をわかりやすくする為、文章を統一を目指すことにしました。 その為に、文章の統一を行う校正エンジンを使うことに。

既存の校正エンジンの問題…

WordPress では文章校正のプラグインは山ほどあるのですが、ほとんどが英語文章用だという事に気がつきました。

日本語文章やプログラミング用語を校正するのは結構難しいので、ここでは Python 言語を使用して独自に校正エンジンを組んでいくことにしています。

校正エンジンの作り方については割愛します。機械学習系の文献を参考にしてください。

この校正エンジンのシステムは、言乃葉テナ・プロジェクトの協力をしていただいたものです。(謝辞

公式サポートフォーラムを巡回するようにした

フック解説のサンプルコードをわかりやすくする為の材料として、公式サポートフォーラムを巡回し、多くのサンプルコードなどを収集 + 収集ルールなどを機械学習する仕組みも作ってみました。

そこから、「逆引き」と言うネタもでていたので、「逆引き」サイトを目指すことにしました。

カスタマイズ記事の機能は、まだ試している段階ですのでほとんどありません。2021 年中に安定した記事更新の自動化を行っていく予定です。しばらくお待ちを…。

校正ルールを作った

正しい日本語を校正するルールをしっかりと作るのは難しいので、簡単なルールを適用しています。

まず、「HTML が記述できます…」と言う文章を変更するなどのルールを作っています。 「HTML が記述できます…」を修正した理由として、最終的な結果は HTML になるかもしれませんが、そのタイミングで処理した結果を別のフックで処理させる使い方もしており、必ずしも HTML を出力するべきではないからです。

その他に簡単なものですと Snow Monkey と言う表記が Snow Monkye など、タイポされることが多いので、そう言ったタイポの判定です。

タイポの校正パターンは2018年からのキタジマ氏のタイポを全力で学習させました。キタジマ発言に関する校正精度は高いはずです。

が、それでもすべてのタイポを検出できないタカシのタイポ。新作タイポネタをよく思いつくね、タイポ名人のセンスありすぎでしょ……(やめてさしあげろ

このタイポ修正エンジンのシステムは、言乃葉テナ・プロジェクトとナギサ氏の協力をしていただいたものです。(謝辞
そして、学習精度を上げる為にタイポのネタ提供は、タカシです(勝手に発言を学習素材として使っています…

カスタマイズ記事とフック説明を紐づけてみた

Happy Snow Monkey を参考にした部分やミートアップ時の逆引きと言うネタから…
解説を解りやすくするには、ただのフック一覧ではなく、フック一覧と連動した記事メディアの方が良いと考えました。

その為に、記事内のフック名に一致するフックを「関連フック」としてリンクさせる為に関連フックのプラグインを作ることにしました。

リアルタイム検索を導入してみた

フック 1 つにつき 1 ページで対応していたのですが、リファレンスメディアとなるならサクサクと検索できるようにする必要性も考えました。

その為に、検索は Ajax を利用し、リアルタイムでの検索結果反映をする仕組みにしてみました。

しかし、Snow Monkey 用にも RealTime Search プラグインを試行錯誤して作ってはみたのですが、導入するには至りませんでした。

高速化…してみよう

多くのカスタマイズをしてみると…非常にページ表示速度が遅くなってしまうんですね…。
業務でサクサクと調べたい時でも使える解説メディアとしてページ表示の遅さも大きな問題だなーと思いました。

その為に多くの高速化をやってみました。

余談:私の場合(脱WordPress + GatsbyJS で再構築)

WordPress で、単純なブログサイトやコーポレートサイトを高速化するのは多くの場合にできることだと思います。
キャッシュやその他プラグインの調整で改善することが多いからです。

しかし、校正エンジンやその他を積んだ VPS サーバのメンテナンスも含めていくと、(時間もお金も)コストが大変になってしまいます。
何らかの機能などを追加対応すると、それに対しても高速化しないと、ページが重くなると言う運命に収束されていく。

ページが重いと言う運命に収束してしまうなら、WordPress って言うシステムの世界線を超えるしか無いなぁと…思います。
はい、これが定説です(「運命は必ず決まっていて収束します。それは定説です」ってだけの某カルト宗教の迷言ネタです。ネタです。深い意味はないです…はい)

そして、少し情報のやり取りを増やそうとすれば、WordPress の古臭い REST API の仕様や手続き処理が面倒に絡んできました。
ブロックエディターのたびたび変更される DOM も問題です。外部からのコンテンツ文字列操作をさせないつもりなのかすごく辛い。

いっその事…と、 WordPress + Snow Monkey から、別の仕組みを開発することにしました。

幸い、私は開発に強い人間ですし、システムを作るのは苦痛ではなく、楽しくできることです。
Yes Code, No Life!!(ノーコードじゃないので Yes でも良いよね)

最終的に「逆引きゴリラ」では、静的サイトジェネレータである GatsbyJS を最終的な出力などに利用しています。
GatsbyJS は、 Gutenberg と同じように React を使用して静的サイトを構築できますし、REST ではなく GraphQL を使用しています。
また、プラグインで Python と連動しやすく、WordPress で書いた記事を Markdown などに変換するのも簡単にできます。

GraphQL の学習や、機械学習(Python)の技術をより習得するためにも、面白い挑戦ができると思いましたし、 GatsbyJS で使用する為に開発した React の処理の多くを、同じ React で開発可能なカスタムブロックの開発でほぼそのまま利用もできます。

WordPress の制作に移植する際でも無駄になりません。むしろ、こういった WordPress 外のシステム開発をすることで見える事の方が多かったです。

WordPress の世界の外を見るのはけっして悪いことじゃないと思います。
もし、 WordPress 外の仕組みに再構築する場合、WordPress にも活かせるシステムで制作するのもお勧めしたいと思います。

仕組みとしてこんな感じです。

ローカルの Mac サーバ:(自動化分)

  • Automator、Swift などで外部の Snow Monkey 系のサイトから情報収集する
  • Python を使い、言語解析を機械学習し収集した記事の分別
  • ローカルの WordPress に、調整したテキストを WordPress CLI やら API やらでぶちこむ
  • Gutenberg のカスタムブロックと外部連携により、タイポなどの校正エンジンで一部を自動テキスト変換
  • WordPress のプラグインで、収集された記事を Markdown 形式に変換(Snow Monkey をシステム的に各プラグインに繋ぎ込んだ使い方をしてます)
  • 変換が終了したらメール送信

私の作業:

  • メール送信された記事の Markdown を編集
  • GatsbyJS のビルドアクションに登録

ローカルの Mac サーバ:(自動化分)

  • GatsbyJS のビルド
  • Git にコミット

となっています。自動で処理される範囲が大きいので人力コストが凄く減ってます。

最後

何かの縁なのか、公式リファレンスの文のコピーから逆引きゴリラの公開になった期間も約 3 ヶ月くらい…。
基礎の仕組み自体は 2 週間ほどで作っているのですが、フック調査や機械学習システムの調整が時間かかってしまってます…。
解説メディアをやるなら、きちんと調査したものを公開したかったのですが、まだまだ完成と言えない状態で公開してしまい、何かとすみません。

フックを調べていくうちに、 WordPress やそのプラグインを使用して開発をするべきでないシステムだと気づくかもしれません。
または、フックを調べていくうちに、より良いシステムが作れることに気が付くかもしれません。

フックの調査や解説や説明メディアを作ってみるのは、きっと、あなたにとっても掛け替えのない経験になるでしょう。
興味があれば作ってみてください。

最後の最後に(余談 + 本音

どーも…色んな事を見ていくと、売れる為にコンテンツ制作とか学習してる人が多い感じもするんですが、 「勉強していると言うスタイルだけ出している人が多い」と思うことが多々あります。

実際に Snow Monkey のサポートフォーラムでも回答をしてあげれば、伸びている方と伸びていない方がいる。
伸びている方は良いと思います。しかし、サポート受けて解決さえすれば終わりなのは、残念な方だと思います。

そう言う残念に思ってしまう方々が、別の所で案件を取ろうとしている。
お客さんの案件に対して、サポートフォーラムで回答された内容のまま対応して終わっている。
あのね、それで「勉強してます。案件ください」って言うスタイルをするのは、やめた方がいいです。
それで、勉強してると良く言えますね…って思います。

たまに言われていた誤解もありますが、私がサポートフォーラムの回答をしたことで金銭を得ていません。(私がサポート料金を頂いたことはありません
しかし、その人たち…案件で金銭得てますよね?
そう言った人の仕事を代わりにする人間でもないですよ。それに、サポートフォーラムもそういう場じゃないですよ…。
まあ、そういう方々が質問してくることって今はそう無いのですが。

私がサポートフォーラムの回答を公式の人間でも無いのに、なぜやっているのか…と聞かれる事もありましたので、ここに再度書いときます。

Snow Monkey のコントリビューターで、あるから。Snow Monkey の 1 ユーザーであるから。
Snow Monkey がユーザーの貢献で成長するプロジェクトであると知っているから。
回答を受けた方や、フォーラムを閲覧した人たちが Snow Monkey 制作に対し、新しい知見を知り、 そこからまた新しいサービスや知見、またはテーマにとっても良い進化が生まれ続ける…それを目指しているから。
後は、ごくたまーにですが、「この質問を調べるのは面白そうだ」と言う場合もあります。
その時の知的好奇心が満たされる感じが、心地よいからです。

それだけで、公式開発者でないユーザーであるけれども、回答すると言う行為を時々しています。

だからこそ、Snow Monkey の公式サポートフォーラムでサポートをしてもらえば案件で困った時も解決できるとか言うことを言う人がまだ居るのは、 正直…「やめれ!」って思っています。
そう言う人のやり方は、ウェブ制作者としてのマナーも…ねーです!

そして、「Snow Monkey だからできた」ってサポートフォーラムで回答を受けただけの人が、自分でできたように言うのやめような。
いや、別のテーマでも簡単にできるよ?って。それ、Snow Monkey でサポートを受けることで自分は何も考えずにできたから Snow Monkey だからできた って言いたいだけちゃうんかと。
その後に案件募集のツイートをするの頭おかしいんちゃうんかと。まず、それくらいの対応を自分でできるようになってから案件を取らんと苦労するで。ホンマに。
サポートフォーラムを自分の案件解決に使うのは間違いやからな。
Snow Monkey 使う場合でも、最低限のことはまずは自分で試してから案件取りや?客に迷惑かけてまうで?

何が Snow Monkey でできるかまず知ってから案件取るの大事やで。
“何でもできるテーマ”じゃないからな。そんな”何でもできるテーマ”をキタジマタカシが作れると思っているのなら…そんな幻想はぶっ壊した方が良いで…。

何でもできるテーマなら、「Snow Monkey とは何ぞや」を考える会など開かれませんで。
「なんでもできるテーマ」って言えば良いだけや、それならな。
何でもできる訳では無いからこそ、「Snow Monkey とは何ぞや」とか「Snow Monkey に合うカスタマイズとは」も、それぞれの制作者が自由に考えることができるんやで。

何でもやりたいって言うのも解るんですが、それぞれのテーマにあった”らしさ”、合っているカスタマイズの方向性って言うのも有ります。
それって、Snow Monkey にもあります。
それは、Snow Monkey のスタイリングの仕様やら、フックを知り、またカスタマイズを幾つもしていけば、きっと理解が深まっていきます。

Snow Monkey に合うカスタマイズの方向性は、それぞれが調べながら見つけ出すしかないです。
開発者のキタジマタカシであっても 100% の答えを出せないと思います。正解もないでしょうし。答えようもないでしょう。
なぜなら、それぞれの Snow Monkey は、その人だけの Snow Monkey として育っていますし、育てることが可能だからですね。

私の Snow Monkey も、あなたの Snow Monkey と異なっていますし。
私の Snow Monkey は、システムで言えば、外部のシステムと連携や GatsbyJS と連携したマークアップもしています。猿じゃない…システム面に特化した暴走ゴリラに成長してしまった…(汗)

例えば…もし、他のテーマに似たスタイリングを Snow Monkey で再現したりすれば、再現させたサイトに近い Snow Monkey にもなるはずです。
そして、仕草と育て方によっては、やがて「類人猿」にもなるっぽいです(笑)

多分、そう言う方の育てた Snow Monkey って、私の Snow Monkey でできない仕草……一杯できるんでしょうね。 どういう仕草ができているのか…興味ありますね。

もし、あなただけの Snow Monkey を育てたいとか、何からはじめたら良いのかわからないなら、育て方をサポートフォーラムに相談するのも良いでしょうし、 フックを調べることでキッカケを見つけるとかしてみるのも良いでしょう。

意外と面白いです。勉強にもなるはずです。
猿からゴリラに進化してしまうかもしれませんが。

以上です。