Rails plugin generator

Most of your comments should be addressed by:

https://github.com/discourse/discourse/commit/d40d241e72905dc044f771af5989f3b56809b61d

https://github.com/discourse/discourse/commit/acc96abe1a4abb16363fec75d0a2d7fd803a7f25

13 Likes

I was just testing a theory about the origin of an issue in the elections and qa plugins, and needed to test some logic in isolation. Normally I would create a new plugin by hand to do this, but this time it was much easier using the plugin generator, just a single command. Useful already :slight_smile: Thanks.

I was getting a NameError though on initial load after generating a plugin (I had removed tmp). The plugin.rb includes an auto-generated enabled_site_setting out of the box, but the setting isn’t defined in config/settings.yml. If you add the setting, the error goes away. We’ll need to either remove the auto-generated enabled setting or add a config/settings.yml with the auto-generated enabled setting included by default.

6 Likes

Agreed.

Should be now correctly handled by:

https://github.com/discourse/discourse/commit/90e67b671b6d8c33c2c0bd0817a4e064a01a05ca

4 Likes

This is adding support for controller/routes/spec/acceptance:

https://github.com/discourse/discourse/commit/2dfb097dd94911676c99c71434be223b5af98410

2 Likes

:heart_eyes: Absolutely love this, @joffreyjaffeux! I have a local templated plugin that I use for this exact purpose. I can create the git repo and then copy/paste the files into the directory to create the “Initial commit.” So I can easily see us using this heavily at ProCourse.

Notes about potential enhancements:

  • Looks like you have MIT as the license that comes with this. Most of our plugins are license free since they are proprietary and private. The code is owned by the client. But we have a fair number of clients who choose to share their commissioned work with the world and as such we drop in a GNU GPL v2 license on the repo. It’s been a challenge nailing down a license to use for those, but the general thinking is that it should follow core. My ask here is whether or not it should allow us to choose a license to be included.

  • Include license URL in about section? We do this as part of themes already. It would likely be a good thing to do the same for plugins and then link to the license on the /admin/plugins page.

  • I have a tendency to build plugins using a dedicated /my-plugin/lib/my-plugin/engine.rb file with an associated /config/routes.rb file. The plugin.rb file is great for showing me where to start, but I use it as a collecting zone for the structure of the plugin. The actual logic is stored in the engine file. I’d love for this to allow a one liner that creates that structure automatically.

  • I can see how this could evolve in the future as well. Maybe a way to standardize the way plugins are built. For example, from the plugin directory, rails g plugin i18n en.js.my-plugin.my-localization-string. But it could be used to add plugin settings, routes, jobs, etc… Not sure how much I would personally use this because I know these structures and how they work. But for those new to the system, it could lower the learning curve a bit.

  • More flexible about section? We use the Author line as ProCourse for every new plugin as opposed to the GitHub username. We also make sure the URL of the plugin is a full URL and not a link to the GitHub profile. Maybe it’s just me, but it seems like you could take the Name sent to the generator and the GitHub username and assume the repo name matches the name of the plugin (lowercased and dasherized). But I could see that causing issues in some places as well.

  • Local defaults? This may just be the nature of my business, but I find myself (or a team member) creating a new plugin structure two to four times a week, sometimes more. And we have a set structure for the about section that we use. It would be great if we could save some defaults locally that work every time without the need to answer the questions each run.

That’s my first run through it. I’ve run it a couple times and can already see it speeding up the process significantly. Thank you! :hugs:

12 Likes

Thx, great points. Could you send me (in PM if necessary) an example plugin demonstrating the above points please ?

I just finished creating a public version of this. That way others can use it as well and I can share links to specifics since I realized there are some more points that I do.

  • Whenever I add custom routes to a plugin, I always use a Constraint that ties to the plugin enabled setting. This prevents the routes from existing unless the site setting is true. I wish I saw this more in plugins as custom routes shouldn’t be allowed just because the plugin is installed.

  • This template includes a Rails controller and an Ember route. These are only used in about half of the plugins I do, but it’s nice to have them there just so the structure already exists. I don’t know that this generator needs to include these pieces, but it’s helpful on my end.

  • I always start my stylesheets with a global class selector. Every time I add HTML to the plugin, I start with a wrapper div with class="discourse-plugin-template". That ensures that my styles only apply to my custom code. Sometimes I need to add CSS outside of that selector, but it seems like most cases don’t have that requirement.

9 Likes

The ‘built-in’ method for this is to use requires_plugin in the plugin controller. I agree that this isn’t used as much as it should be though, even in official plugins. (Example here, defined here)

9 Likes

Just created a plugin with name “TrustLevelGroups” using plugin generator, after that can’t run server cause an error

1 Like

Out of the box I get a similar error

I have several fixes on my local branch… been using it a lot recently. Will push soon.

6 Likes

Newbie note: you must run the generator in the Discourse source directory (that’s /src if you use Docker). Otherwise you’ll just get confusing error/help messages about how the parameters are incorrect for rails new.

4 Likes

There seems to be a mismatch between the plugin generator and this post. Specifically, the Beginner’s Guide suggests to create the javascript initializer with the following directory and naming structure:

plugins/basic-plugin/assets/javascripts/discourse/initializers/alert.js.es6

However, the plugin creates the javascript initializer at

plugins/discourse-racoon/assets/javascripts/initializers/discourse-racoon.es6

Personally, I was having issues with the javascript loading after using this plugin until I changed the directory and naming structure to match the Beginner’s guide. Should the package be updated?

3 Likes

Yes would be better indeed.

3 Likes

Yes I had to rename the JavaScript extensions but the structure worked for me.

this thing breaks for me.

Cant help you, you give me no context. What did you type? where did you type it? clean or exisisting state?

6 Likes

I followed this tutorial https://meta.discourse.org/t/beginners-guide-to-creating-discourse-plugins-part-1/30515. Just installed and worked so guess its clean.
I typed:

bundle exec rails g plugin cidian

No it’s not clean as you have followed this tutorial to create a plugin, and the error is likely in what you typed while following the tutorial.

The error is very clear to me: mount ::cidian::Engine, at: "/cidian" is invalid. You should fix this in your code.

2 Likes

First of all: I dont know ruby (yet) as I will start from the front end.
this code was produced by this plugin generator. so its not my fault. Its the generators fault. I typed nothing while following the tutorial. I just followed the development environment setup guide for ubuntu. Before running the generator the local discourse instance worked fine.
https://github.com/discourse/discourse/blob/master/lib/generators/plugin/templates/plugin.rb.erb
to be very clear: I am just at the first page of this tutorial. specifically the part that links to this plugin generator.