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.
There are a number of minor changes in this commit :
1. Combine the "Themes" and "Components" links in the admin sidebar into
a single tab labelled "Themes and components"
2. The combined tab links to the `/admin/config/customize/themes` page
(titled as "Themes and components")
3. Add a new "Components" tab to the "Themes and components" page.
There's already an existing "Themes" tab
4. Add a "back to" link at the top of individual theme/component page to
navigate back to the respective tab in the "Themes and components" page
5. Remove the themes/components list/sidebar that currently serves for
navigating between themes/components
6. Remove the header in the theme/component page
Changes 4–6 apply only if the admin sidebar is enabled; they have no
effect otherwise.
Internal topic: t/146006.
Follow up to: https://github.com/discourse/discourse/pull/31670
This deletes the mixin.
Did a search across our repos with `/mixins\/user-field/`, only still
used in `plugin-api`.gjs which is being deleted in this PR.
This was preventing favorites emojis to work correctly as it was using
topic context. No tests for now as it's a very specific behavior hard to
test with acceptance test and a system spec seems heavy for this.
We made some changes to the SmallUserList widget in #31549. This accidentally broke at least one plugin (discourse-topic-voting) which uses it.
This fixes that by defaulting isVisible to true (old behaviour) when the argument is missing.
When you are uploading, it just causes weird problems
when you switch between markdown/rich editors, and it's
not something we really want to support. This commit
disables the Composer::ToggleSwitch while uploading.
Redis / Valkey over TLS requires authentication involving both a
username and a password.
On most instances, the default username is `default`, but this allows
Discourse to provide its own.
Adds support to typing `---`, `___` or `***` to create a horizontal
rule.
Converting when typing `---` is actually written here as an en-dash +
`-`, because the typographer replacements extension turns `--` into an
en-dash first.
`___` and `***` are only triggered after a whitespace, because they
could also mean bold+italic.
This commit updates `Migration::SafeMigrate` to protect against unsafe
ways of adding a Postgres index concurrently.
Per postgres documentation:
If a problem arises while scanning the table, such as a deadlock or a
uniqueness violation in a unique index,
the CREATE INDEX command will fail but leave behind an "invalid" index.
This index will be ignored for querying
purposes because it might be incomplete; however it will still consume
update overhead. The recommended recovery
method in such cases is to drop the index and try again to perform
CREATE INDEX CONCURRENTLY .
Therefore, the simplest way for us to ensure that migrations that create
indexes concurrently are idempotent is to follow postgres'
recommendation of dropping the index first before trying to create the
index concurrently.
There's no `textarea` with the rich editor, so being `undefined` it
fails with a `TypeError: Cannot read properties of undefined (reading
'id')`.
This has the same behavior with the textarea editor but works much
better (positioning closer to the caret) with the rich editor.
These specs are causing far more flakes and trouble than they are worth,
I think it's just the killer
combination of relying on messagebus and background jobs along with the
specs being quite big. Let's just get rid of them...
