Most of your comments should be addressed by:
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 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.
Should be now correctly handled by:
This is adding support for controller/routes/spec/acceptance:
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
aboutsection? 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
I have a tendency to build plugins using a dedicated
/my-plugin/lib/my-plugin/engine.rbfile with an associated
plugin.rbfile 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.
aboutsection? 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
aboutsection 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!
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
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.
Just created a plugin with name “TrustLevelGroups” using plugin generator, after that can’t run server cause an error
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.
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
Yes would be better indeed.
Cant help you, you give me no context. What did you type? where did you type it? clean or exisisting state?
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.
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.
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.
to be very clear: I am just at the first page of this tutorial. specifically the part that links to this plugin generator.