This commit makes the
[color-scheme-toggle](https://github.com/discourse/discourse-color-scheme-toggle)
theme component a core feature with improvements and bug fixes. The
theme component will be updated to become a no-op if the core feature is
enabled.
Noteworthy changes:
* the color mode selector has a new "Auto" option that makes the site
render in the same color mode as the user's system preference
* the splash screen respects the color mode selected by the user
* dark/light variants of category logos and background images are now
picked correctly based on the selected color mode
* a new `interface_color_selector` site setting to disable the selector
or choose its location between the sidebar footer or header
Internal topic: t/139465.
---------
Co-authored-by: Ella <ella.estigoy@gmail.com>
In the current admin index page, all plugins show up as tabs. This includes plugins with auto-generated config routes.
This changes the tabs to include only plugins with custom UIs.
This is the first in a series of PRs to introduce a
ProseMirror-based
WYSIWYM editor experience
alongside our current textarea Markdown editor.
Behind a hidden site setting, this PR adds a toggle to the composer
toolbar, allowing users to switch between the two options.
Our implementation builds upon the excellent ProseMirror and its
non-core Markdown
module, using the
module's schema, parsing, and serialization definitions as the base for
further Discourse-specific features.
An extension API is included to enable further customizations.
The necessary extensions to support all Discourse's core and core
plugins features **will be implemented in subsequent PRs**.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
This change adds a sidebar link for each plugin that fulfils the following criteria:
- Does not have an explicit admin route defined in the plugin.
- Has at least one site setting (not including enabled/disabled.)
That sidebar link leads to the automatically generated plugin show settings page.
due to an issue with LEFT JOIN, we were enqueue a "chat summary" email
for every new messages in a channel, instead of for every new mentions 😬
This bloated the sidekiq queue with a lot of unecessary jobs as seen in
- https://meta.discourse.org/t/-/347197
- https://meta.discourse.org/t/-/346542
Thankfully, it wasn't sending those emails as the query for listing the
unread mentions and dms was correct when generating the chat summary
email.
Due to a recent regression the selection management was failing in
drawer mode for threads. We were not correctly setting the active
thread.
This commit fixes the issue and adds a spec.
Previously the return to forum link would automatically take you to the
forum homepage, however this was not intended functionality. We should
attempt to take the user to their last viewed forum page.
This change fixes a bug in how we determined what the destination link
should be.
Internal ref: /t/110508
All of these buttons use our default grey background styling, but aren't
carrying the `btn-default` class, which makes them easier to target in
themes. This PR adds the class.
We used this flag for experimenting with admin plugin sidebars. We have now settled on a tabbed layout, and this is no longer needed.
This PR simply ignores the flag in a backwards-compatible way, so we can discontinue usage in plugins and then remove the backwards-compatibility in core.
The following case was bugged:
- visit a thread in full page chat
- click channel title
- click back button in channel navbar
- 💥 you would have a channel with limited width as if there was
still the thread showing next to it, but it was empty
These changes allow to load model when loading a screen of the drawer,
the underlying idea is to avoid having to rely on the global
`activeChannel`, this essentially makes each screen responsible for it's
data.
This change is also fixing a bug where clicking on a link routing to the
same screen of the drawer you are already on, would display a blank
drawer.
This commit does several changes:
- it moves the ownership of the last message info to the channel instead
of storing it on the message, it avoids the need to iterate over every
messages
- makes an optimistic update of the last read message id
- adds a spec to confirm this behavior
Users can now decide if they want to send a message on:
- <kbd>enter</kbd>
- <kbd>meta + enter</kbd>
If you choose <kbd>meta + enter</kbd>, <kbd>enter</kbd> will add a
linebreak.
<img width="192" alt="Screenshot 2025-01-21 at 12 57 48"
src="https://github.com/user-attachments/assets/abfd6f8b-83b3-4e6f-be67-8f63d536ca8a"
/>
```
Checking for expected text of nil is confusing and/or pointless
since it will always match. Please specify a string or regexp instead.
plugins/chat/spec/system/chat_message_interaction_spec.rb:51
```
Lazy loading images naturally causes a slight delay, because the browser
only starts to load them after laying out the DOM and checking whether
they're in the viewport. Plus, in Safari, re-rendering the DOM of a
lazy-loaded image always causes a brief flicker, even if the image is
already cached in the browser.
Lazy-loading is most beneficial on large one-off images which are often
rendered outside the viewport. That's frequently the case for images
which users share in topics. Avatars, on the other hand, are very small
images, they're very often above-the-fold, and the same avatar often
occurs many times on the same page.
Therefore, this commit removes `loading="lazy"` from avatars, which
should improve avatar load times in all browsers, and stop the flicker
in Safari.
---
Tapping logo to reload topic-list in Safari. Before: https://github.com/user-attachments/assets/242299f8-aa13-4991-b321-2f143603ed26
After: https://github.com/user-attachments/assets/5e5bfd28-3a78-40fd-af21-3d92e7b3ba8a
Each case simplified:
`next(() => later(() => ...))` -> "wait 0 ms then wait X ms"
`next(() => debounce(() => ...))` -> "wait 0 ms then wait X ms
(debounced)"
`next(() => scheduleAfter("render", ...))` -> "in the next (empty) run
loop, do the thing (after a no-op render step)"
Stylelint is a css linter: https://stylelint.io/
As part of this change we have added two javascript scripts:
```
pnpm lint:css
pnpm lint:css:fix
```
Look at `.vscode/settings.json.sample` and `.vscode/extensions.json` for
configuration in VSCode.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Previously if you linked to a chat thread inline, our oneboxer
did not have special handling for this, so the link would end
up with the text "Chat #channel-name" which is not ideal for a
thread.
This commit makes it so the thread onebox is in the format
"Thread title - #channel-name" if the thread title exists,
otherwise we show "Thread in #channel-name"
discourse-emojis is used in chat only for message actions to show a
difference with the the other emojis so people don't think it's just the
smiley emoji.
When we had no width stored for the side panel in the local storage,
essentially the computation would end up being:
```javascript
Math.min(null, 1000);
```
Which would output: 0. This commit ensures we have a default for store
width: MIN_PANEL_WIDTH. And also uses the same value in CSS and JS.
I had to change z-layers of chat-side-panel resizer as it was
interfering with system specs changing the notification level of a
thread, when trying to click the option in the dropdown, it would
instead click the resizer as it would appear on top of the dropdown.
Tried to write a test but couldn't get something reliable.
When tapping something on a touch-enabled device, `mouseMove` events are
still fired, so floatkit would still be triggered even if configured for
'hover' only. For links, this would be particularly strange, because the
tooltip would appear for a split-second, before the page navigation
occured.
To avoid this problem, we can use the more-modern 'pointerMove' event,
and check the `pointerType` to exclude 'touch'
The stacking context fix we use in chat to avoid:
https://bugs.webkit.org/show_bug.cgi?id=262287 was causing this weird
behavior in chat where the scroll event wouldn't fire when the finger is
on text and not an empty area of the scrollable div.
This simplified implementation seems to work reliably and avoids the
issue.
When clicking the "new features" notification item for
admins that navigates to /whats-new, the user notification
menu was not closing. This was happening because inside
the UserMenu::Menu component, the `routeDidChange` event
was firing and calling `closeUserMenu()`, however this is already
called inside the `Header` component via `toggleHamburger()`.
This is _only_ happening for the "new features" notification
item, other items have already been destroyed and they do not get
the `routeDidChange` event. No idea why, but this fixes the issue
in a global way.
`discourse-common` was created in the past to share logic between the
'wizard' app and the main 'discourse' app. Since then, the wizard has
been consolidated into the main app, so the separation of
`discourse-common` is no longer useful.
This commit moves `discourse-common/(lib|utils)/*` into
`discourse/lib/*`, adds shims for the imports, and updates existing
uses in core.
And change the "formula" to check for duplicate messages to
- no duplicate check in 1:1 DMs
- only duplicate check in group DMs / channels, for posts made by the
same user, in the past 10 seconds
Internal ref - t/144262
