Seems like a good start to me. Now, I just need to learn to actually do cool things with it.
My first plan is to write some code to query the DB so I can get a value I need from the post_custom_fields table and use that on the topics page for a small piece requested by our grey-beard mod team.
Tomorrow I’ll pull it down from git and start searching for sample DB code from other plugins to get me started and see how far I can get.
Every little bit helps and having a generator like this for novice discourse plugin makers like me is much appreciated. You can see it down there on the bottom, begging to be developed:
Still trying to learn about Discourse plugins, I went back to this plugin generator today; and tried this in dev environment on macOS, where the app is running fine and I have been doing a lot of Ruby and Rails studies and small plugins, to learn:
# cd /var/Tim/Discourse/plugins
# rails g plugin DiscourseRacoon
# bundle exec 'rails s'
All seems to go well, and the plugin installs fine:
Am I wrong that the plugin routes and the controller should work OOTB after the generate the basic plugin, in this case DiscourseRacoon?
I went to various online references, and they indicated we should check that the route existed; so I checked routes.rb and there are routes defined there; and I also checked discourse_racoon_controller.rb and the controller has an index method (action).
Sorry, I’m still struggling with more interesting plugin dev and Discourse. What I doing wrong? Any suggestion on what is my next step to debug this?
I assume that is a Rails convention I need to learn? Where all routes defined with underscores are accessed with dashes?
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
I generated a hello world plugin with this generator, added a bunch of Ruby “write to a file” statements and watched the Rails lifecycle, found and the Rails controllers were not working as expected (they would not log, indicating they were were being ignored).
After debugging, I got this to work as expected by moving the Rails controllers up a directory.
In addition, also added a Javascript/Ember controller and template for the main index page, added some HTML and CSS to all the templates and added some JS code to read the cookies and highlight the templates.
For example, after a few changes to the plugin generated by the rails plugin generator:
In closing, I would like to thank @joffreyjaffeux for this rails plugin generator. I had a lot of fun debugging the Rails controllers and enjoyed modifying it to provide more code to inspect both the Rails lifecycle and the JS templates/controllers.
I hope my changes help anyone else who, like me, is still learning the basics of Discourse in plugin dev in their spare time and would like to use the rails plugin generator.
Thanks for figuring this out, @neounix! Maybe this will be the leg up that I need to get my project moving forward.
Hey @joffreyjaffeux, is moving those files the Recommended Solution, or should they be included with something like
load File.expand_path('some-path-here', __dir__)
I think that I tried including them , but then got some error about a missing. . . something (so I presume I did the wrong thing and it’s not worth documenting exactly).
EDIT: It looks to me like the controller does indeed get loaded/run when hitting /plugin-path.
I originally tried to load the Ruby controllers with load statements in plugin.rb but they would not log as expected.
When I tested the Ruby controllers I tested with Ruby statements to log to the filesystem and ran a tail -f on that log file to test how the controllers fire.
For fun, I ended my day yesterday writing some code to read all the process ENV vars into a cookie with a Rails controller and writing them to the app with the Ember controller.
In Part 4 of @eviltrout’s plugin guide, he recommends developing the plugin outside of the discourse code base and setting up a symbolic link in the plugins directory.
Would it make sense to add a -d ~/path/to/plugin_src option to generate the plugin in a different directory, and possibly also set up the symlink?
