2019-05-03 06:17:27 +08:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2017-04-12 22:52:52 +08:00
|
|
|
class RemoteTheme < ActiveRecord::Base
|
2019-01-25 22:19:01 +08:00
|
|
|
METADATA_PROPERTIES = %i[
|
|
|
|
license_url
|
|
|
|
about_url
|
|
|
|
authors
|
|
|
|
theme_version
|
|
|
|
minimum_discourse_version
|
|
|
|
maximum_discourse_version
|
2023-01-09 20:20:10 +08:00
|
|
|
]
|
|
|
|
|
2019-01-23 22:40:21 +08:00
|
|
|
class ImportError < StandardError
|
|
|
|
end
|
|
|
|
|
2023-02-07 00:10:50 +08:00
|
|
|
ALLOWED_FIELDS = %w[
|
|
|
|
scss
|
|
|
|
embedded_scss
|
|
|
|
embedded_header
|
|
|
|
head_tag
|
|
|
|
header
|
|
|
|
after_header
|
|
|
|
body_tag
|
|
|
|
footer
|
|
|
|
]
|
2017-05-03 04:01:01 +08:00
|
|
|
|
2023-01-21 02:52:49 +08:00
|
|
|
GITHUB_REGEXP = %r{\Ahttps?://github\.com/}
|
|
|
|
GITHUB_SSH_REGEXP = %r{\Assh://git@github\.com:}
|
2018-08-06 13:29:15 +08:00
|
|
|
|
2023-08-23 02:30:33 +08:00
|
|
|
MAX_METADATA_FILE_SIZE = Discourse::MAX_METADATA_FILE_SIZE
|
|
|
|
MAX_ASSET_FILE_SIZE = 8.megabytes
|
|
|
|
MAX_THEME_FILE_COUNT = 1024
|
|
|
|
MAX_THEME_SIZE = 256.megabytes
|
|
|
|
|
2019-08-29 22:47:08 +08:00
|
|
|
has_one :theme, autosave: false
|
2018-09-08 21:24:11 +08:00
|
|
|
scope :joined_remotes,
|
2023-11-29 13:38:07 +08:00
|
|
|
-> do
|
2018-09-08 21:24:11 +08:00
|
|
|
joins("JOIN themes ON themes.remote_theme_id = remote_themes.id").where.not(
|
|
|
|
remote_url: "",
|
|
|
|
)
|
2023-11-29 13:38:07 +08:00
|
|
|
end
|
2023-01-09 20:20:10 +08:00
|
|
|
|
2019-01-25 22:19:01 +08:00
|
|
|
validates_format_of :minimum_discourse_version,
|
|
|
|
:maximum_discourse_version,
|
|
|
|
with: Discourse::VERSION_REGEXP,
|
|
|
|
allow_nil: true
|
|
|
|
|
2019-01-23 22:40:21 +08:00
|
|
|
def self.extract_theme_info(importer)
|
2023-08-23 02:30:33 +08:00
|
|
|
if importer.file_size("about.json") > MAX_METADATA_FILE_SIZE
|
|
|
|
raise ImportError.new I18n.t(
|
|
|
|
"themes.import_error.about_json_too_big",
|
|
|
|
limit:
|
|
|
|
ActiveSupport::NumberHelper.number_to_human_size(
|
|
|
|
MAX_METADATA_FILE_SIZE,
|
|
|
|
),
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
|
|
|
begin
|
|
|
|
json = JSON.parse(importer["about.json"])
|
|
|
|
json.fetch("name")
|
|
|
|
json
|
|
|
|
rescue TypeError, JSON::ParserError, KeyError
|
|
|
|
raise ImportError.new I18n.t("themes.import_error.about_json")
|
|
|
|
end
|
2019-01-23 22:40:21 +08:00
|
|
|
end
|
|
|
|
|
2020-03-27 06:11:56 +08:00
|
|
|
def self.update_zipped_theme(
|
|
|
|
filename,
|
|
|
|
original_filename,
|
|
|
|
user: Discourse.system_user,
|
|
|
|
theme_id: nil,
|
2024-01-11 14:04:02 +08:00
|
|
|
update_components: nil,
|
|
|
|
run_migrations: true
|
2020-03-27 06:11:56 +08:00
|
|
|
)
|
2023-09-12 07:38:47 +08:00
|
|
|
update_theme(
|
|
|
|
ThemeStore::ZipImporter.new(filename, original_filename),
|
|
|
|
user:,
|
|
|
|
theme_id:,
|
|
|
|
update_components:,
|
2024-01-11 14:04:02 +08:00
|
|
|
run_migrations:,
|
2023-09-12 07:38:47 +08:00
|
|
|
)
|
|
|
|
end
|
|
|
|
|
2023-11-17 07:17:32 +08:00
|
|
|
# This is only used in the development and test environment and is currently not supported for other environments
|
|
|
|
if Rails.env.test? || Rails.env.development?
|
2023-09-12 07:38:47 +08:00
|
|
|
def self.import_theme_from_directory(directory)
|
2024-07-25 22:10:51 +08:00
|
|
|
update_theme(ThemeStore::DirectoryImporter.new(directory), update_components: "none")
|
2023-09-12 07:38:47 +08:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def self.update_theme(
|
|
|
|
importer,
|
|
|
|
user: Discourse.system_user,
|
|
|
|
theme_id: nil,
|
2024-01-11 14:04:02 +08:00
|
|
|
update_components: nil,
|
|
|
|
run_migrations: true
|
2023-09-12 07:38:47 +08:00
|
|
|
)
|
2018-03-12 15:36:06 +08:00
|
|
|
importer.import!
|
|
|
|
|
2019-01-23 22:40:21 +08:00
|
|
|
theme_info = RemoteTheme.extract_theme_info(importer)
|
2019-01-30 22:17:04 +08:00
|
|
|
theme = Theme.find_by(id: theme_id) if theme_id # New theme CLI method
|
2020-03-27 06:11:56 +08:00
|
|
|
|
|
|
|
existing = true
|
|
|
|
if theme.blank?
|
2021-12-02 00:58:13 +08:00
|
|
|
theme = Theme.new(user_id: user&.id || -1, name: theme_info["name"], auto_update: false)
|
2020-03-27 06:11:56 +08:00
|
|
|
existing = false
|
|
|
|
end
|
2018-03-12 15:36:06 +08:00
|
|
|
|
2019-01-23 22:40:21 +08:00
|
|
|
theme.component = theme_info["component"].to_s == "true"
|
2020-03-27 06:11:56 +08:00
|
|
|
theme.child_components = child_components = theme_info["components"].presence || []
|
2024-07-25 22:10:51 +08:00
|
|
|
theme.skip_child_components_update = true if update_components == "none"
|
2019-01-23 22:40:21 +08:00
|
|
|
|
2018-03-12 15:36:06 +08:00
|
|
|
remote_theme = new
|
|
|
|
remote_theme.theme = theme
|
|
|
|
remote_theme.remote_url = ""
|
|
|
|
|
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 13:10:15 +08:00
|
|
|
do_update_child_components = false
|
2024-01-11 14:04:02 +08:00
|
|
|
|
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 13:10:15 +08:00
|
|
|
theme.transaction do
|
2024-01-11 14:04:02 +08:00
|
|
|
remote_theme.update_from_remote(
|
|
|
|
importer,
|
|
|
|
skip_update: true,
|
|
|
|
already_in_transaction: true,
|
|
|
|
run_migrations:,
|
|
|
|
)
|
2020-03-27 06:11:56 +08:00
|
|
|
|
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 13:10:15 +08:00
|
|
|
if existing && update_components.present? && update_components != "none"
|
|
|
|
child_components = child_components.map { |url| ThemeStore::GitImporter.new(url.strip).url }
|
2020-03-27 06:11:56 +08:00
|
|
|
|
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 13:10:15 +08:00
|
|
|
if update_components == "sync"
|
|
|
|
ChildTheme
|
|
|
|
.joins(child_theme: :remote_theme)
|
|
|
|
.where("remote_themes.remote_url NOT IN (?)", child_components)
|
|
|
|
.delete_all
|
|
|
|
end
|
2020-03-27 06:11:56 +08:00
|
|
|
|
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 13:10:15 +08:00
|
|
|
child_components -=
|
|
|
|
theme
|
|
|
|
.child_themes
|
|
|
|
.joins(:remote_theme)
|
|
|
|
.where("remote_themes.remote_url IN (?)", child_components)
|
|
|
|
.pluck("remote_themes.remote_url")
|
|
|
|
theme.child_components = child_components
|
|
|
|
do_update_child_components = true
|
|
|
|
end
|
2020-03-27 06:11:56 +08:00
|
|
|
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 13:10:15 +08:00
|
|
|
theme.update_child_components if do_update_child_components
|
2018-03-12 15:36:06 +08:00
|
|
|
theme
|
|
|
|
ensure
|
|
|
|
begin
|
|
|
|
importer.cleanup!
|
|
|
|
rescue => e
|
|
|
|
Rails.logger.warn("Failed cleanup remote path #{e}")
|
|
|
|
end
|
|
|
|
end
|
2023-09-12 07:38:47 +08:00
|
|
|
private_class_method :update_theme
|
2018-03-12 15:36:06 +08:00
|
|
|
|
2018-10-09 14:01:08 +08:00
|
|
|
def self.import_theme(url, user = Discourse.system_user, private_key: nil, branch: nil)
|
2018-12-17 22:27:49 +08:00
|
|
|
importer = ThemeStore::GitImporter.new(url.strip, private_key: private_key, branch: branch)
|
2017-04-12 22:52:52 +08:00
|
|
|
importer.import!
|
|
|
|
|
2019-01-23 22:40:21 +08:00
|
|
|
theme_info = RemoteTheme.extract_theme_info(importer)
|
2022-11-02 00:33:17 +08:00
|
|
|
|
2018-08-24 09:30:00 +08:00
|
|
|
component = [true, "true"].include?(theme_info["component"])
|
|
|
|
theme = Theme.new(user_id: user&.id || -1, name: theme_info["name"], component: component)
|
2020-03-05 20:58:18 +08:00
|
|
|
theme.child_components = theme_info["components"].presence || []
|
2017-04-12 22:52:52 +08:00
|
|
|
|
|
|
|
remote_theme = new
|
|
|
|
theme.remote_theme = remote_theme
|
|
|
|
|
2018-03-09 13:14:21 +08:00
|
|
|
remote_theme.private_key = private_key
|
2018-10-09 14:01:08 +08:00
|
|
|
remote_theme.branch = branch
|
2017-04-12 22:52:52 +08:00
|
|
|
remote_theme.remote_url = importer.url
|
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 13:10:15 +08:00
|
|
|
|
2017-04-12 22:52:52 +08:00
|
|
|
remote_theme.update_from_remote(importer)
|
|
|
|
|
|
|
|
theme
|
|
|
|
ensure
|
|
|
|
begin
|
|
|
|
importer.cleanup!
|
|
|
|
rescue => e
|
|
|
|
Rails.logger.warn("Failed cleanup remote git #{e}")
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-08-03 07:53:48 +08:00
|
|
|
def self.out_of_date_themes
|
2018-09-08 21:24:11 +08:00
|
|
|
self
|
|
|
|
.joined_remotes
|
|
|
|
.where("commits_behind > 0 OR remote_version <> local_version")
|
2020-10-09 01:48:16 +08:00
|
|
|
.where(themes: { enabled: true })
|
2018-08-03 07:53:48 +08:00
|
|
|
.pluck("themes.name", "themes.id")
|
|
|
|
end
|
|
|
|
|
2018-09-08 21:24:11 +08:00
|
|
|
def self.unreachable_themes
|
|
|
|
self.joined_remotes.where("last_error_text IS NOT NULL").pluck("themes.name", "themes.id")
|
|
|
|
end
|
|
|
|
|
2022-01-22 02:23:26 +08:00
|
|
|
def out_of_date?
|
|
|
|
commits_behind > 0 || remote_version != local_version
|
|
|
|
end
|
|
|
|
|
2017-04-12 22:52:52 +08:00
|
|
|
def update_remote_version
|
2019-01-23 22:40:21 +08:00
|
|
|
return unless is_git?
|
2018-10-09 14:01:08 +08:00
|
|
|
importer = ThemeStore::GitImporter.new(remote_url, private_key: private_key, branch: branch)
|
2018-09-08 21:24:11 +08:00
|
|
|
begin
|
|
|
|
importer.import!
|
2019-01-23 22:40:21 +08:00
|
|
|
rescue RemoteTheme::ImportError => err
|
2018-09-08 21:24:11 +08:00
|
|
|
self.last_error_text = err.message
|
|
|
|
else
|
|
|
|
self.updated_at = Time.zone.now
|
|
|
|
self.remote_version, self.commits_behind = importer.commits_since(local_version)
|
2018-09-10 23:17:56 +08:00
|
|
|
self.last_error_text = nil
|
2019-08-30 05:32:54 +08:00
|
|
|
ensure
|
|
|
|
self.save!
|
2021-04-29 08:07:27 +08:00
|
|
|
begin
|
|
|
|
importer.cleanup!
|
|
|
|
rescue => e
|
|
|
|
Rails.logger.warn("Failed cleanup remote git #{e}")
|
|
|
|
end
|
2018-09-08 21:24:11 +08:00
|
|
|
end
|
2017-04-12 22:52:52 +08:00
|
|
|
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 13:10:15 +08:00
|
|
|
def update_from_remote(
|
|
|
|
importer = nil,
|
|
|
|
skip_update: false,
|
|
|
|
raise_if_theme_save_fails: true,
|
2024-01-11 14:04:02 +08:00
|
|
|
already_in_transaction: false,
|
|
|
|
run_migrations: true
|
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 13:10:15 +08:00
|
|
|
)
|
2017-04-12 22:52:52 +08:00
|
|
|
cleanup = false
|
2017-04-18 03:56:13 +08:00
|
|
|
|
2017-04-12 22:52:52 +08:00
|
|
|
unless importer
|
|
|
|
cleanup = true
|
2018-10-09 14:01:08 +08:00
|
|
|
importer = ThemeStore::GitImporter.new(remote_url, private_key: private_key, branch: branch)
|
2018-09-08 21:24:11 +08:00
|
|
|
begin
|
|
|
|
importer.import!
|
2019-01-23 22:40:21 +08:00
|
|
|
rescue RemoteTheme::ImportError => err
|
2018-09-08 21:24:11 +08:00
|
|
|
self.last_error_text = err.message
|
2019-08-30 05:32:54 +08:00
|
|
|
self.save!
|
2018-09-08 21:24:11 +08:00
|
|
|
return self
|
2018-09-10 23:17:56 +08:00
|
|
|
else
|
|
|
|
self.last_error_text = nil
|
2018-09-08 21:24:11 +08:00
|
|
|
end
|
2017-04-12 22:52:52 +08:00
|
|
|
end
|
|
|
|
|
2019-01-23 22:40:21 +08:00
|
|
|
theme_info = RemoteTheme.extract_theme_info(importer)
|
2019-04-12 18:36:08 +08:00
|
|
|
updated_fields = []
|
2017-05-10 05:20:28 +08:00
|
|
|
|
|
|
|
theme_info["assets"]&.each do |name, relative_path|
|
|
|
|
if path = importer.real_path(relative_path)
|
2019-01-18 23:20:11 +08:00
|
|
|
new_path = "#{File.dirname(path)}/#{SecureRandom.hex}#{File.extname(path)}"
|
|
|
|
File.rename(path, new_path) # OptimizedImage has strict file name restrictions, so rename temporarily
|
|
|
|
upload =
|
|
|
|
UploadCreator.new(
|
|
|
|
File.open(new_path),
|
|
|
|
File.basename(relative_path),
|
|
|
|
for_theme: true,
|
|
|
|
).create_for(theme.user_id)
|
2022-04-01 09:03:14 +08:00
|
|
|
|
|
|
|
if !upload.errors.empty?
|
|
|
|
raise ImportError,
|
|
|
|
I18n.t(
|
|
|
|
"themes.import_error.upload",
|
|
|
|
name: name,
|
|
|
|
errors: upload.errors.full_messages.join(","),
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
2019-04-12 18:36:08 +08:00
|
|
|
updated_fields << theme.set_field(
|
|
|
|
target: :common,
|
|
|
|
name: name,
|
|
|
|
type: :theme_upload_var,
|
|
|
|
upload_id: upload.id,
|
|
|
|
)
|
2017-05-10 05:20:28 +08:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-08-10 18:30:18 +08:00
|
|
|
# Update all theme attributes if this is just a placeholder
|
|
|
|
if self.remote_url.present? && !self.local_version && !self.commits_behind
|
|
|
|
self.theme.name = theme_info["name"]
|
|
|
|
self.theme.component = [true, "true"].include?(theme_info["component"])
|
|
|
|
self.theme.child_components = theme_info["components"].presence || []
|
|
|
|
end
|
|
|
|
|
2019-01-25 22:19:01 +08:00
|
|
|
METADATA_PROPERTIES.each do |property|
|
|
|
|
self.public_send(:"#{property}=", theme_info[property.to_s])
|
|
|
|
end
|
2023-09-12 07:38:47 +08:00
|
|
|
|
2019-01-25 22:19:01 +08:00
|
|
|
if !self.valid?
|
|
|
|
raise ImportError,
|
|
|
|
I18n.t(
|
|
|
|
"themes.import_error.about_json_values",
|
|
|
|
errors: self.errors.full_messages.join(","),
|
|
|
|
)
|
|
|
|
end
|
2018-03-12 15:36:06 +08:00
|
|
|
|
2020-03-13 00:35:28 +08:00
|
|
|
ThemeModifierSet.modifiers.keys.each do |modifier_name|
|
2020-03-11 21:30:45 +08:00
|
|
|
theme.theme_modifier_set.public_send(
|
|
|
|
:"#{modifier_name}=",
|
|
|
|
theme_info.dig("modifiers", modifier_name.to_s),
|
|
|
|
)
|
|
|
|
end
|
2023-09-12 07:38:47 +08:00
|
|
|
|
2020-03-11 21:30:45 +08:00
|
|
|
if !theme.theme_modifier_set.valid?
|
|
|
|
raise ImportError,
|
|
|
|
I18n.t(
|
|
|
|
"themes.import_error.modifier_values",
|
|
|
|
errors: theme.theme_modifier_set.errors.full_messages.join(","),
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
2023-08-23 02:30:33 +08:00
|
|
|
all_files = importer.all_files
|
|
|
|
|
|
|
|
if all_files.size > MAX_THEME_FILE_COUNT
|
|
|
|
raise ImportError,
|
|
|
|
I18n.t(
|
|
|
|
"themes.import_error.too_many_files",
|
|
|
|
count: all_files.size,
|
|
|
|
limit: MAX_THEME_FILE_COUNT,
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
|
|
|
theme_size = 0
|
|
|
|
|
|
|
|
all_files.each do |filename|
|
2019-01-23 22:40:21 +08:00
|
|
|
next unless opts = ThemeField.opts_from_file_path(filename)
|
2023-08-23 02:30:33 +08:00
|
|
|
|
|
|
|
file_size = importer.file_size(filename)
|
|
|
|
|
|
|
|
if file_size > MAX_ASSET_FILE_SIZE
|
|
|
|
raise ImportError,
|
|
|
|
I18n.t(
|
|
|
|
"themes.import_error.asset_too_big",
|
|
|
|
filename: filename,
|
|
|
|
limit: ActiveSupport::NumberHelper.number_to_human_size(MAX_ASSET_FILE_SIZE),
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
|
|
|
theme_size += file_size
|
|
|
|
|
|
|
|
if theme_size > MAX_THEME_SIZE
|
|
|
|
raise ImportError,
|
|
|
|
I18n.t(
|
|
|
|
"themes.import_error.theme_too_big",
|
|
|
|
limit: ActiveSupport::NumberHelper.number_to_human_size(MAX_THEME_SIZE),
|
|
|
|
)
|
|
|
|
end
|
|
|
|
|
2019-01-23 22:40:21 +08:00
|
|
|
value = importer[filename]
|
2019-11-28 10:13:13 +08:00
|
|
|
updated_fields << theme.set_field(**opts.merge(value: value))
|
2019-01-23 22:40:21 +08:00
|
|
|
end
|
|
|
|
|
2018-03-12 15:36:06 +08:00
|
|
|
if !skip_update
|
|
|
|
self.remote_updated_at = Time.zone.now
|
|
|
|
self.remote_version = importer.version
|
|
|
|
self.local_version = importer.version
|
|
|
|
self.commits_behind = 0
|
|
|
|
end
|
2017-04-12 22:52:52 +08:00
|
|
|
|
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 13:10:15 +08:00
|
|
|
transaction_block = -> do
|
|
|
|
# Destroy fields that no longer exist in the remote theme
|
|
|
|
field_ids_to_destroy = theme.theme_fields.pluck(:id) - updated_fields.map { |tf| tf&.id }
|
|
|
|
ThemeField.where(id: field_ids_to_destroy).destroy_all
|
|
|
|
|
|
|
|
update_theme_color_schemes(theme, theme_info["color_schemes"]) unless theme.component
|
|
|
|
|
|
|
|
self.save!
|
2024-01-11 14:04:02 +08:00
|
|
|
|
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 13:10:15 +08:00
|
|
|
if raise_if_theme_save_fails
|
|
|
|
theme.save!
|
|
|
|
else
|
|
|
|
raise ActiveRecord::Rollback if !theme.save
|
|
|
|
end
|
2024-01-11 14:04:02 +08:00
|
|
|
|
|
|
|
theme.migrate_settings(start_transaction: false) if run_migrations
|
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 13:10:15 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
if already_in_transaction
|
|
|
|
transaction_block.call
|
|
|
|
else
|
|
|
|
self.transaction(&transaction_block)
|
|
|
|
end
|
2017-04-18 03:56:13 +08:00
|
|
|
|
2017-04-12 22:52:52 +08:00
|
|
|
self
|
|
|
|
ensure
|
|
|
|
begin
|
|
|
|
importer.cleanup! if cleanup
|
|
|
|
rescue => e
|
|
|
|
Rails.logger.warn("Failed cleanup remote git #{e}")
|
|
|
|
end
|
|
|
|
end
|
2017-04-18 03:56:13 +08:00
|
|
|
|
|
|
|
def normalize_override(hex)
|
|
|
|
return unless hex
|
|
|
|
|
|
|
|
override = hex.downcase
|
2017-04-18 04:57:37 +08:00
|
|
|
override = nil if override !~ /\A[0-9a-f]{6}\z/
|
2017-04-18 03:56:13 +08:00
|
|
|
override
|
|
|
|
end
|
|
|
|
|
|
|
|
def update_theme_color_schemes(theme, schemes)
|
2018-03-15 15:26:54 +08:00
|
|
|
missing_scheme_names = Hash[*theme.color_schemes.pluck(:name, :id).flatten]
|
2019-02-01 01:45:11 +08:00
|
|
|
ordered_schemes = []
|
2017-04-18 03:56:13 +08:00
|
|
|
|
2018-03-16 08:19:06 +08:00
|
|
|
schemes&.each do |name, colors|
|
2018-03-15 15:26:54 +08:00
|
|
|
missing_scheme_names.delete(name)
|
2019-08-12 18:02:38 +08:00
|
|
|
scheme = theme.color_schemes.find_by(name: name) || theme.color_schemes.build(name: name)
|
|
|
|
|
|
|
|
# Update main colors
|
|
|
|
ColorScheme.base.colors_hashes.each do |color|
|
|
|
|
override = normalize_override(colors[color[:name]])
|
|
|
|
color_scheme_color =
|
|
|
|
scheme.color_scheme_colors.to_a.find { |c| c.name == color[:name] } ||
|
|
|
|
scheme.color_scheme_colors.build(name: color[:name])
|
|
|
|
color_scheme_color.hex = override || color[:hex]
|
2019-08-29 22:47:08 +08:00
|
|
|
theme.notify_color_change(color_scheme_color) if color_scheme_color.hex_changed?
|
2019-08-12 18:02:38 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
# Update advanced colors
|
|
|
|
ColorScheme.color_transformation_variables.each do |variable_name|
|
|
|
|
override = normalize_override(colors[variable_name])
|
|
|
|
color_scheme_color = scheme.color_scheme_colors.to_a.find { |c| c.name == variable_name }
|
|
|
|
if override
|
|
|
|
color_scheme_color ||= scheme.color_scheme_colors.build(name: variable_name)
|
|
|
|
color_scheme_color.hex = override
|
2019-08-29 22:47:08 +08:00
|
|
|
theme.notify_color_change(color_scheme_color) if color_scheme_color.hex_changed?
|
2019-08-12 18:02:38 +08:00
|
|
|
elsif color_scheme_color # No longer specified in about.json, delete record
|
|
|
|
scheme.color_scheme_colors.delete(color_scheme_color)
|
|
|
|
theme.notify_color_change(nil, scheme: scheme)
|
2017-04-18 03:56:13 +08:00
|
|
|
end
|
|
|
|
end
|
2019-08-12 18:02:38 +08:00
|
|
|
|
|
|
|
ordered_schemes << scheme
|
2017-04-18 03:56:13 +08:00
|
|
|
end
|
2018-03-15 15:26:54 +08:00
|
|
|
|
|
|
|
if missing_scheme_names.length > 0
|
|
|
|
ColorScheme.where(id: missing_scheme_names.values).delete_all
|
|
|
|
# we may have stuff pointed at the incorrect scheme?
|
|
|
|
end
|
2019-02-01 01:45:11 +08:00
|
|
|
|
|
|
|
theme.color_scheme = ordered_schemes.first if theme.new_record?
|
2017-04-18 03:56:13 +08:00
|
|
|
end
|
2018-03-15 15:26:54 +08:00
|
|
|
|
2018-08-06 13:29:15 +08:00
|
|
|
def github_diff_link
|
|
|
|
if github_repo_url.present? && local_version != remote_version
|
2023-01-21 02:52:49 +08:00
|
|
|
"#{github_repo_url.gsub(/\.git\z/, "")}/compare/#{local_version}...#{remote_version}"
|
2018-08-06 13:29:15 +08:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def github_repo_url
|
|
|
|
url = remote_url.strip
|
|
|
|
return url if url.match?(GITHUB_REGEXP)
|
|
|
|
|
|
|
|
if url.match?(GITHUB_SSH_REGEXP)
|
|
|
|
org_repo = url.gsub(GITHUB_SSH_REGEXP, "")
|
|
|
|
"https://github.com/#{org_repo}"
|
|
|
|
end
|
|
|
|
end
|
2019-01-23 22:40:21 +08:00
|
|
|
|
|
|
|
def is_git?
|
|
|
|
remote_url.present?
|
|
|
|
end
|
2017-04-12 22:52:52 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
# == Schema Information
|
|
|
|
#
|
|
|
|
# Table name: remote_themes
|
|
|
|
#
|
2019-01-30 09:34:51 +08:00
|
|
|
# id :integer not null, primary key
|
|
|
|
# remote_url :string not null
|
|
|
|
# remote_version :string
|
|
|
|
# local_version :string
|
|
|
|
# about_url :string
|
|
|
|
# license_url :string
|
|
|
|
# commits_behind :integer
|
|
|
|
# remote_updated_at :datetime
|
|
|
|
# created_at :datetime not null
|
|
|
|
# updated_at :datetime not null
|
|
|
|
# private_key :text
|
|
|
|
# branch :string
|
|
|
|
# last_error_text :text
|
|
|
|
# authors :string
|
|
|
|
# theme_version :string
|
|
|
|
# minimum_discourse_version :string
|
|
|
|
# maximum_discourse_version :string
|
2017-04-12 22:52:52 +08:00
|
|
|
#
|