Hey Discourse Plugin Gurus, Just a quick question about Discourse plugins and Rails initializers. If a Discourse plugin has a directory called “config” and a subdirectory under “config” called “initializers” does the Discourse Rails app read all the plugin initializer files under the “initializers” directory like Rails 6 does? The reason I ask is that I’m in the middle of writing a “back office” Rails 6 application (Rails only, no EmberJS or other JS framework on top) from scratch for a client and I have a directory under initializers like this: ./config/initializers/client/ … and all the initializers unique to the client are in the “client” subdirectory. Rails 6 reads all files under the standard initializers directory (even subdirectories); and so I was wondering if Discourse plugins, with a similar directory structure for initializers, will behave as Rails 6 does and read all the initializers in the plugin in a manner like this: ./plugins/my_plugin/config/initializers/myclient/ client_initializer1.rb client_initializer2.rb client_initializer2.rb … without registering these assets in the plugin.rb file? Thanks! PS: I looked in about 10 Discourse plugins on GitHub and none of the ones I looked at had initializers under the config directory. That’s why I decided to post the question (and my Rails dev environment is not set up for Discourse at the moment, it’s all setup for the client).

[image] fzngagan: After skimming through this Ruby on Rails Guides: Configuring Rails Applications Yeah, I read that Rails guide a lot lately. Basically, I’m “OK” with how Rails 6 config works (still learning, but getting more and more comfortable each day). I am just wondering if we can use the same structure in a Discourse plugin (for initializers), if Rails will read the initializers in the subdirectories like they do in Rails 6; or do we have to register the plugin initializer directory as a configuration “asset” (for a lack of a better word) in plugin.rb. I was reading up on Rails plugins yesterday and comparing a bit as well.

[image] neounix: I am just wondering if we can use the same structure in a Discourse plugin (for initializers), if Rails will read the initializers in the subdirectories like they do in Rails 6; or do we have to register the plugin initializer directory as a configuration “asset” (for a lack of a better word) in plugin.rb. Discourse doesn’t read any ruby file other than plugin.rb as far as I know. It does read the js and config files. All the ruby files have to be required in plugin.rb.

I believe so too. You load any additional Ruby files you need from within plugin.rb. Here’s an example from the Follow plugin: plugin.rb 0290c4282 after_initialize do Notification.types[:following] = 800 Notification.types[:following_posted] = 801 Notification.types[:following_replied] = 802 PostAlerter::NOTIFIABLE_TYPES.push(Notification.types[:following]) PostAlerter::NOTIFIABLE_TYPES.push(Notification.types[:following_posted]) PostAlerter::NOTIFIABLE_TYPES.push(Notification.types[:following_replied]) PostAlerter::COLLAPSED_NOTIFICATION_TYPES.push(Notification.types[:following_replied]) %w[ ../lib/follow/engine.rb ../lib/follow/notification.rb ../lib/follow/updater.rb ../app/controllers/follow/follow_controller.rb ../config/routes.rb ].each do |path| load File.expand_path(path, __FILE__) end add_to_class(:user, :following_ids) do

[image] fzngagan: Discourse doesn’t read any ruby file other than plugin.rb as far as I know. It does read the js and config files. All the ruby files have to be require d in plugin.rb. That’s kinda my impression reading though a number of Discourse plugins on GitHub. Seems Discourse only reads plugin.rb and we have to load all other Ruby files we might want, like initializers, in plugin.rb. However, I was hoping I was wrong and there might be a “deeper” integration of Discourse plugins and Rails; as I have been getting very spoiled on how great Rails 6 is. [image] merefield: I believe so too. You load any additional Ruby files you need from within plugin.rb. Here’s an example from Follow plugin: Thanks for confirming as well.

[image] neounix: However, I was hoping I was wrong and there might be a “deeper” integration of Discourse plugins and Rails; as I have been getting very spoiled on how great Rails 6 is. I think there should be a way to require initializer code in plugin.rb too. Did you try this in plugin.rb Rails.application.config.before_initialize do # initialization code goes here end

[image] fzngagan: I think there should be a way to require initializer code in plugin.rb too. Did you try this in plugin.rb Yes, that is not a problem calling and loading the initializers in plugin.rb. The reason for my question was because I am currently writing a fairly large Rails 6 app for a business, converting their legacy back office scripts (over a few decades) to a Rails app, and to add initializers, I just have a subdirectory under config/initializers (in Rails) and all my initializer files are included so nicely without any need to write any code to include these files in Rails. Thanks for all your replies. Much appreciated!

[image] fzngagan: live reload the ruby files without restarting the server This is what reloadable_patch is for. If you wrap ruby class changes in reloadable_patch, it should live reload!

[image] markvanlan: If you wrap ruby class changes in reloadable_patch , it should live reload! Can I wrap the whole plugin.rb file inside it for dev? More seriously, how far can we go with it? Also, adding new files or changing any yml files needs a server restart right?

You shouldn’t have to do a reloadable_patch for everything. Many of the methods defined in instance.rb to make plugin development easy, use reloadable_patch internally like add_to_serializer. lib/plugin/instance.rb 66402abe9 @admin_route = { label: label, location: location } end def enabled? @enabled_site_setting ? SiteSetting.get(@enabled_site_setting) : true end delegate :name, to: :metadata def add_to_serializer(serializer, attr, define_include_method = true, &block) reloadable_patch do |plugin| base = "#{serializer.to_s.classify}Serializer".constantize rescue "#{serializer.to_s}Serializer".constantize # we have to work through descendants cause serializers may already be baked and cached ([base] + base.descendants).each do |klass| unless attr.to_s.start_with?("include_") klass.attributes(attr) if define_include_method # Don't include serialized methods if the plugin is disabled klass.public_send(:define_method, "include_#{attr}?") { plugin.enabled? } Ideally our plugin api is good enough that you shouldn’t have to do an insane amount of reloadable_patch’ing. [image] fzngagan: Also, adding new files or changing any yml files needs a server restart right? Yeah, this is true. I wonder if anything can be done about the yml file changes; that one annoys me personally.

Discourse Plugins and Rails 6 config/initializers Question

Development

fzngagan (Faizaan Gagan) October 27, 2020, 1:52pm 10

Yeah, I would love those rails perks being ported to discourse plugins. One of my personal favourite would be able to live reload the ruby files without restarting the server.

Topic		Replies	Views
Developing Discourse Plugins - Part 1 - Create a basic plugin Developer Guides plugin-guides , tutorial	32	85670	July 8, 2025
Rails plugin generator Announcements	49	13989	August 20, 2021
Is it possible to use a local plugin directory with a docker install? Development	39	3580	June 16, 2022
Transforming simple ruby files into a ruby gem Development	5	1152	December 14, 2018
Package a Discourse plugin as a gem Developers plugin-guides , how-to	4	741	July 27, 2023

Discourse Plugins and Rails 6 config/initializers Question

Related topics