Related:
40fd82e2d1
This PR introduces three new plugin modifiers attached to
- `basic_post_serializer.cooked`
- `basic_topic_serializer.fancy_title`
- `topic_view_serializer.fancy_title`
Implementation note: I had wanted to add them in the `Post` and `Topic`
models themselves, but they do not directly provide access to the
request's scope which is needed for the use case.
This fixes the destination of the auth process in the following
scenarios:
- when landing on a PM or a topic as an anonymous user and then loggin
in
- when landing on a public topic, hitting Reply or Like and then logging
in
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.
Ember workaround to ensure that a field with the same name is correctly
destroyed/created when changing the params and then correctly calling
registerField/unregisterFIeld.
This is covered by the two specs above it:
"automatically redirects when going to /signup" and "automatically
redirects when skipping the signup form"
(Plus, it doesn't do what it says on the label.)
This makes the backtrace for a deprecated icon name error clearer in
terms of pointing out which plugin the icon is being registered from.
The error will only be raised in the test environment.
This PR also extracts out to a separate module the hashmaps & logic for
converting FA4 era icons to discourse FA6 compatible icons. This
isolates that logic for reuse in DiscoursePluginRegistry - otherwise
pulling in the whole SvgSprite resulted in errors.
...loading an invite link that points to a topic they already have
access to.
This "feature" was removed in 07ef1a80a1461123d602c57e366974aed265a91e
as part of the security fix.
Internal ref - t/145628
Currently when using the shortcuts to delete a post the UI would show
you the confirmation modal even if you don't have the right to do it.
This commit fixes the issue at the root in the
`deletePostWithConfirmation` function.
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.
Adds https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/enterkeyhint
to the search inputs.
This hint is used for mobile devices to guide what label
is shown on the onscreen keyboard. By default `return` is
shown, now for search we will see `search`.
Also add `type="search"` to the full page search input for
further guidance.
This feature was originally experimental. We made it baseline in #29572, however this was met with some pushback, so we have decided to make it experimental again.
The original PR couldn't be reverted, but this one basically does the same by cherry-picking all the changes back.
This PR does some things to the about page:
- Hide the stat if there are 0 admins/moderators.
- Count admins and moderators separately, so a user who is both will add
to both counts.
- A user who is both will still show up as a moderator, even if `admins`
is hidden.
Follow-up to https://github.com/discourse/discourse/pull/31271
In the linked PR, we made `<GroupChooser />` use the site's preloaded
list of groups instead of fetching the list from the servers every time
the component is triggered. However, when a site has thousands of
groups, the performance issue has shifted from the server to the browser
— `<GroupChooser />` takes several seconds to render in the browser for
a site with thousands of groups and the sites becomes completely
unresponsive while the component is rendering.
This PR changes the `<GroupChooser />` so it limits the displayed groups
to 100, with ability to filter the list to show more groups when there
are more than 100 groups.
