Fixes the custom homepage crawler output to include links to the site's
top menu.
This also provides a way to override that content via a plugin. Example
usage in a `plugin.rb` file:
```
register_html_builder("server:custom-homepage-crawler-view") do |c|
"<div>override</div>"
end
```
This reduces some duplicate color assignment to tags and rolls them up
under a common css var
```css
:root {
--tag-text-color: var(--primary-high);
}
.extra-info-wrapper {
--tag-text-color: var(--header_primary-high);
}
```
This also makes the tag separator color consistent with the tag color,
by setting it to `--tag-text-color`
Ultimately we have 3 tag text color states (this appeared to be
consistent across all tag styles):
* Default: primary-high
* Header: header__primary-high
* Visited topic in the topic list: primary-medium
Previously we were showing a loading spinner, but the old user list
persisted so the spinner was often off the bottom of the screen. This
commit updates the `users` list to be a getter, so it's always perfectly
in-sync with the `_results` set. That means no users will be shown while
a new list is being loaded, so the spinner is more visible.
https://meta.discourse.org/t/load-spinner-missing-from-dynamic-pages/357525/4
This reverts commit 992bdf173ad8ad25764c0a89132bc35df4c81f12.
This change was causing issues in a [third party
plugin](https://meta.discourse.org/t/events-plugin):
https://meta.discourse.org/t/events-plugin/69776/869
```
Uncaught Error: Could not find module `discourse/mixins/singleton` imported from `discourse/plugins/discourse-events/discourse/models/provider`
at loader.js:247:1
at h (loader.js:258:1)
at u.findDeps (loader.js:168:1)
at h (loader.js:262:1)
at u.findDeps (loader.js:168:1)
at h (loader.js:262:1)
at requireModule (loader.js:24:1)
at y (app.js:170:18)
at b (app.js:193:19)
at app.js:156:29
at g.start (app.js:167:1)
at HTMLDocument.<anonymous> (start-app.js:5:7)
at discourse-boot.js:13:12
at discourse-boot.js:1:1
```
Currently we allow for 2 theme screenshots to be specified,
with a lightweight spec to allow both a light and dark
version of the screenshot. However, we were not storing this
screenshot name anywhere, so we would not be able to use it
for light/dark switching.
This commit fixes that issue, and also does some general refactoring
around theme screenshots, and adds more tests.
Test is flaking in CI with:
```
Failure/Error: expect(theme_translations_settings_editor.get_input_value).to have_content("Bonjour!")
expected to find text "Bonjour!" in "Hello there!"
[Screenshot Image]: /__w/discourse/discourse/tmp/capybara/failures_r_spec_example_groups_admin_customize_themes_when_editing_theme_translations_should_allow_admin_to_edit_and_save_the_theme_translations_from_other_languages_797.png
~~~~~~~ JS LOGS ~~~~~~~
(no logs)
~~~~~ END JS LOGS ~~~~~
./spec/system/admin_customize_themes_spec.rb:158:in `block (3 levels) in <main>'
```
The test has been flaking in CI with the following message:
```
Failure/Error: measurement = Benchmark.measure { example.run }
expected: "draft"
got: ""
(compared using ==)
[Screenshot Image]: /__w/discourse/discourse/tmp/capybara/failures_r_spec_example_groups_chat_composer_draft_when_loading_a_channel_with_a_draft_loads_the_draft_458.png
~~~~~~~ JS LOGS ~~~~~~~
~~~~~ END JS LOGS ~~~~~
./plugins/chat/spec/system/chat_composer_draft_spec.rb:31:in `block (3 levels) in <main>'
```
This is a stripped-back version of the Search Banner
component https://meta.discourse.org/t/search-banner/122939,
which will be renamed to Advanced Search Banner,
see https://github.com/discourse/discourse-search-banner/pull/84.
This welcome banner interacts with the header search.
When `search_experience` is set to `search_field`, we only
show the header search after the welcome banner scrolls
out of view, and vice-versa.
Only new sites will get this feature turned on by default,
existing sites have a migration to disable it.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: Jordan Vidrine <jordan@jordanvidrine.com>
This is a follow up to 6820622467ab3613e824f0cb6219def2a575bc1d.
This commit addresses migrations that uses `remove_index` with the
`if_exists: true` option to drop an existing index before creating an
index using the `concurrently` option.
This commit also reruns two migration which may have caused indexes to
be left in an `invalid` state.
### Reviewers Note
Plugin tests are failing due to
https://github.com/discourse/discourse-translator/pull/251
Since d2409f2964e85a4cb134f119d1bdddce54156175, these calculations are
now incredibly cheap, and the caches introduced by `@computed` become
the bottleneck. On a site with 5k+ categories, removing these caches
results in a 4x render time improvement for their homepage (~2s ->
~0.5s).
Technically, this means these properties will no longer be reactive for
places that depend on them using computed property syntax. However, they
are still reactive for modern code with autotracking. Given that the set
of categories doesn't change after initial load, I think this is
acceptable. If we do run into any issues, then we can update the related
code to use autotracking.
Note: `@dependentKeyCompat` has similar perf overheads to `@computed`,
so that's why I haven't used that for backward-compat.
Now that we support multiple drafts, we can avoid the extra draft check
within composer when creating a new topic or reply. For posts, we
already autoload the existing draft into composer when the user tries to
create a new reply, so there is no longer a need for the abandon draft
dialog.
Drafts can still be deleted by closing the composer (using a different
dialog) or manually via the User Drafts page.
This change also correctly sets the draft key within composer actions
when switching from a post reply to a linked topic.
The "Tag synonyms when visiting edit tag page allows an admin to create
a new tag as synonym when tag does not exist" system
test was flaky with the following error:
```
Failure/Error: super
Capybara::ElementNotFound:
Unable to find css "#add-synonyms.is-expanded"
```
Backtrace points to the following location:
```
...
./spec/system/page_objects/components/select_kit.rb:30:in `expanded_component'
./spec/system/page_objects/components/select_kit.rb:88:in `search'
...
```
What I noticed is that
`PageObjects::Components::SelectKit#expanded_component` has already
found the expanded element when it calls `#expand`. Therefore, there is
no need for us to search for it again.
The "Homepage allows users to pick their homepage" system test was flaky
because it was assuming that waiting 5 seconds was enough for the
request to save the user's preferences to complete. This may be true in
development where we have powerful development machines. In production,
Capybara's default wait time is actually 10 seconds so we should respect
that.
The "Admin editing objects type theme setting when editing a theme
setting of objects type allows an admin to edit a theme setting of
objects type via the settings editor"
system test was flaky because of the way we were filling in content into
AceEditor. It is not a normal input and does not seem to function like a
normal input. Using Capybara's `fill_in` method was not reliable so we
will just use AceEditor's API directly to update its input.
This improves the new rake task to bulk delete posts based on feedback:
- Honour the `can_permanently_delete` site setting.
- Fix a warning about a scope order no being applied due to batching.
- Fix an issue where double delete would result in duplicate user
histories.
When creating a DM to a group in chat, we show
a count of users for that group if the number of
users exceeds SiteSetting.chat_max_direct_message_users.
However, we were also counting bot users here, we should
only be counting human users, this led to confusion because
the chat group count was different from the one on
e.g. /g/:group_name
When a user typed `:emoji` using the autocomplete on the rich editor,
but then used the "more" option to open the emoji picker and picked an
emoji from there, we were leaving the dangling `:emoji` there and just
added the emoji node after it.
We now check if there's a partial emoji exactly at the caret position,
and replace it too.
When copying images from cooked, we have a `data-base62-sha1` attribute
instead of a `data-orig-src` that we were expecting.
This PR fixes it and adds a system test.
At the moment, every call to `Category.subcategories` causes an
iteration through every single category. For sites with thousands of
categories, this is incredibly expensive, and makes things like the
category dropdown & sidebar rendering very slow.
To improve things, we can create a map of parent_category => [child
categories] in a single iteration, cache it, and then use that when
finding subcategories.
The `@computed` decorator ensures that this cache will be recalculated
whenever the list of categories changes (e.g. when sideloading new
categories in the experimental lazy-loaded-categories mode)
When opening the sidebar on a site with thousands of categories,
`getSubCategoryIds` is called repeatedly and the nested loops burn a lot
of CPU time.
The `Category.descendants` logic is similar in efficiency, but crucially
it is cached so it only needs to be calculated once per category. So
this change should make a big difference to sidebar performance on sites
with lots of categories.
We already support `/apple-app-site-association` at the root. Apple also
accepts `.well-known/apple-app-site-association` as a valid path so this
adds that as well, just in case.
Previously, I was getting this error in the JS console:
```
livereload.js:2232 Mixed Content: The page at 'https://DOMAIN/' was
loaded over HTTPS, but attempted to connect to the insecure WebSocket
endpoint 'ws://DOMAIN:443/_lr/livereload'. This request has been blocked;
this endpoint must be available over WSS.
````
Adding a `https: true` option seems to fix the problem when running the
local server over an https proxy. (It'll be marked as `false` when the
protocol isn't https.)
This isn't just a warning, opening `/tests` is delayed about 10-20
seconds.
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
The service worker isn't served via normal asset paths or the CDN.
Instead, the ERB was being compiled by sprockets, fished out of the
`public/` directory by the static_controller, and then the
sprockets-specific stuff like `sourceMappingUrl` was being removed.
Instead, we can put the ERB under `views/static/`, and have it evaluate
at runtime. There are only a couple of super-cheap interpolations, plus
the route is cached in nginx, so there is no performance concern.
This takes us one step closer to removing sprockets.
