Context: The `btn` mixin is used for every functional button, but this
includes button elements that are not, or should not be, styled like our
default or primary buttons.
To change how this works this commit:
* stripped down the mixin to the bare essentials, mainly limiting to the
properties that use variables.
* moved most things into the `btn` class
* moved some things into specific descriptive classes (default, danger,
success) such as border-radius
Example of button that does not need a border-radius and would benefit
from this:
<img width="464" height="184" alt="CleanShot 2025-09-19 at 12 56 04@2x"
src="https://github.com/user-attachments/assets/e908b2cf-971f-4c1f-aade-7492bad2f89c"
/>
* Deprecated…
* FlatButton component
* btn-active: we should use the proper pseudoclass :active or a –-active
modifier in code if we need it
* btn-text: every button by default is a btn-text. We already have a
class to indicate when it isn’t (no-text)
* fixed btn-link property to make DButton component behave like an
inline link (no padding, link-styling)
* Since I moved styling from .btn, ths means every button now needs a
specific declaration. So I’ve added btn-default where necessary.
* Fixed btn-flat hover effect: The difference between btn-flat and
btn-transparent was getting very ambiguous. I’ve fixed the hover effect
for btn-flat so that the distinction is:
<img width="1094" height="408" alt="image"
src="https://github.com/user-attachments/assets/addf56a9-1f61-463d-abd9-5028a3b88fad"
/>
* Changed the custom icon colour from header icons so it follows the
normal btn-flat styling, the way the sidebar icon already was doing.
(Consistency)
**Other small button-related change along the way**
What | BC | AC |
|----| ----|--------|
Inconsistent save/cancel colours | <img width="1720" height="1084"
alt="CleanShot 2025-09-19 at 15 31 40@2x"
src="https://github.com/user-attachments/assets/227289c3-6ded-4633-868d-6e33c32d83c3"
/> | <img width="1720" height="1084" alt="CleanShot 2025-09-19 at 15 30
56@2x"
src="https://github.com/user-attachments/assets/b23f96c9-04f3-40ea-9fba-2be59eae8e64"
/> |
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
Replaces Ember's deprecated `filterBy` with the native JavaScript method
`filter`. This aligns with modern JavaScript practices, improves code
clarity, and prepares for future deprecations.
Changes involve various components, controllers, and models across the
codebase.
This Pull Request introduces changes that replace the use of .sortBy
with .sort combined with compare from @ember/utils. This update aims to
modernize and standardize sorting operations throughout the codebase.
**Main Changes:**
* Replaced .sortBy with .sort and compare in various components,
controllers, and services to improve sorting practices.
* Updated sorting logic to handle optional chaining (?.) for increased
robustness.
* Adjusted sorting logic, including reversing, in some cases for more
clarity and correctness.
* Added a new deprecation workflow entry to handle sortBy deprecation
logs (discourse.native-array-extensions.sortBy).
Replaces usages of `mapBy` across the codebase with JavaScript's native
`.map`. This resolves deprecation warnings related to Ember's array
extensions and ensures compatibility with future Ember versions.
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
Refactor all instances of `reject` and `rejectBy` across the codebase to
use the native `filter` method paired with appropriate logic. Updates
include changes in models, components, and services.
This ensures compatibility with modern JavaScript standards and reduces
reliance on deprecated array extension methods.
For historical reasons, Discourse has a customized Ember resolver. This
had a much more fuzzy implementation of 'normalize' and 'findTemplate'
functions. This leniency meant that our file naming hasn't always
matched Ember conventions.
Standardizing our naming will make things easier to understand for
developers, and will make adoption of newer ecosystem tooling easier
(e.g. route-based bundle splitting in Embroider/vite)
This commit adds deprecations to the resolver when this leniency is
used, and uses a fully bespoke codemod to rename all of the affected
routes/controllers/templates in the Discourse core repository.
Backwards-compatibility is maintained for anyone looking up the old
names in the resolver.
For now, we want to force the markdown mode for email template
editing for admins, as this is a niche area and doesn't much
benefit from RTE for now...we may want to revert this decision
in future and do a better solution here.
This commit also fixes an issue where, for templates like
system_messages.reviewables_reminder which have a `one` and
`other` key for their text body (and thus "multiple bodies"),
we were showing `object Object` in the editor. Instead, we
want to do the same thing we do for multiple subjects, which
is provide a link to site texts with the text:
> This email template has multiple bodies.
There is only one known case of this happening so far, but at least
this minimally handles the issue for now.
It doesn’t appear this expectation is necessary and it was causing
random failure as sometimes we will have an error from promotheus in the
log totally unrelated:
```
expected block to not output to stderr, but output "E, [2025-09-19T07:16:59.199016 #2050] ERROR -- : Prometheus Exporter, failed to send message Connection refused - connect(2) for \"localhost\" port 9405\n"
```
/t/-/149729
We've had the new floatkit-based autocomplete live in various parts of
Discourse for about a month now, and it's stable enough for us to remove
the site setting letting admins revert to the jquery-based autocomplete
library which is now deprecated.
Previously we introduced threads in Chat DMs in #29170 - however setting
the default to false seems like a better fit.
This will take effect for all new DM chats initiated, existing chats are
not changed but threads can still be turned off manually within each
channel's settings.
Prior to this commit we would show the collapsible DMs section which has
a [+] on hover to start a DM but it was not very nice visually and also
had low affordance.
The new empty DMs state:
<img width="275" height="77" alt="Screenshot 2025-09-16 at 09 07 57"
src="https://github.com/user-attachments/assets/99976dfd-44ec-40f8-a6d1-c0d15f550524"
/>
Prior to this fix we would fetch thread data even if it was present in
the bus data, that's already unnecessary work in a normal situation but
that's even worse when a user is coming back to their computer as we
will have to catchup multiple new threads at once.
Also ensures we correctly await fetching data from server when
necessary.
No test as there are not behavior change.
Prior to this change we would have different context for quick reactions
and for channels this commit just move everything into one context which
is less surprising.
When visiting a channel's members info route directly, the add member
button will always be shown because the logic to show the button assumes
that chat messages have been loaded. Skip for now while we figure out a
fix.
When creating or updating a chat message, uploads attached to the
message are filtered so as to only keep uploads created by the message
creator using `Upload.user`. This field, however, only points to the
_original_ user that created the upload, but since uploads are
de-duplicated, other users might have also uploaded the file. This PR
fixes this by looking at the `UserUpload`s instead (as suggested by
@SamSaffron).
Reported here: https://meta.discourse.org/t/chat-upload-bug/379253
Uses the timestamp at the moment where the user hits send for the
created_at value of the chat message. This should ensure very consistent
ordering.
The implementation is simple:
- collects the timestamp and send it in the request (client_created_at)
- if client_created_at is present and valid, set it as created_at when
creating the message
I suspect that we could end up in a situation where a message is routed
to a slower worker and even if sent before an other message could end up
being persisted before the first message which would cause ordering issues.
This upgrade does not include any breaking changes for Discourse
themes/plugins. Two of the three deprecations in Ember 6 (array
prototype extensions, component-template resolution) have already been
polyfilled in Discourse. The third (action helper/modifier) is
polyfilled in this commit.
Performance testing shows a 2-3% improvement in Discourse rendering
time, thanks to upstream performance fixes in the glimmer-vm since the
regressions in the Ember 5.x series.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
This change prevents the user from starting a group chat with groups
when the current user does not have permission to view the group's
members.
The group is omitted from both the default list and results list when
searching.
Internal ref: /t/-/145343
When a user card is rendered, there are two phases: first, where a
placeholder is created, then after the user card data is retrieved, the
data is inserted into the user card structure.
This causes an issue where, if the placeholder is too close to the
bottom of the viewport, and there's a lot of data being inserted into
the user card, then the user card will be partially rendered outside of
the viewport, resulting in odd scrolling behaviour.
To address this issue, this change makes use of float-kit's ability to
auto-update the position of the user-card. There are three relevant UX
changes from this:
- When the avatar is close to the bottom of the viewport, the
placeholder renders below the avatar, and the final user card is much
bigger, the user card will jump from being below the avatar, to above
the avatar.
- The user card follows the avatar when the chat window scrolls.
- When the avatar scrolls out of view, the user card is hidden.
This commit introduces deprecation warnings for accessing Site.mobileView or
Site.desktopView during application initialization to prevent
layout-related errors and improve code reliability.
The changes include:
* Added deprecation warnings for Site.mobileView and Site.desktopView
access during the initialization phase.
* Updated multiple plugins and components to avoid these deprecated
calls during startup.
* Refactored initialization logic across discourse-ai, discourse-chat,
discourse-calendar, discourse-reactions, discourse-assign,
discourse-subscriptions, and discourse-user-notes plugins
* Improved error prevention by discouraging early access to
view-dependent properties before the application is fully initialized
* Enhanced code maintainability by establishing clearer boundaries
between initialization and runtime phases
This deprecation helps prevent subtle bugs that can occur when
components try to determine the view type before the application context
is properly established, leading to more robust plugin initialization
patterns.
We recently updated `Chat::ListChannelThreadMessages` to take an option
so its `max_page_size` could be configured.
This behavior should be consistent between
`Chat::ListChannelThreadMessages` and `Chat::ListChannelMessages` since
they’re basically doing the same thing.
This patch updates the behavior of the `Chat::ListChannelMessages`
service.
Joffrey JAFFEUX
chapoiandMartin Brennan
Yuriy Kurant
Discourse Translator Bot
Jarek RadoszandLoïc Guitaut
Sérgio Saquetim
David TaylorandSérgio Saquetim
Alan Guo Xiang Tan
Kelv
David Battersby
Charles Lechasseur
Gary Pendergast
Gabriel Grubba
SamandJoffrey JAFFEUX