Commit Graph

71 Commits

Author SHA1 Message Date
Jarek Radosz d91d67a442
FEATURE: Allow theme settings to request refresh (#15037)
Similar to site settings, adds support for `refresh` option to theme settings.

```yaml
super_feature_enabled:
  type: bool
  default: false
  refresh: true
```
2021-11-22 13:16:56 +01:00
Vinoth Kannan a6de4a5ce9
DEV: use upload id to save in theme setting instead of URL. (#14341)
When we use URL instead it creates the problem while changing the CDN hostname.
2021-09-16 07:58:53 +05:30
Penar Musaraj c8f4f7c235
FIX: Ignore missing uploads in theme settings (#13486)
In some rare cases, this could prevent the site from bootstrapping,
because theme settings are invoked early in the application.
2021-06-22 22:34:22 -04:00
Alan Guo Xiang Tan 8e3691d537 PERF: Eager load Theme associations in Stylesheet Manager.
Before this change, calling `StyleSheet::Manager.stylesheet_details`
for the first time resulted in multiple queries to the database. This is
because the code was modelled in a way where each `Theme` was loaded
from the database one at a time.

This PR restructures the code such that it allows us to load all the
theme records in a single query. It also allows us to eager load the
required associations upfront. In order to achieve this, I removed the
support of loading multiple themes per request. It was initially added
to support user selectable theme components but the feature was never
completed and abandoned because it wasn't a feature that we thought was
worth building.
2021-06-21 11:06:58 +08:00
Martin Brennan 6fe78cd542
FIX: Make sure reset-new for tracked is not limited by per_page count (#13395)
When dismissing new topics for the Tracked filter, the dismiss was
limited to 30 topics which is the default per page count for TopicQuery.
This happened even if you specified which topic IDs you were
selectively dismissing. This PR fixes that bug, and also moves
the per_page_count into a DEFAULT_PER_PAGE_COUNT for the TopicQuery
so it can be stubbed in tests.

Also moves the unused stub_const method into the spec helpers
for cases like this; it is much better to handle this in one place
with an ensure. In a follow up PR I will clean up other specs that
do the same thing and make them use stub_const.
2021-06-17 08:20:09 +10:00
Jarek Radosz e36377d9ab
DEV: Don't user before(:all)/after(:all) (#13389)
Leaking state and non-obvious order (before :all runs *before* RailsHelper.test_setup) are not worth it.
A replacement PR for #13370. Fixes some flaky specs, e.g.
```
bin/rspec './spec/components/freedom_patches/translate_accelerator_spec.rb[1:3]' './spec/jobs/clean_up_user_export_topics_spec.rb[1:1]' --tag ~type:multisite --seed 35994
```

Also included:
* DEV: No need for locale reset (we do it anyway in rails_helper in `test_setup`)
2021-06-15 17:25:06 +02:00
Osama Sayegh 4f88f2eb15
FEATURE: Allow theme tests to be run in production (take 2) (#12845)
This commit allows site admins to run theme tests in production via a new `/theme-qunit` route. When you visit `/theme-qunit`, you'll see a list of the themes/components installed on your site that have tests, and from there you can select a theme or component that you run its tests.

We also have a new rake task `themes:install_and_test` that can be used to install a list of themes/components on a temporary database and run the tests of the themes/components that are installed. This rake task can be useful when upgrading/deploying a Discourse instance to make sure that the installed themes/components are compatible with the new Discourse version being deployed, and if the tests fail you can abort the build/deploy process so you don't end up with a broken site.
2021-04-28 23:12:08 +03:00
Osama Sayegh a169dc6832
Revert "FEATURE: Allow theme tests to be run in production (#12815)" (#12840)
This reverts commit 7217dcb67a.

https://meta.discourse.org/t/failed-to-bootstrap-due-to-out-of-memory-killer/188141/18?u=osama

Precompiling test_helper.js is so expensive that it can make bootstrap
fail on servers with limited resources (2GB RAM). We will find another
way that doesn't require much resources.
2021-04-26 23:05:58 +03:00
Osama Sayegh 7217dcb67a
FEATURE: Allow theme tests to be run in production (#12815)
This commit allows site admins to run theme tests in production via a new `/theme-qunit` route. When you visit `/theme-qunit`, you'll see a list of the themes/components installed on your site that have tests, and from there you can select a theme or component that you run its tests.

We also have a new rake task `themes:install_and_test` that can be used to install a list of themes/components on a temporary database and run the tests of the themes/components that are installed. This rake task can be useful when upgrading/deploying a Discourse instance to make sure that the installed themes/components are compatible with the new Discourse version being deployed, and if the tests fail you can abort the build/deploy process so you don't end up with a broken site.
2021-04-26 12:56:45 +03:00
Penar Musaraj c47e6a2004
FIX: Use CDN urls for theme settings of type upload (#12773) 2021-04-20 18:42:02 -04:00
Penar Musaraj d44deb45f3
FIX: Use CDN urls for theme uploads (#12769) 2021-04-20 13:25:35 -04:00
Osama Sayegh cd24eff5d9
FEATURE: Introduce theme/component QUnit tests (take 2) (#12661)
This commit allows themes and theme components to have QUnit tests. To add tests to your theme/component, create a top-level directory in your theme and name it `test`, and Discourse will save all the files in that directory (and its sub-directories) as "tests files" in the database. While tests files/directories are not required to be organized in a specific way, we recommend that you follow Discourse core's tests [structure](https://github.com/discourse/discourse/tree/master/app/assets/javascripts/discourse/tests).

Writing theme tests should be identical to writing plugins or core tests; all the `import` statements and APIs that you see in core (or plugins) to define/setup tests should just work in themes.

You do need a working Discourse install to run theme tests, and you have 2 ways to run theme tests:

* In the browser at the `/qunit` route. `/qunit` will run tests of all active themes/components as well as core and plugins. The `/qunit` now accepts a `theme_name` or `theme_url` params that you can use to run tests of a specific theme/component like so: `/qunit?theme_name=<your_theme_name>`.

* In the command line using the `themes:qunit` rake task. This take is meant to run tests of a single theme/component so you need to provide it with a theme name or URL like so: `bundle exec rake themes:qunit[name=<theme_name>]` or `bundle exec rake themes:qunit[url=<theme_url>]`.

There are some refactors to how Discourse processes JavaScript that comes with themes/components, and these refactors may break your JS customizations; see https://meta.discourse.org/t/upcoming-core-changes-that-may-break-some-themes-components-april-12/186252?u=osama for details on how you can check if your themes/components are affected and what you need to do to fix them.

This commit also improves theme error handling in Discourse. We will now be able to catch errors that occur when theme initializers are run and prevent them from breaking the site and other themes/components.
2021-04-12 15:02:58 +03:00
Osama Sayegh 2b9ab3a0d9
Revert "FEATURE: Introduce theme/component QUnit tests (#12517)" (#12632)
This reverts commit a53d8d3e61 and 105634435f.

Reverted because the change broke some components. Will be added back in a few days.
2021-04-07 17:45:49 +03:00
Osama Sayegh a53d8d3e61
FEATURE: Introduce theme/component QUnit tests (#12517)
This commit allows themes and theme components to have QUnit tests. To add tests to your theme/component, create a top-level directory in your theme and name it `test`, and Discourse will save all the files in that directory (and its sub-directories) as "tests files" in the database. While tests files/directories are not required to be organized in a specific way, we recommend that you follow Discourse core's tests [structure](https://github.com/discourse/discourse/tree/master/app/assets/javascripts/discourse/tests).

Writing theme tests should be identical to writing plugins or core tests; all the `import` statements and APIs that you see in core (or plugins) to define/setup tests should just work in themes.

You do need a working Discourse install to run theme tests, and you have 2 ways to run theme tests:

* In the browser at the `/qunit` route. `/qunit` will run tests of all active themes/components as well as core and plugins. The `/qunit` now accepts a `theme_name` or `theme_url` params that you can use to run tests of a specific theme/component like so: `/qunit?theme_name=<your_theme_name>`.

* In the command line using the `themes:qunit` rake task. This take is meant to run tests of a single theme/component so you need to provide it with a theme name or URL like so: `bundle exec rake themes:qunit[name=<theme_name>]` or `bundle exec rake themes:qunit[url=<theme_url>]`.

There are some refactors to internal code that's responsible for processing themes/components in Discourse, most notably:

* `<script type="text/discourse-plugin">` tags are automatically converted to modules.

* The `theme-settings` service is removed in favor of a simple `lib` file responsible for managing theme settings. This was done to allow us to register/lookup theme settings very early in our Ember app lifecycle and because there was no reason for it to be an Ember service.

These refactors should 100% backward compatible and invisible to theme developers.
2021-04-07 10:39:57 +03:00
Jarek Radosz 303d2227cc
DEV: Fix `FakeLogger` spec issues (#12397)
* DEV: Add `#level` and `#level=` to `FakeLogger`

* DEV: Fix a leaky test
2021-03-15 15:36:10 +11:00
Penar Musaraj 10780d2448
DEV: support json_schema in theme settings (#12294) 2021-03-10 20:15:04 -05:00
Penar Musaraj aa1442fdc3
DEV: Use separate files for theme component stylesheets (take 2) (#12225)
This switches to outputting a separate file for each theme component CSS
asset. We have separate CSS plugin files, separate JS files
(for plugins/themes/components), it makes sense to do the same for
component CSS assets.

Benefits:
- easier debugging
- fixes a regression with theme component sourcemaps
- changes to theme components are updated individually

With HTTP/2, there is also no performance downside to having additional
files in the initial request.
2021-02-26 12:30:23 -05:00
Penar Musaraj e74bdfdf8e
Revert "DEV: Use separate files for theme component stylesheets (#12214)" (#12224)
This reverts commit f57a49c2f9.

This had some unexpected side effects, needs some more work.
2021-02-26 08:20:39 -05:00
Penar Musaraj f57a49c2f9
DEV: Use separate files for theme component stylesheets (#12214)
This switches to outputting a separate file for each theme component CSS
asset. We have separate CSS plugin files, separate JS files
(for plugins/themes/components), it makes sense to do the same for
component CSS assets.

Benefits:
- easier debugging
- fixes a regression with theme component sourcemaps
- changes to theme components are updated individually

With HTTP/2, there is also no performance downside to having additional
files in the initial request.
2021-02-26 07:44:15 -05:00
Penar Musaraj 12ffba771c
FIX: Improve SCSS handling in components (#11963)
- ignores errors when including component SCSS in parent theme
- adds support for SCSS `@import`s in components' `color_definitions.scss` files
2021-02-04 08:51:18 -05:00
Penar Musaraj 2309032e68
FIX: Include extra SCSS in child theme (#11952) 2021-02-03 11:02:53 -05:00
Penar Musaraj e8b82724fd
DEV: Refactor theme SCSS compilation (#11919) 2021-02-02 13:09:41 -05:00
Joffrey JAFFEUX bbddce4d3a
DEV: updates js transpiler to use babel 7 (#10627)
Updates our js transpiler code to use Babel 7.11.6

List of changes in this commit:

- Updates plugins, babel plugins all have a new version which doesn't contain -es2015- anymore
- Drops [transform-es2015-classes](https://babeljs.io/docs/en/babel-plugin-transform-classes) this plugin shouldn't be needed now that we don't support IE
- Drops check-es2015-constants, checking constants is now part of babel and the check-constants plugin is deprecated. As a result the behavior slightly changed, and is now wrapping every const call in a readOnlyError function which would throw if assigned a new value. This explains the modified spec.
- Adds [proposal-optional-chaining](https://babeljs.io/docs/en/babel-plugin-proposal-optional-chaining)

```javascript
const obj = {
  foo: {
    bar: {
      baz: 42,
    },
  },
};

const baz = obj?.foo?.bar?.baz; // 42
```

- Adds [proposal-json-strings](https://babeljs.io/docs/en/babel-plugin-proposal-json-strings)

```javascript
// IN
const ex = "before
after";
//                ^ There's a U+2028 char between 'before' and 'after'


// OUT
const ex = "before\u2028after";
//                ^ There's a U+2028 char between 'before' and 'after'
```

- Adds [proposal-nullish-coalescing-operator](https://babeljs.io/docs/en/babel-plugin-proposal-nullish-coalescing-operator)

```javascript
var object = {};
var foo = object.foo ?? "default"; // default
```

- Adds [proposal-logical-assignment-operators](https://babeljs.io/docs/en/babel-plugin-proposal-logical-assignment-operators)

```javascript
let a;
let b = 2;
a ||= b; // 2
```

- Adds [proposal-numeric-separator](https://babeljs.io/docs/en/babel-plugin-proposal-numeric-separator)

```javascript
let budget = 1_000_000_000_000;
console.log(budget === 10 ** 12); // true
```

- Adds proposal-object-rest-spread https://babeljs.io/docs/en/babel-plugin-proposal-object-rest-spread

```javascript
let { x, y, ...z } = { x: 1, y: 2, a: 3, b: 4 };
console.log(x); // 1
console.log(y); // 2
console.log(z); // { a: 3, b: 4 }
```

- Adds proposal-optional-catch-binding https://babeljs.io/docs/en/babel-plugin-proposal-optional-catch-binding

```javascript
try {

} catch {

} finally {
  // ensures finally is available in every browsers
}
```

- Adds improved regex support for firefox through (transform-dotall-regex](https://babeljs.io/docs/en/next/babel-plugin-transform-dotall-regex.html) and (proposal-unicode-property-regex](https://babeljs.io/docs/en/babel-plugin-proposal-unicode-property-regex)

- Drops async/generator stuff, the browser we target should allow to use this (excepts iterable async)
2020-09-15 09:26:33 +02:00
David Taylor d29d69e10d
FIX: Invalidate database theme cache when hostname changes (#9908)
Hostname can vary per-site on a multisite cluster, so this change requires converting the compiler_version from a constant into a class method which is evaluated at runtime. The value is stored in the theme DistributedCache, so performance impact should be negligible.
2020-05-29 13:04:51 +01:00
Gerhard Schlager ec2f3169ff FIX: Using the `default_locale` in locale fallbacks caused problems
Locale files get precompiled after deployment and they contained translations from the `default_locale`. That's especially bad in multisites, because the initial `default_locale` is `en_US`. Sites where the `default_locale` isn't `en_US` could see missing translations. The same thing could happen when users are allowed to chose a different locale.

This change simplifies the logic by not using the `default_locale` in the locale chain. It always falls back to `en` in case of missing translations.
2020-05-06 22:59:07 +02:00
Krzysztof Kotlarek b120728999
FEATURE: Ability to add components to all themes (#8404)
* FEATURE: Ability to add components to all themes

This is the first and functional step from that topic https://dev.discourse.org/t/adding-a-theme-component-is-too-much-work/15398/16

The idea here is that when a new component is added, the user can easily assign it to all themes (parents).

To achieve that, I needed to change a site-setting component to accept `setDefaultValues` action and `setDefaultValuesLabel` translated label.
Also, I needed to add `allowAny` option to disable that for theme selector.

I also refactored backend to accept both parent and child ids with one method to avoid duplication (Renamed `add_child_theme!` to more general `add_relative_theme!`)

* FIX: Improvement after code review

* FIX: Improvement after code review2

* FIX: use mapBy and filterBy directly
2019-11-28 16:19:01 +11:00
Penar Musaraj 067696df8f DEV: Apply Rubocop redundant return style 2019-11-14 15:10:51 -05:00
David Taylor 98fbc019a3
FIX: Ensure live-reloading of theme CSS works first time (#8052)
The client-side theme-selector would always apply the first in a series of file change notifications. This has been fixed, so it now applies the most recent notification.

Duplicate notifications were being sent because
- The remote_theme autosave was causing every change notification to be doubled
- Color scheme change notifications were being sent every time a theme was uploaded, even if the colors were unchanged

These duplicate notifications have been fixed, and a spec added to ensure it does not regress in future
2019-08-29 15:47:08 +01:00
Sam Saffron 719a93c312 FEATURE: treat theme_uploads as settings in JavaScript
This change allows themes and components access to theme assets.

This means that inside theme js you can now get the URL for an asset with:

```
settings.theme_uploads.name
```
2019-08-21 16:51:10 +10:00
David Taylor ed5b31f427 FIX: Recompile extra_js theme assets when COMPILER_VERSION changes (#7897) 2019-07-16 16:34:33 +02:00
Osama Sayegh 3d64532273 FEATURE: allow disabling theme components (#7812)
This allows you to temporarily disable components without having to remove them from a theme. 

This feature is very handy when doing quick fix engineering.
2019-07-03 18:18:11 +10:00
David Taylor 7500eed4c0
FEATURE: Multi-file javascript support for themes (#7526)
You can now add javascript files under `/javascripts/*` in a theme, and they will be loaded as if they were included in core, or a plugin. If you give something the same name as a core/plugin file, it will be overridden. Support file extensions are `.js.es6`, `.hbs` and `.raw.hbs`.
2019-06-03 10:41:00 +01:00
Osama Sayegh e20c30987c
FEATURE: detect theme errors and catch them (#7589)
* FEATURE: detect theme errors and catch them

* Bump COMPILER_VERSION

* Feedback

* Override eslint no console for one line

* Can't use our ajax method

* remove emoji from translation file
2019-05-24 17:25:55 +03:00
Gerhard Schlager b788948985 FEATURE: English locale with international date formats
Makes en_US the new default locale
2019-05-20 13:47:20 +02:00
David Taylor e84531a6a6 FIX: Correctly clear theme stylesheet cache when changing color scheme 2019-05-08 16:02:55 +01:00
Daniel Waterworth e219588142 DEV: Prefabrication (test optimization) (#7414)
* Introduced fab!, a helper that creates database state for a group

It's almost identical to let_it_be, except:

 1. It creates a new object for each test by default,
 2. You can disable it using PREFABRICATION=0
2019-05-07 13:12:20 +10:00
romanrizzi 84a3459af6 DEV: Mark flaky tests as pending 2019-04-30 15:01:21 -03:00
Sam Saffron 4ea21fa2d0 DEV: use #frozen_string_literal: true on all spec
This change both speeds up specs (less strings to allocate) and helps catch
cases where methods in Discourse are mutating inputs.

Overall we will be migrating everything to use #frozen_string_literal: true
it will take a while, but this is the first and safest move in this direction
2019-04-30 10:27:42 +10:00
David Taylor 268d4d4c82
FEATURE: Multiple SCSS file support for themes (#7351)
Theme developers can include any number of scss files within the /scss/ directory of a theme. These can then be imported from the main common/desktop/mobile scss.
2019-04-12 11:36:08 +01:00
David Taylor b101065bad
FIX: Sanitize theme settings properly before injecting into stylesheets (#7031) 2019-03-08 08:58:06 +00:00
David Taylor 7878e5007a
FIX: Refactor to prevent themes affecting core stylesheets (#7029)
If a theme setting contained invalid SCSS, it would cause an error 500 on the site, with no way to recover. This commit stops loading theme settings in the core stylesheets, and instead only loads the color scheme variables. This change also makes `common/foundation/variables.scss` available to themes without an explicit import.
2019-02-19 15:55:59 +00:00
David Taylor 91f0468f4e FIX: Allow unbaked theme fields to be destroyed
The after_commit hook was attempting to re-bake theme_fields after they were destroyed, which caused an exception to be thrown
2019-02-12 16:14:43 +00:00
David Taylor 2e48c43546 FIX: Fix safe mode regression
Follow up from a48731e
2019-01-25 17:00:30 +00:00
David Taylor a48731e359
FEATURE: Support additional metadata in theme about.json (#6944)
New `about.json` fields (all optional):
 - `authors`: An arbitrary string describing the theme authors
 - `theme_version`: An arbitrary string describing the theme version
 - `minimum_discourse_version`: Theme will be auto-disabled for lower versions. Must be a valid version descriptor.
 - `maximum_discourse_version`: Theme will be auto-disabled for lower versions. Must be a valid version descriptor.

A localized description for a theme can be provided in the language files under the `theme_metadata.description` key

The admin UI has been re-arranged to display this new information, and give more prominence to the remote theme options.
2019-01-25 14:19:01 +00:00
David Taylor f40c97c367 Remove support for `theme_var` and `theme_color_var` fields
These are remnants of the old 'customization' system, and have been superseded by theme settings
2019-01-18 12:04:23 +00:00
David Taylor 24b59afe2a FIX: Wrap theme javascript inside IIFE to prevent using global namespace 2019-01-17 14:44:10 +00:00
David Taylor def6b2fca1 DEV: Correct theme setting specs 2019-01-17 12:39:34 +00:00
David Taylor 880311dd4d
FEATURE: Support for localized themes (#6848)
- Themes can supply translation files in a format like `/locales/{locale}.yml`. These files should be valid YAML, with a single top level key equal to the locale being defined. For now these can only be defined using the `discourse_theme` CLI, importing a `.tar.gz`, or from a GIT repository.

- Fallback is handled on a global level (if the locale is not defined in the theme), as well as on individual keys (if some keys are missing from the selected interface language).

- Administrators can override individual keys on a per-theme basis in the /admin/customize/themes user interface.

- Theme developers should access defined translations using the new theme prefix variables:
  JavaScript: `I18n.t(themePrefix("my_translation_key"))`
  Handlebars: `{{theme-i18n "my_translation_key"}}` or `{{i18n (theme-prefix "my_translation_key")}}`

- To design for backwards compatibility, theme developers can check for the presence of the `themePrefix` variable in JavaScript

- As part of this, the old `{{themeSetting.setting_name}}` syntax is deprecated in favour of `{{theme-setting "setting_name"}}`
2019-01-17 11:46:11 +00:00
Vinoth Kannan 59e5af466b FIX: call method only if it exists
discourse-objects creating empty Discourse object in window. It fails the _registerPluginCode method call since it is not exist.
2019-01-15 15:55:32 +05:30
Kyle Zhao 61dcd7c52c FIX: validate YAML before save to avoid race condition 2018-12-25 15:08:17 +02:00