This reverts commit 91e9c1c81343990d5ebbb3a3bb7c68ec4445d610.
After feedback, for now we are reverting this change. This is not
permanent, the settings sidebar will be removed again, after we:
* Visually group the settings the same way as the sidebar does
on All Settings
* Add more settings pages to the main admin sidebar to cover the ~250
settings not yet represented there
Small alignment fix for user stream items on desktop, following changes
made in #31122
We currently have a combination of `post-list-item` and
`user-stream-item` classes within these pages, so I've also applied some
shared styles to these elements to provide a more consistent layout.
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>
Plugins like for example AI or Akismet create reviewable items. When the
plugin is disabled, then we cannot properly handle those items.
In that situation, we should display warnings about unhandled types.
Instruct admin to reenable plugins. In addition, we should allow the
admin to delete all pending reviews from disabled plugins.
This is a follow-up to 71eb2f6cda9ad8a69ba1ae7d506440c3ff0bc9cb, we have
outlets in this wrapper too — so best to re-enable pointer events on all
immediate children of the disabled wrapper.
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>
Before this commit it was complicated to render a `Checkbox` outside of
a `CheckboxGroup` as you would get no title, no description, no optional
hint and not tooltip.
This commits makes all of this possible by adding a special case for
checkboxes, and sharing code for tooltips and optional hint.
This commit also uses this opportunity to refactor part of the code to
use curryComponent and reduce code duplication.
This experiment hides the list of categories in the inner
sidebar for the main site settings page if the admin sidebar
is enabled. It also defaults the list of settings to "All"
instead of a specific category.
Our theory here is that people who use this page are using
it to find an exact setting, not to go through the categories
one by one. Our admin sidebar also has several groups of important
settings already too, so that can be used for browsing.
Finally, the input on the page focuses when you load it, so
filtering is faster.
Related to
https://meta.discourse.org/t/double-button-inconsistencies-post-menu/349845
This does some general clean up...
* **Moves shared mobile/desktop styles into /common**
We had some mobile hover states for some reason, and desktop hover/focus
states can be moved to common and gated with `.discourse-no-touch`...
this means we're applying them on capabilities rather than device type
* **Adds some `-d-post-control-` variables to make theming easier**
Theme authors can replace the variables without worrying about selector
specificity
* **Removes an overridden fade-out class from likes**
We were overriding the effect here anyway
* **Fixes a janky hover transition effect on the like button**
This was being incorrectly inherited from another button
...and fixes some issues
* **Corrects border radius on double buttons (likes, flags)**

* **Corrects double button height issues for flags**

* **Adjusts the flag count to avoid the lumpy circle CSS problem**

* **Removes lingering post-tap focus/hover states on mobile by applying
`.discourse-no-touch` and `focus-visible`**
Tested both glimmer and legacy.
- `@height` was supported but not working correctly, this is now fixed
and tested
- `@preview` was not supported, we would always hide the preview in form
kit. You now have control over this, default `false`.
We're seeing drops in CLS performance and the animation of this element
may likely be the culprit. We can try removing and seeing if this is
indeed the issue.
FormKit allows you to set `@format` on a field which will set the width
of the wrapping container of the control. However, title and
descriptions are out of this container. FormKit will now by default
applies the same format to title and description.
You can override this behavior by using `@titleFormat` and
`@descriptionFormat`.
This commit converts the `AdminReport` component, which is quite
high complexity, to gjs. After this initial round, ideally this
component would be broken up into smaller components because it is
getting quite big now.
Also in this commit:
* Add an option to display the report description in a tooltip, which
was
the main way the description was shown until recently. We want to use
this on the dashboard view mostly.
* Move admin report "mode" definitions to the server-side Report model,
inside a `Report::MODES` constant, collecting the modes defined in
various
places in the UI into one place
* Refactor report code to refer to mode definitions
* Add a `REPORT_MODES` constant in JS via javascript.rake and refactor
JS to refer to the modes
* Delete old admin report components that are no longer used
(trust-level-counts, counts, per-day-counts) which were replaced
by admin-report-counters a while ago
* Add a new `registerReportModeComponent` plugin API, some plugins
introduce their own modes (like AI's `emotion`) and components and
we need a way to render them
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.
This update makes some small improvements to the posts route front-end.
Specifically, it adds a title to the page, and it improves the
positioning of expand/collapse caret.
The name "Staff Notice" was not quite right since TL4 users
can also add these notices. This commit changes the wording to
"Official Notice".
In addition to this, currently you have to go look into the staff
action logs to see who is responsible for a notice. This commit
stores the ID of the user who created the notice, then shows this
information on each notice to staff users.
Finally, I migrated the ChangePostNoticeModal component to gjs.
Recently we introduced a new `PostList` component (d886c55f63). In this update, we make broader adoption of this component. In particular, these areas include using the new component in the user activity stream pages, user's deleted posts, and pending posts page. This update also takes the existing `posts` route and adds a barebones front-end for it to view posts all in one page.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
The solution in (https://github.com/discourse/discourse/pull/30547)
using `em` units was causing readability problems for code blocks in
mobile. This reverts to the previous solution
(https://github.com/discourse/discourse/pull/30536) of using `font-size:
inherit` for code within heading elements.
The downside is that the code in heading won't be slightly smaller than
the other text like it is for inline code in paragraphs, but it seems
worth it to avoid causing other size issues.
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.