Marking mixed-decls as silenced & fatal simultaneously is causing a
warning "Ignoring setting to silence mixed-decls deprecation, since it
has also been made fatal"
The intention is for it to be silenced for themes/plugins, but fatal for
core.
This improves the error message(s) displayed when an error happens while
using a social login to log in / sign up into a Discourse community.
Unfortunately, we can't be super precise in the reason behind the error
(it can be the user clicked "cancel" during the authorization phase, or
any of the plethora of other possible errors) because the reason isn't
provided (either for security reasons, or because it's just hard to do
so in a reliable & consistent way accross all social logins).
The best I could do was to
- add the name of the "social login" provider in the error message
- tweak the copy a bit for the different cases handle
- fix the CSS/HTML to match the one used by the main application
In order to show the name of the provider, we use either the "provider"
or the "strategy" query parameter, or use the name of the authenticator
(if it's the only one enabled).
Internal ref - t/153662
---
**BEFORE**
**AFTER**
Fixing this everywhere will be a very large undertaking, so we're
deferring it until there is a concrete timeline for it becoming an error
in sass.
In the meantime, we'll be adding a stylelint rule to enforce ordering of
declarations/nested-blocks/mixins, so that will go some way towards
avoiding this deprecation.
Running this spec locally I was getting an error:
```
1) translate accelerator plugins loads plural rules from plugins
Failure/Error: DiscoursePluginRegistry.unregister_locale("foo")
NoMethodError:
undefined method `unregister_locale' for class DiscoursePluginRegistry
# ./spec/lib/freedom_patches/translate_accelerator_spec.rb:113:in `block (3 levels) in <main>'
Finished in 0.17998 seconds (files took 1.88 seconds to load)
1 example, 1 failure
Failed examples:
rspec ./spec/lib/freedom_patches/translate_accelerator_spec.rb:117 # translate accelerator plugins loads plural rules from plugins
```
On top of this, this spec was flakey, Im not sure this is going to fix
flakyness, but this seems like a good first step.
Previously when changing back to the same email (ie. change to new
email, then change back again) we can easily end up showing the
incorrect old email if changing back to the same email more than once.
Then passing the incorrect old email causes an error as it can't be found.
This happens because we only searched for a combination of `user_id` and
`new_email` which can load an older change from the database. By using
the current email address when finding / initializing the
`EmailChangeRequest` we can prevent this issue as we will be creating a
new entry rather than loading an outdated one.
## 🔍 Overview
This update adds the ability for users to manually add translations to
specific posts. It adds a 🌐 icon on the post menu where you can click to
add translations for posts.
It also introduces a new site setting:
`content_localization_debug_allowed_groups` which is convenient when
debugging localized posts. It adds a globe icon in the post meta data
area along with a number of how many languages the post is translated
in. Hovering over the icon will show a tooltip with access to editing
and deleting the translated posts.
## 📸 Screenshots
<img width="1234" alt="Screenshot 2025-05-07 at 13 26 09"
src="https://github.com/user-attachments/assets/9d65374d-ee3e-4e8b-b171-b98db6f90f23"
/>
<img width="300" alt="Screenshot 2025-05-07 at 13 26 41"
src="https://github.com/user-attachments/assets/6ee9c5e6-16ed-4dab-97ec-9401804a4ac8"
/>
There are instances of posts being deleted by system_user where the context is left blank in the staff action logs, leading to confusion about why exactly they have been deleted.
This change deprecates using the PostDestroyer as system_user without providing a context, and adds a context to all call sites currently missing it in core. Plugins to be done after this is merged.
Previously we were compiling core and theme CSS into two targets:
Desktop and Mobile. The majority of both files was the 'common' css.
This commit splits those common styles into their own targets so that
there is less duplication. This should improve compilation times + cache
reuse, as well as opening the door for experiments with
media-query-based mobile-modes.
The only functional change is that we can no longer use `@extend` to
copy 'common' rules in core to mobile/desktop. This is probably for the
best. Duplication and/or mixins are a more native-css pattern for this.
Plugins already have a common / mobile / desktop pattern, so are
unchanged by this commit.
- Move some data transforming into contracts.
- Add some missing specs.
- Use the `try` step.
- Improve the `model` step a bit by allowing to catch any exception,
and not only `ArgumentError`. We already had the mechanism to inspect
which exception was caught.
We are no longer using any of the transpilation/bundling features of
Sprockets. We only use it to serve assets in development, and then
collect & fingerprint them in production. This commit switches us to use
the more modern "Propshaft" gem for that functionality.
Propshaft is much simpler than Sprockets. Instead of taking a
combination of paths + "precompile" list, Propshaft simply assumes all
files in the configured directory are required in production. Previously
we had some base paths configured quite high in the directory structure,
and then only precompiled selected assets within the directory. That's
no longer possible, so this commit refactors those places (mostly
plugin-related) to use dedicated directories under
`app/assets/generated/`.
Another difference is that Propshaft applies asset digests in
development as well as production. This is great for caching & dev/prod
consistency, but does mean some small changes were required in tests.
We previously had some freedom-patches applied to Sprockets. Some of
those had to be ported across to Propshaft. We now have three patches:
1. Skip adding digest hashes to webpack-generated chunks (which are
already digested, and referred to from other js files)
2. Avoid raising errors for missing assets in test mode. We don't always
compile assets before running basic RSpec tests.
3. Maintain relative paths for sourcemap URLs, so that files don't need
to be recompiled depending on their CDN path
Significant refactors are made to the `assets.rake` and `s3.rake` tasks,
which rely on implementation details of Sprockets/Propshaft.
Previously all locale bundles would be built & compressed during
assets:precompile. For most sites, only one of these languages was
actually used, so this is fairly wasteful.
This commit moves the main locale bundle into the
ExtraLocalesController, which has recently undergone many improvements
to make it more efficient. This allows locale files to be bundled "just
in time" when they're first accessed.
Now that brotli level=6 is enabled for these assets in our nginx config,
this change should have no impact on the locale bundle size.
This is mainly used for the test environment where
`Discourse.current_hostname` and `GlobalSetting.relative_url_root` can
be stubbed.
### Reviewer notes
We don't really need a test here since this doesn't really affect the
production environment.
This commit adds
- `topic_localization` containing its topic, a locale, title, and
fancy_title
- `post_localization` containing its post, a locale, raw, cooked, the
associated post's version
- and also APIs to add them
Reviewer note: We may ask ourselves "why create separate models instead
of one that is generic?" but the different localizable models may be
vastly different. For example in posts we only have raw that we need to
translate, and topics we have only title, but for categories we have
name and description. Then, we may ask ourselves "why not create a
polymorphic one that takes in model and column name?" and then we end up
with the same thing as what we have currently which is custom fields
(which is a mess in itself). Also, when replacing the untranslated
content to the translated one, we may find it easier to just `join` +
`coalesce` on the dedicated table - it would be a much simpler query
than polymorphism.
- Load moment and moment-timezone-with-data via webpack import instead
of including copies in every locale file
- Fetch static files from node_modules instead of `vendor/`
This cuts the size of locale-specific JS files in half, since they no
longer include moment itself.
Currently, trust level is calculated with this formula:
`[granted_trust_level, previous_trust_level,
SiteSetting.default_trust_level].max`
When a user is invited, SiteSetting.default_invitee_trust_level should
be respected in that calculation.
This commit adds a new `--exclude-pattern` CLI option which supports
excluding files using unix style pattern matching.
This is to simplify a couple of situations:
1. Running `bin/turbo_rspec plugin/spec` but we want to exclude all
tests in the `plugin/spec/system` folder.
Example: `bin/turbo_rspec --exclude-pattern="*spec/system*"
plugin/spec`
2. Running `bin/turbo_rspec plugin/*/spec/system` but we want to exclude
tests for a particular plugin.
Example: `bin/turbo_rspec --exclude-pattern="plugins/chat/*"
plugin/*/spec/system`
Adds support for a tag-chooser in form templates. It supports single tag
and multi tags. The source of the displayed tags has to be a tag_group
name.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
This commit adds a `:sidekiq_job_error` event which is
triggered when an error is encountered while running a Sidekiq job. The
intent of this change is to complement the `:sidekq_job_ran` event which
can be used with the `:sidekiq_job_error` event to calculate the error
rate for each job.
Allow admins to edit user custom flags. Because changing
name/description will update name/description for old reviewables,
warning has to be displayed.
Still, system flags can never be edited or deleted (only disabled).
Building the Discourse JS app is very resource-intensive. This commit
introduces an `assemble_ember_build` script which will check the
existing content of the `dist/` directory and re-use the core build if
possible. Plugins will always be rebuilt.
For now, this functionality is only useful for multi-stage (i.e.
non-standard) Discourse deployments. But in future, this script may be
extended to pull the contents of the `dist/` directory from a remote
location.
