Discourse Version: 2.9beta10
Plugin Commit: FIX: straighten-out wizard-level subscription features · paviliondev/discourse-custom-wizard@12cd8ac · GitHub
https://cablogstaging.discoursehosting.net/admin/plugins/subscription-client/suppliers
Nothing in forum/browser logs
Strange, haven’t seen this before. It’s possible it’s related to your hosting. I’ll chat with @richard .
The only thing worth mentioning is that every site we host is always a multisite, regardless of the plan.
hm ok. Nothing is standing out to me, and like I said, this is the first I’ve seen this.
@richard Can you think of any reason why this wouldn’t work on your servers?
See also
https://github.com/paviliondev/discourse-custom-wizard/blob/main/plugin.rb#L8
@richard It performs a request to get “Provider” data here
But any connection errors are stored in the plugin store, and there’s nothing there on JR’s instance.
This suggests to me that it’s not even finding the Custom Wizard plugin, i.e. that find_plugin code isn’t working for some reason.
@Jrgong @richard I’ll add some more logs in there on Monday so we can get a clearer picture as to why it’s not working in this environment.
I can confirm this is a multisite issue. The table in the multisite master database contains the supplier, the table in the other multisite databases do not, so /admin/plugins/subscription-client/suppliers returns an empty json response.
Quick (and dirty!) fix below, but there might be more issues, didn’t test that, it’s late already.
--- a/plugin.rb
+++ b/plugin.rb
@@ -39,7 +39,9 @@ after_initialize do
load File.expand_path(path, __FILE__)
end
+ RailsMultisite::ConnectionManagement.each_connection do
SubscriptionClient::Resources.find_all unless Rails.env.test?
+ end
User.has_many(:subscription_client_suppliers)
It occurred to me that it is highly undesirable to execute the find_suppliers function during startup. It introduces a direct dependency to network connectivity and external services, preventing delaying Discourse to start when one of those fail take more time .
Could this be done in an async job that is triggered upon plugin initialization? The additional benefit is that this gives you automatic multisite capabilities since Discourse will trigger a separate job for each individual multisite member.
Thanks, I’ll take a look at this approach on Monday.
It doesn’t prevent startup if the connectivity fails.
Yes, I’ll consider that.
Thanks 
@richard @Jrgong Sorry this has taken so long. I have a new computer and setting up the rspec environment for multisite unit tests proved harder than normal.
https://github.com/paviliondev/discourse-subscription-client/pull/1
@Jrgong once richard reviews this and it’s merged the subscription plugin will work on communiteq’s multisite environment.
Reviewed and found working, going to merge it now, thank you Angus!