```
WARNING: Sass's behavior for declarations that appear after nested
rules will be changing to match the behavior specified by CSS in an upcoming
version. To keep the existing behavior, move the declaration above the nested
rule. To opt into the new behavior, wrap the declaration in `& {}`.
More info: https://sass-lang.com/d/mixed-decls
```
Eventually, this new component will be used everywhere that we render
'decorated' HTML (e.g. all posts and chat messages). It takes the best
bits from our main widget-based post rendering and re-creates it in a
more ember-native way. For example:
- The HTML is first rendered in a detached DOM, so that requests for
images/iframes/etc. are not triggered until after the decoration
- HTML generation and decoration is done in a helper (i.e. during the
'render' phase of the runloop). I think that's the 'most Ember
compatible' way for us to do this. It means that components added via
`renderGlimmer` will be rendered in the same runloop, and it means that
things like `schedule("afterRender")` will work exactly as expected.
- HTML will be re-rendered and re-decorated whenever the `@html` or
`@decorate` arguments change
- BUT, `untrack` is used to ensure that reactive state accessed inside
the decorate function will not trigger a re-render. This is mostly for
compatibility with existing decorators, and we may want to make
reactivity opt-in in future
- A self-contained `renderGlimmer` system is included. This will allow
`helper.renderGlimmer` to be used for any content in these components.
Implementing it in a self-contained way rather than using the service
means that the component will work ok in unit tests, and that rendered
components will show up in the right place in the Ember inspector.
This commit only introduces the new component in DiscourseBanner.
Followups will introduce it elsewhere.
This was intended to provide a better UX for interactive elements in the
composer preview. However, the morphing strategy has irreconcilable
conflicts with our `decorateCooked` API, and so we have been unable to
enable this by default.
Going forward, we're focussing efforts on the WYSIWYG composer to
provide this kind of smooth UX, so we're dropping the
`enable_diffhtml_preview` approach.
In a previous PR, I introduced this system spec that checks that a sidebar link is auto-generated for certain plugins.
This causes problems, because the core test suite can be run with plugins either enabled or disabled, causing flaky tests.
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 change updates the Automation plugin to make use of the `use_new_show_route` plugin flag, as well as generally updating the UI to match current admin UI guidelines. Notable changes include:
- Moving template/router/controller files to make use of the `admin.adminPlugins.show` route.
- Changing the URIs from `/admin/plugins/discourse-automation` to `/admin/plugins/automation`, to match the `PLUGIN_NAME`.
- Adding UI wrappers around the New/Edit forms, and polishing the list of defined automations.
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
This commit adds a new Localization config page for
admins, as a basic filtered site setting page similar
to Legal and Notifications. Included settings are:
* default locale
* allow user locale
* set locale from accept langauge header
* onebox locale
* display local time in user card
* discourse local dates enabled
* support mixed text direction
* unicode usernames
* allowed unicode username characters
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.
Rename `min_first_post_typing_time` to `fast_typing_threshold` and
provide admin 4 options:
- disabled
- low - 1 second
- standard - 3 seconds
- high - 5 seconds
Related PRs:
- https://github.com/discourse/discourse-zoom/pull/112
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"
/>
"context" notation is not supported in iOS < 16.4, and we don't have any
post-processing on our CSS files which can automatically make that
conversion.
For now, changing the stylelint config to enforce the more-compatible
syntax, and updating all occurences.
```
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.
