> [code]
> line1
> line2
> [/code]
would render as
| line1
| > line2
instead of the correct
| line1
| line2
That was due to the `bbcode-block` code using a `slice` to get the content of a block and not taking into account it being nested in a quote block for example.
The fix was to get the content using the `getLines` utils method.
Context: https://meta.discourse.org/t/markdown-bbcode-code-quote-bug/299047
Since we are introducing new ways to search in Discourse, like the AI
semantic search using embeddings, posts can be part of a search result
list without having any search data.
Since the code path already handles this, we only need to add a safety
check when accessing the post_search_data.
This reverts the "fix" made in 44f6b24e34 since it wasn't the correct fix and the emoji picker wasn't showing in chat 🤦♂️
The proper fix is to `stopPropagation()` on the `click` event since the click handler has been made `async`. `preventDefault()` isn't enough.
Should open the emoji picker. But it wasn't 😅
The `handleOutsideClick` event was listening too early and would catch the click on the "more..." option in the autocomplete as a click outside the emoji picker and would immediately close it 🤦
The fix was to defer registering to this event.
In AdminDashboardData we have a bunch of problem checks implemented as methods on that class. This PR absolves it of the responsibility by promoting each of those checks to a first class ProblemCheck. This way each of them can have their own priority and arbitrary functionality can be isolated in its own class.
Think "extract class" refactoring over and over. Since they were all moved we can also get rid of the @@problem_syms class variable which was basically the old version of the registry now replaced by ProblemCheck.realtime.
In addition AdminDashboardData::Problem value object has been entirely replaced with the new ProblemCheck::Problem (with compatible API).
Lastly, I added some RSpec matchers to simplify testing of problem checks and provide helpful error messages when assertions fail.
With the new admin sidebar restructure, we have a link to "Installed plugins". We would like to ensure that when the admin is searching for a plugin name like "akismet" or "automation" this link will be visible. Also when entering the plugins page, related plugins should be highlighted.
Why this change?
Previously, we identified that ActiveRecord's PostgreSQL adapter
executes 3 db queries each time a new connection is created. The 3 db
queries was identified when we looked at the `pg_stats_statement` table
on one of our multisite production cluster. At that time, the hypothesis
is that because we were agressively reaping and creating connections,
the db queries executed each time a connection is created is wasting
resources on our database servers. However, we didn't see any the needle
move much on our servers after deploying the patch so we have decided to
drop this patch as it makes it harder for us to upgrade ActiveRecord in
the future.
Why this change?
Prior to this change, there is no description being displayed for
objects typed theme setting because we were rendering a button instead
of the components for the various setting types which will render the
setting's description.
What does this change do?
1. Introduce `SiteSettings::Description` compoment to centralise the HTML
being rendered across all settings component.
2. Renders the `SiteSettings::Description` component after the edit
button in `site_setting.hbs`.
This commit adds new plugin show routes (`/admin/plugins/:plugin_id`) as we move
towards every plugin having a consistent UI/landing page.
As part of this, we are introducing a consistent way for plugins
to show an inner sidebar in their config page, via a new plugin
API `register_admin_config_nav_routes`
This accepts an array of links with a label/text, and an
ember route. Once this commit is merged we can start the process
of conforming other plugins to follow this pattern, as well
as supporting a single-page version of this for simpler plugins
that don't require an inner sidebar.
Part of /t/122841 internally
Avoid sending user emails if @ mentioning a staged user
Some cases, unknowingly mentioning a staged user would invite
them into topics, sending them an email about it.
* FEATURE: Use browser `dir="auto"` for support_mixed_text_direction
Previously we were using regex to parse all sorts of user input and guess the direction. All out target browsers now support this behavior out-the-box using `dir=auto`, which should be significantly faster.
https://meta.discourse.org/t/dir-auto-for-composer-and-elsewhere/276330
* test
* Update app/assets/javascripts/discourse/tests/integration/components/text-field-test.js
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
* DEV: add toggle to switch to glimmer TopicMap and rename imported hbs-compiler
* DEV: refactor topic-map tests to use assert.dom
* DEV: add topic-map glimmer component
* DEV: remove topic-map widget and switch summary-box to use explicitly passed-in actions
---------
Co-authored-by: David Taylor <david@taylorhq.com>
`apply_transformations` is an async function, and plugins/themes using it expect their transformations to be applied before the loadMore logic continues. This should resolve issues with unencrypted topics when scrolling down topic lists in discourse-encrypt.
Previously, if the sso= payload was invalid Base64, but signed correctly, there would be no useful log or error. This commit improves things by:
- moving the base64 check before the signature checking so that it's properly surfaced
- split the ParseError exception into PayloadParseError and SignatureError
- add user-facing errors for both of those
- add/improve spec for both
**TL;DR:** Refactor autocomplete to use async markdown parsing for code block detection.
Previously, the `inCodeBlock` function in `discourse/app/lib/utilities.js` used regular expressions to determine if a given position in the text was inside a code block. This approach had some limitations and could lead to incorrect behavior in certain edge cases.
This commit refactors `inCodeBlock` to use a more robust algorithm that leverages Discourse's markdown parsing library.
The new approach works as follows:
1. Check if the text contains any code block markers using a regular expression.
If not, return `false` since the cursor can't be in a code block.
1. If potential code blocks exist, find a unique marker character that doesn't appear in the text.
1. Insert the unique marker character into the text at the cursor position.
1. Parse the modified text using Discourse's markdown parser, which converts the markdown into a tree of tokens.
1. Traverse the token tree to find the token that contains the unique marker character.
1. Check if the token's type is one of the types representing code blocks ("code_inline", "code_block", or "fence").
If so, return `true`, indicating that the cursor is inside a code block.
Otherwise, return `false`.
This algorithm provides a more accurate way to determine the cursor's position in relation to code blocks, accounting for the various ways code blocks can be represented in markdown.
To accommodate this change, the autocomplete `triggerRule` option is now an async function.
The autocomplete logic in `composer-editor.js`, `d-editor.js`, and `hashtag-autocomplete.js` has been updated to handle the async nature of `inCodeBlock`.
Additionally, many of the tests have been refactored to handle async behavior. The test helpers now simulate typing and autocomplete selection in a more realistic, step-by-step manner. This should make the tests more robust and reflective of real-world usage.
This is a significant refactor that touches multiple parts of the codebase, but it should lead to more accurate and reliable autocomplete behavior, especially when dealing with code blocks in the editor.
> Written by an 🤖 LLM. Edited by a 🧑💻 human.
