私には良いスタートに思えます。あとは、これで実際に面白いことができるようになるのを学ぶだけです。
最初の計画は、データベースをクエリするコードを書いて、post_custom_fields テーブルから必要な値を取得し、それをトピックページで使用することです。これは、ベテランのモデレーターチームからリクエストされた小さな機能です。
明日は Git からプルして、他のプラグインからのサンプル DB コードを探し始め、どこまで進められるか見てみます。
@j.jaffeux さん、ありがとうございました。
小さな一歩でも積み重ねることが大切です。私のような初心者向けの Discourse プラグイン作成者にとって、このようなジェネレーターがあることは非常に感謝しています。下の画像をご覧いただければ、開発を待っているのがお分かりいただけるでしょう：
長年にわたり、vBulletin 用の無数のプラグインを作成してきましたので、Discourse 用のシンプルなプラグインを作ることにとてもワクワクしています。信じてください。
@j.jaffeux さん
こんにちは。Discourse プラグインについて学んでいる最中です。今日、このプラグインジェネレーターに戻り、macOS の開発環境で試してみました。アプリは正常に動作しており、Ruby や Rails の学習、小さなプラグインの開発を多く行っています。
# cd /var/Tim/Discourse/plugins
# rails g plugin DiscourseRacoon
# bundle exec 'rails s'
すべて順調に進み、プラグインも正常にインストールされました。
しかし、以下のルートにアクセスすると動作しません。
http://localhost:3000/discourse_racoon
基本的なプラグインを生成した後、プラグインのルートとコントローラーは OOTB（すぐに使える状態）で動作するはずだと考えていましたが、間違っていますでしょうか？この場合のプラグイン名は DiscourseRacoon です。
いくつかのオンラインリファレンスを確認したところ、ルートが存在するか確認するよう指示されていました。そこで routes.rb を確認したところ、ルートが定義されていました。また、discourse_racoon_controller.rb も確認し、コントローラーに index メソッド（アクション）が存在することも確認しました。
申し訳ありませんが、より興味深いプラグイン開発と Discourse の扱いにまだ苦労しています。どこが間違っているのでしょうか？デバッグの次のステップについてのアドバイスはありますか？
よろしくお願いいたします。
/discourse-racoon であり、/discourse_racoon ではありません
rake routes | grep racoon
discourse_racoon /discourse-racoon DiscourseRacoon::Engine
GET / discourse_racoon/discourse_racoon#index
actions GET /actions(.:format) discourse_racoon/actions#index
GET /actions/:id(.:format) discourse_racoon/actions#show
@j.jaffeux さん
ありがとうございます！
その通りでした。
これは Rails の慣習で、アンダースコアで定義されたすべてのルートがダッシュでアクセスされるというルールを学ぶ必要があるのでしょうか？
DiscourseRacoon::Engine.routes.draw do
get "/" => "discourse_racoon#index", constraints: DiscourseRacoonConstraint.new
get "/actions" => "actions#index", constraints: DiscourseRacoonConstraint.new
get "/actions/:id" => "actions#show", constraints: DiscourseRacoonConstraint.new
end
こんにちは、
このジェネレーターで「Hello World」プラグインを生成し、Ruby の「ファイルへの書き込み」に関するステートメントをいくつか追加して、Rails のライフサイクルを観察しました。その結果、Rails コントローラーが期待通りに動作していないことがわかりました（ログ出力が行われず、無視されている様子でした）。
デバッグを行った結果、Rails コントローラーを1つ上のディレクトリに移動させることで、期待通りに動作させることができました。
さらに、メインのインデックスページ用の JavaScript/Ember コントローラーとテンプレートを追加し、すべてのテンプレートに HTML と CSS を追加しました。また、クッキーを読み込んでテンプレートをハイライト表示するための JavaScript コードも追加しました。
例えば、Rails プラグインジェネレーターで生成されたプラグインをいくつか変更した後の様子は以下の通りです：
http://localhost:3000/hello-world/
詳細とスクリーンショットについては、以下をご覧ください：
最後に、この Rails プラグインジェネレーターを提供してくれた @j.jaffeux さんに感謝申し上げます。Rails コントローラーのデバッグに多くの時間を費やし、Rails のライフサイクルと JS テンプレート/コントローラーを検証するためのコードを追加して改造する過程を楽しみました。
私の変更が、私のように余暇を使ってプラグイン開発の基礎を学んでいる Discourse ユーザーや、Rails プラグインジェネレーターを利用したい方のお役に立てれば幸いです。
関連情報：
現在、Rails と Discourse プラグイン開発の学習プロセスの一環として、壊れたプラグインのデバッグと修正に熱中しています 
これを解決してくれてありがとう、@neounix！これが私のプロジェクトを前進させるための後押しになるかもしれません。
@j.jaffeux さん、これらのファイルを移動させることが推奨される解決策でしょうか？それとも、以下のような方法で含めるべきでしょうか？
load File.expand_path('some-path-here', __dir__)
私は含めることを試みたと思うのですが、その際「何かの欠落」というエラーが発生しました（つまり、間違ったことをしたのだと思い、正確にドキュメント化する価値はないと思われます）。
編集：どうやらコントローラーは /plugin-path にアクセスした際に実際に読み込まれ、実行されるようです。
こんにちは、@pfaffman さん
当初は、plugin.rb 内で load 文を使って Ruby コントローラーを読み込もうとしましたが、期待通りにログが出力されませんでした。
Ruby コントローラーのテストでは、ファイルシステムにログを出力する Ruby 文を使用してテストし、そのログファイルに対して tail -f を実行して、コントローラーがどのように発火するかを確認しました。
昨日は楽しみのために、Rails コントローラーを使ってすべてのプロセスの ENV 変数を読み取り、それをクッキーに格納し、Ember コントローラーを使ってアプリに書き込むコードを書きました。
本当に面白かったです！
中毒になってしまいました LOL
URL 部分は左側に、Ruby コードの参照は => の右側にあります。_ と - の違いは、エンジンの mount 行で定義されています。
@eviltrout のプラグインガイドの第 4 部では、プラグインを Discourse のコードベースの外で開発し、plugins ディレクトリにシンボリックリンクを設定することが推奨されています。
プラグインを別のディレクトリに生成し、必要に応じてシンボリックリンクも設定するために、-d ~/path/to/plugin_src オプションを追加するのは理にかなっているでしょうか？
申し訳ありませんが、現時点ではこれを非推奨とし、トピックを閉じる可能性があります。
カスタマイズの柔軟性は劣りますが、現在プラグインを立ち上げるための推奨方法は、GitHub - discourse/discourse-plugin-skeleton: Template for Discourse plugins · GitHub をテンプレートとして使用することです（緑色のボタン「USE THIS TEMPLATE」を参照してください）。
こちらの方が、私たちが最新の状態に保つのがはるかに簡単です。