This change includes the following updates:
- Rename view all to view all drafts
- Remove view all link from drop-down when all drafts are displayed in
the menu
- Different icon for draft topics and PMs (adds envelope for PMs)
- Disable drop-down when New Topic button is disabled (private
categories etc)
- Improve drafts drop-down loading (no longer disables the trigger btn
on click)
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.
This fixes an issue where topics could scroll horizontally on mobile:
https://meta.discourse.org/t/topic-page-layout-issue/348262?u=pmusaraj
It seems some recent core change impacted the read state size/position
This sets the size and position to more static values (not based on
global font changes) to avoid the issue, and removes the horizontal
scroll.
By default, iOS safari will automatically zoom into focused inputs with
font-sizes less than 16px. To avoid this, we had a CSS rule to ensure
inputs always had a large font-size on iOS. This worked, but did lead to
design inconsistencies.
Instead, we can set `user-scalable=no` on the viewport meta tag. Since
iOS 10, this property doesn't actually stop users zooming. But it *does*
still prevent the automatic zooming of inputs. So it solves our zoom
problem, and allows us to remove the CSS font-size workaround.
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>
