This commit adds a new `/hashtag/search` endpoint and both
relevant JS and ruby plugin APIs to handle plugins adding their
own data sources and priority orders for types of things to search
when `#` is pressed.
A `context` param is added to `setupHashtagAutocomplete` which
a corresponding chat PR https://github.com/discourse/discourse-chat/pull/1302
will now use.
The UI calls `registerHashtagSearchParam` for each context that will
require a `#` search (e.g. the topic composer), for each type of record that
the context needs to search for, as well as a priority order for that type. Core
uses this call to add the `category` and `tag` data sources to the topic composer.
The `register_hashtag_data_source` ruby plugin API call is for plugins to
add a new data source for the hashtag searching endpoint, e.g. discourse-chat
may add a `channel` data source.
This functionality is hidden behind the `enable_experimental_hashtag_autocomplete`
flag, except for the change to `setupHashtagAutocomplete` since only core and
discourse-chat are using that function. Note this PR does **not** include required
changes for hashtag lookup or new styling.
Before, `sidebar_list_destination` was an attribute on UserOptionSerializer. The problem was that this attribute was added to user model only when the user entered the preferences panel. We want that attribute to be available all the time, therefore it was moved to CurrentUserSerializer.
This commit excludes posts from hidden topics from the latest posts and user activity RSS feeds. Additionally, it also excludes small actions from the first one.
This view can show multiple posts from the same topic and the aria labels
will now include the post number to more easily differentiate posts in
screen readers.
Theme javascript is now minified using Terser, just like our core/plugin JS bundles. This reduces the amount of data sent over the network.
This commit also introduces sourcemaps for theme JS. Browser developer tools will now be able show each source file separately when browsing, and also in backtraces.
For theme test JS, the sourcemap is inlined for simplicity. Network load is not a concern for tests.
Previously, compiling theme 'extra_js' was done with a number of steps. Each theme_field would be compiled into its own value_baked column, and then the JavascriptCache content would be built by concatenating all of those compiled values.
This commit streamlines things by removing the value_baked step. The raw value of all extra_js theme_fields are passed directly to the ThemeJavascriptCompiler, and then the result is stored in the JavascriptCache.
In itself, this commit should not cause any behavior change. It is designed to open the door to more advanced compilation features which have interdependencies between different source files (e.g. template colocation, sourcemaps).
Normally, arguments passed to components are lazily evaluated. `get prefixElementColors` will only be evaluated for `@prefixType="span"`. However, when using the Ember Inspector in development, arguments are eagerly evaluated and their values displayed in the inspector. Therefore we need to make sure that getters can always be evaluated without exceptions being thrown.
This allows plugins to colocate component JS and HBS under `/plugins/{name}/assets/javascripts/discourse/components`.
`discourse-presence` is updated to use this new pattern, which also serves as an integration test for this part of the build pipeline.
Ember's default resolver only looks for components/services/etc. which are namespaced under the app's `modulePrefix` (`discourse`, in our case). To use addon components/services/etc., the addon must re-export them in its `app/` directory.
In order to support plugins, our custom resolver does a 'suffix match'. This has an unintended side-effect of matching things which are not part of the discourse app or themes/plugins. We've come to rely on this for a few in-repo addons like `select-kit`, `admin` and `wizard`.
This unrestricted 'suffix matching' can cause some very unexpected behaviour. For example, the ember-inspector browser extension has a module called `ember_debug/service/session`. When looking up `service:session`, our resolver was choosing that third-party service over our own Session service. This means Discourse fails to boot when the Ember Inspector is open.
This commit restricts the 'suffix matching' to a known set of namespaces. This brings us one step closer to the default Ember Resolver implementation, and reduces the chance of unexpected behaviour like the ember-inspector issue.
This commit also updates the `dialog-holder` addon to export its service under the app directory, so that we don't need to account for it in the resolver. We may want to consider doing the same for things like `select-kit` and `truth-helpers`, but is beyond the scope of this commit.
Displays a sidebar section link to admin users when
`default_sidebar_categories` site setting has not been configured for the
site.
Internal Ref: /t/73500
