2019-05-02 18:17:27 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2018-03-04 19:04:23 -05:00
|
|
|
class ThemeSettingsManager
|
|
|
|
attr_reader :name, :theme, :default
|
|
|
|
|
|
|
|
def self.types
|
|
|
|
ThemeSetting.types
|
|
|
|
end
|
|
|
|
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
def self.cast_row_value(row)
|
|
|
|
type_name = self.types.invert[row.data_type].downcase.capitalize
|
|
|
|
klass = "ThemeSettingsManager::#{type_name}".constantize
|
|
|
|
klass.cast(row.value)
|
|
|
|
end
|
|
|
|
|
2018-03-04 19:04:23 -05:00
|
|
|
def self.create(name, default, type, theme, opts = {})
|
|
|
|
type_name = self.types.invert[type].downcase.capitalize
|
|
|
|
klass = "ThemeSettingsManager::#{type_name}".constantize
|
|
|
|
klass.new(name, default, theme, opts)
|
|
|
|
end
|
|
|
|
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
def self.cast(value)
|
|
|
|
value
|
|
|
|
end
|
|
|
|
|
2018-03-04 19:04:23 -05:00
|
|
|
def initialize(name, default, theme, opts = {})
|
|
|
|
@name = name.to_sym
|
|
|
|
@default = default
|
|
|
|
@theme = theme
|
|
|
|
@opts = opts
|
|
|
|
@types = self.class.types
|
|
|
|
end
|
|
|
|
|
|
|
|
def value
|
2021-09-15 22:28:53 -04:00
|
|
|
has_record? ? db_record.value : default
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def type_name
|
|
|
|
self.class.name.demodulize.downcase.to_sym
|
|
|
|
end
|
|
|
|
|
|
|
|
def type
|
|
|
|
@types[type_name]
|
|
|
|
end
|
|
|
|
|
|
|
|
def description
|
2019-05-31 09:49:59 -04:00
|
|
|
@opts[:description] # Old method of specifying description. Is now overridden by locale file
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|
|
|
|
|
2021-11-22 07:16:56 -05:00
|
|
|
def requests_refresh?
|
|
|
|
@opts[:refresh]
|
|
|
|
end
|
|
|
|
|
2018-03-04 19:04:23 -05:00
|
|
|
def value=(new_value)
|
|
|
|
ensure_is_valid_value!(new_value)
|
|
|
|
|
|
|
|
record = has_record? ? db_record : create_record!
|
|
|
|
record.value = new_value.to_s
|
|
|
|
record.save!
|
|
|
|
record.value
|
|
|
|
end
|
|
|
|
|
|
|
|
def db_record
|
2018-12-20 12:13:05 -05:00
|
|
|
# theme.theme_settings will already be preloaded, so it is better to use
|
|
|
|
# `find` on an array, rather than make a round trip to the database
|
|
|
|
theme.theme_settings.to_a.find do |i|
|
|
|
|
i.name.to_s == @name.to_s && i.data_type.to_s == type.to_s
|
2023-01-09 07:10:19 -05:00
|
|
|
end
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def has_record?
|
|
|
|
db_record.present?
|
|
|
|
end
|
|
|
|
|
|
|
|
def create_record!
|
|
|
|
record = ThemeSetting.new(name: @name, data_type: type, theme: @theme)
|
|
|
|
record.save!
|
|
|
|
record
|
|
|
|
end
|
|
|
|
|
|
|
|
def is_valid_value?(new_value)
|
|
|
|
true
|
|
|
|
end
|
|
|
|
|
|
|
|
def invalid_value_error_message
|
|
|
|
name = type == @types[:integer] || type == @types[:float] ? "number" : type_name
|
|
|
|
primary_key = "themes.settings_errors.#{name}_value_not_valid"
|
|
|
|
|
|
|
|
secondary_key = primary_key
|
|
|
|
secondary_key += "_min" if has_min?
|
|
|
|
secondary_key += "_max" if has_max?
|
|
|
|
|
|
|
|
translation = I18n.t(primary_key)
|
|
|
|
return translation if secondary_key == primary_key
|
|
|
|
|
|
|
|
translation += " #{I18n.t(secondary_key, min: @opts[:min], max: @opts[:max])}"
|
|
|
|
translation
|
|
|
|
end
|
|
|
|
|
|
|
|
def ensure_is_valid_value!(new_value)
|
|
|
|
unless is_valid_value?(new_value)
|
|
|
|
raise Discourse::InvalidParameters.new invalid_value_error_message
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def has_min?
|
|
|
|
min = @opts[:min]
|
|
|
|
(min.is_a?(::Integer) || min.is_a?(::Float)) && min != -::Float::INFINITY
|
|
|
|
end
|
|
|
|
|
|
|
|
def has_max?
|
|
|
|
max = @opts[:max]
|
|
|
|
(max.is_a?(::Integer) || max.is_a?(::Float)) && max != ::Float::INFINITY
|
|
|
|
end
|
|
|
|
|
2018-08-03 16:41:37 -04:00
|
|
|
class List < self
|
|
|
|
def list_type
|
|
|
|
@opts[:list_type]
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
class String < self
|
2018-03-04 19:04:23 -05:00
|
|
|
def is_valid_value?(new_value)
|
|
|
|
(@opts[:min]..@opts[:max]).include? new_value.to_s.length
|
|
|
|
end
|
2019-02-05 09:14:53 -05:00
|
|
|
|
|
|
|
def textarea
|
|
|
|
@opts[:textarea]
|
|
|
|
end
|
2021-03-10 20:15:04 -05:00
|
|
|
|
|
|
|
def json_schema
|
2023-01-09 07:10:19 -05:00
|
|
|
begin
|
2021-03-10 20:15:04 -05:00
|
|
|
JSON.parse(@opts[:json_schema])
|
|
|
|
rescue StandardError
|
|
|
|
false
|
2023-01-09 07:10:19 -05:00
|
|
|
end
|
2021-03-10 20:15:04 -05:00
|
|
|
end
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
class Bool < self
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
def self.cast(value)
|
|
|
|
[true, "true"].include?(value)
|
|
|
|
end
|
|
|
|
|
2018-03-04 19:04:23 -05:00
|
|
|
def value
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
self.class.cast(super)
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def value=(new_value)
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
new_value = (self.class.cast(new_value)).to_s
|
2018-03-04 19:04:23 -05:00
|
|
|
super(new_value)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
class Integer < self
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
def self.cast(value)
|
|
|
|
value.to_i
|
|
|
|
end
|
|
|
|
|
2018-03-04 19:04:23 -05:00
|
|
|
def value
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
self.class.cast(super)
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def value=(new_value)
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
super(self.class.cast(new_value))
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def is_valid_value?(new_value)
|
|
|
|
(@opts[:min]..@opts[:max]).include? new_value.to_i
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
class Float < self
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
def self.cast(value)
|
|
|
|
value.to_f
|
|
|
|
end
|
|
|
|
|
2018-03-04 19:04:23 -05:00
|
|
|
def value
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
self.class.cast(super)
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def value=(new_value)
|
FEATURE: Theme settings migrations (#24071)
This commit introduces a new feature that allows theme developers to manage the transformation of theme settings over time. Similar to Rails migrations, the theme settings migration system enables developers to write and execute migrations for theme settings, ensuring a smooth transition when changes are required in the format or structure of setting values.
Example use cases for the theme settings migration system:
1. Renaming a theme setting.
2. Changing the data type of a theme setting (e.g., transforming a string setting containing comma-separated values into a proper list setting).
3. Altering the format of data stored in a theme setting.
All of these use cases and more are now possible while preserving theme setting values for sites that have already modified their theme settings.
Usage:
1. Create a top-level directory called `migrations` in your theme/component, and then within the `migrations` directory create another directory called `settings`.
2. Inside the `migrations/settings` directory, create a JavaScript file using the format `XXXX-some-name.js`, where `XXXX` is a unique 4-digit number, and `some-name` is a descriptor of your choice that describes the migration.
3. Within the JavaScript file, define and export (as the default) a function called `migrate`. This function will receive a `Map` object and must also return a `Map` object (it's acceptable to return the same `Map` object that the function received).
4. The `Map` object received by the `migrate` function will include settings that have been overridden or changed by site administrators. Settings that have never been changed from the default will not be included.
5. The keys and values contained in the `Map` object that the `migrate` function returns will replace all the currently changed settings of the theme.
6. Migrations are executed in numerical order based on the XXXX segment in the migration filenames. For instance, `0001-some-migration.js` will be executed before `0002-another-migration.js`.
Here's a complete example migration script that renames a setting from `setting_with_old_name` to `setting_with_new_name`:
```js
// File name: 0001-rename-setting.js
export default function migrate(settings) {
if (settings.has("setting_with_old_name")) {
settings.set("setting_with_new_name", settings.get("setting_with_old_name"));
}
return settings;
}
```
Internal topic: t/109980
2023-11-02 01:10:15 -04:00
|
|
|
super(self.class.cast(new_value))
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|
|
|
|
|
|
|
|
def is_valid_value?(new_value)
|
|
|
|
(@opts[:min]..@opts[:max]).include? new_value.to_f
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
class Enum < self
|
|
|
|
def value
|
|
|
|
val = super
|
|
|
|
match = choices.find { |choice| choice == val || choice.to_s == val }
|
|
|
|
match || val
|
|
|
|
end
|
|
|
|
|
|
|
|
def is_valid_value?(new_value)
|
|
|
|
choices.include?(new_value) || choices.map(&:to_s).include?(new_value)
|
|
|
|
end
|
|
|
|
|
|
|
|
def choices
|
|
|
|
@opts[:choices]
|
|
|
|
end
|
|
|
|
end
|
2020-04-15 09:04:02 -04:00
|
|
|
|
|
|
|
class Upload < self
|
2021-04-20 18:42:02 -04:00
|
|
|
def value
|
2023-03-06 03:41:47 -05:00
|
|
|
has_record? ? cdn_url(db_record.value) : default
|
2021-09-15 22:28:53 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
def default
|
|
|
|
upload_id = default_upload_id
|
|
|
|
return if upload_id.blank?
|
|
|
|
|
|
|
|
cdn_url(upload_id)
|
|
|
|
end
|
|
|
|
|
|
|
|
def value=(new_value)
|
|
|
|
if new_value.present?
|
|
|
|
if new_value == default
|
|
|
|
new_value = default_upload_id
|
|
|
|
else
|
|
|
|
upload = ::Upload.find_by(url: new_value)
|
|
|
|
new_value = upload.id if upload.present?
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
super(new_value)
|
|
|
|
end
|
|
|
|
|
|
|
|
private
|
|
|
|
|
|
|
|
def cdn_url(upload_id)
|
|
|
|
return if upload_id.blank?
|
|
|
|
|
|
|
|
upload = ::Upload.find_by_id(upload_id.to_i)
|
|
|
|
return if upload.blank?
|
|
|
|
|
|
|
|
Discourse.store.cdn_url(upload.url)
|
2021-04-20 18:42:02 -04:00
|
|
|
end
|
|
|
|
|
2021-09-15 22:28:53 -04:00
|
|
|
def default_upload_id
|
|
|
|
theme_field =
|
|
|
|
theme.theme_fields.find_by(name: @default, type_id: ThemeField.types[:theme_upload_var])
|
|
|
|
return if theme_field.blank?
|
|
|
|
|
|
|
|
theme_field.upload_id
|
|
|
|
end
|
2020-04-15 09:04:02 -04:00
|
|
|
end
|
2018-03-04 19:04:23 -05:00
|
|
|
end
|