mirror of
https://gh.wpcy.net/https://github.com/discourse/discourse.git
synced 2026-04-30 05:31:36 +08:00
19af83d39e
This commit introduces the concept of themeable site settings,
which is a new tool for theme authors that lives alongside theme
modifiers and theme settings. Here is a quick summary:
* Theme settings - These are custom settings used to control UI and functionality within your theme or component and provide configuration options. These cannot change core Discourse functionality.
* Theme modifiers - Allows a theme or a component to modify selected server-side functionality of core Discourse as an alternative to building a plugin.
* Themeable site settings (new) - Allows a theme (not components) to override a small subset of core site settings, which generally control parts of the UI and other minor functionality. This allows themes to have a greater control over the full site experience.
Themeable site settings will be shown for all themes, whether the theme
changes
the value or not, and have a similar UI to custom theme settings.
We are also introducing a new page at
`/admin/config/theme-site-settings` that
allows admins to see all possible themeable site settings, and which
themes
are changing the value from the default.
### Configuration
Theme authors can configure initial values themeable site settings using
a section in the `about.json` file like so:
```json
"theme_site_settings": {
"search_experience": "search_field"
}
```
These values will not change when the theme updates, because we cannot
know if admins have manually changed them.
### Limitations
Themeable site settings are only really intended to control elements of
the UI, and when retrieving their value we require a theme ID, so these
limitations apply:
- Themeable site settings cannot be used in Sidekiq jobs
- Themeable site settings cannot be used in markdown rules
- Themeable site settings will be cached separately to client site
settings using theme ID as a key
- Themeable site settings will override keys on the `siteSettings`
service on the client using the application preloader
- `SiteSetting.client_settings_json` will not include themeable site
settings, instead you can call `SiteSetting.theme_site_settings_json`
with a theme ID
### Initial settings
There are only two site settings that will be themeable to begin with:
* `enable_welcome_banner`
* `search_experience`
And our new Horizon theme will take advantage of both. Over time, more
settings that control elements of the UI will be exposed this way.
35 lines
1.2 KiB
Ruby
35 lines
1.2 KiB
Ruby
# frozen_string_literal: true
|
|
class BackfillThemeableSiteSettings < ActiveRecord::Migration[7.2]
|
|
def up
|
|
initial_themeable_site_settings = %w[enable_welcome_banner search_experience]
|
|
|
|
initial_themeable_site_settings.each do |setting|
|
|
db_data_type, db_value =
|
|
DB.query_single("SELECT data_type, value FROM site_settings WHERE name = ?", setting)
|
|
|
|
# If there is no value in the DB, it means the admin hasn't changed it from the default,
|
|
# and theme site settings will just use the default value.
|
|
next if db_value.nil?
|
|
|
|
theme_ids = DB.query_single("SELECT id FROM themes WHERE NOT component")
|
|
|
|
theme_ids.each do |theme_id|
|
|
# ThemeSiteSetting has an identical schema to SiteSetting, so we can use the same values
|
|
# and data types.
|
|
DB.exec(
|
|
"INSERT INTO theme_site_settings (name, data_type, value, theme_id, created_at, updated_at)
|
|
VALUES (:setting, :data_type, :value, :theme_id, NOW(), NOW())
|
|
ON CONFLICT (name, theme_id) DO NOTHING",
|
|
setting:,
|
|
data_type: db_data_type,
|
|
value: db_value,
|
|
theme_id:,
|
|
)
|
|
end
|
|
end
|
|
end
|
|
|
|
def down
|
|
raise ActiveRecord::IrreversibleMigration
|
|
end
|
|
end
|
