discourse/spec/support/sample_plugin_site_settings.yml

discourse_sample_plugin:
  discourse_sample_plugin_enabled: true
site_settings:
  plugin_setting:
    default: "some value"
  test_some_topic_id:
    default: 0
  test_some_other_topic_id:
    default: 0
FIX: Sort plugins by their setting category name (#25128) Some plugins have names (e.g. discourse-x-yz) that are totally different from what they are actually called, and that causes issues when showing them in a sorted way in the admin plugin list. Now, we should use the setting category name from client.en.yml if it exists, otherwise fall back to the name, for sorting. This is what we do on the client to determine what text to show for the plugin name as well. 2024-01-08 07:57:25 +08:00			`discourse_sample_plugin:`
			`discourse_sample_plugin_enabled: true`
DEV: Avoid leaking new site setting states in test environment (#21713) What is the problem? In the test environement, we were calling `SiteSetting.setting` directly to introduce new site settings. However, this leads to changes in state of the SiteSettings hash that is stored in memory as test runs. Changing or leaking states when running tests is one of the major contributors of test flakiness. An example of how this resulted in test flakiness is our `spec/integrity/i18n_spec.rb` spec file which had a test case that would fail because a new "plugin_setting" site setting was registered in another test case but the site setting did not have translations for the site setting set. What is the fix? There are a couple of changes being introduced in this commit: 1. Make `SiteSetting.setting` a private method as it is not safe to be exposed as a public method of the `SiteSetting` class 2. Change test cases to use existing site settings in Discourse instead of creating custom site settings. Existing site settings are not removed often so we don't really need to dynamically add new site settings in test cases. Even if the site settings being used in test cases are removed, updating the test cases to rely on other site settings is a very easy change. 3. Set up a plugin instance in the test environment as a "fixture" instead of having each test create its own plugin instance. 2023-05-25 07:53:57 +08:00			`site_settings:`
			`plugin_setting:`
			`default: "some value"`
			`test_some_topic_id:`
			`default: 0`
			`test_some_other_topic_id:`
FIX: Sort plugins by their setting category name (#25128) Some plugins have names (e.g. discourse-x-yz) that are totally different from what they are actually called, and that causes issues when showing them in a sorted way in the admin plugin list. Now, we should use the setting category name from client.en.yml if it exists, otherwise fall back to the name, for sorting. This is what we do on the client to determine what text to show for the plugin name as well. 2024-01-08 07:57:25 +08:00			`default: 0`