This PR extends the current setting
`content_localization_anonymous_language_switcher` to one that can be
shown even for logged in users ->
`content_localization_language_switcher`
When logged in, the preference is saved to the `user` rather than a
cookie. 🍪https://github.com/user-attachments/assets/b6f4d41b-4716-4020-a97d-2c3f90d54576
We're not going to finish/release dual-mode palettes and theme-owned
palettes at this time, so we're cleaning up the code that we've already
merged for these features.
Internal topic: t/161279.
The current impersonation feature works by signing you in as the user you are impersonating. This has the side effect of invalidating your own session and forcing you to log out and in again.
In this experimental implementation you keep your existing session, but DefaultCurrentUserProvider returns the user being impersonated, allowing you to see the site from their perspective.
The change is sponsored by `Rails/AddColumnIndex` rubocop rule:
> (…) add_column does not accept index, but also does not raise an error
for extra keys, so it is possible to mistakenly add the key without
realizing it will not actually add an index.
I opted not to add these "missing" indexes since they've proven not
necessary after all.
In #33558 we removed automatic_backups_enabled setting, and instead rely on backup_frequency being blank to disable.
There was a big oversight there with the site setting type system, which will coerce the value to an integer. It also makes it so you can't blank the value out in the UI.
This is a "fix forward" solution where instead of "set to blank to disable" we do "set to 0 to disable". This works along the grain of the site setting type system for a workable fix where we don't have to deal with the irreversible migration in the previous change.
We can potentially go and add in "nullable" to the type system at a later point.
We're removing the automatic_backups_enabled toggle and depending solely on the backup_frequency value. This PR replaces the setting and adds a migration for any forum that has automatic_backups_enabled disabled.
This commit responds to feedback in the Discourse Meta discussion
https://meta.discourse.org/t/monospace-font-in-the-markdown-only-editor/359936
This change introduces a user preference that allows users to choose
whether the Markdown editor uses a monospace font. The default setting
is `true` for new sites, but set to `false` for existing sites to avoid
disrupting current users' experiences.
Admins can change the `default_other_enable_markdown_monospace_font`
site setting to manage this for all users.
This commit adds a new dropdown preference to set the default color mode for
the user and change the color mode for the current device. It works the same way
as the interface color selector in the sidebar footer (or header), but it also allows
setting the default mode for the user that gets used when the user logs in on a
new device. It remains possible to set a color mode per device using the
sidebar/header selector or this new preference.
Internal topic: t/159358.
We believe the rich editor is a great experience for the
vast majority of sites and users, so we are enabling it
for all sites and all users by default.
This commit does the following:
* Hides the rich_editor site setting and sets it to true by default.
It can still be overridden by sites that want to disable it
completely.
* Sets `rich_editor` to true for all sites to enable the rich editor
everywhere.
* Adds a new `default_composition_mode` site setting and corresponding
user option that defaults to Rich for all users. The other option is
Markdown.
* Changes the rich editor toggle in the composer to use the new
database-backed user option (`composition_mode`) instead of a local
storage key/value store. This makes the preference persistent
across devices.
Existing key/value store settings for the markdown toggle are
kept, the preference will be saved to the user option automatically.
When enabled this will convert uploaded videos to a standard format that should
be playable on all devices and browsers.
The goal of this feature is to prevent codec playback issues that
sometimes can occur with video uploads.
It uses an adapter pattern, so that other services for video conversion
could be easily added in the future.
Previously, all script tags in a theme field would be combined into a
single `.js` bundle along with the `text/discourse-plugin` modules. This
led to some unexpected run order, and also makes it hard to implement
the `type=module` change being developed in #33103.
This commit refactors things so that each raw script gets extracted into
its own `.js` bundle, which is then placed in exactly the same place in
the HTML.
This commit introduces the concept of themeable site settings,
which is a new tool for theme authors that lives alongside theme
modifiers and theme settings. Here is a quick summary:
* Theme settings - These are custom settings used to control UI and functionality within your theme or component and provide configuration options. These cannot change core Discourse functionality.
* Theme modifiers - Allows a theme or a component to modify selected server-side functionality of core Discourse as an alternative to building a plugin.
* Themeable site settings (new) - Allows a theme (not components) to override a small subset of core site settings, which generally control parts of the UI and other minor functionality. This allows themes to have a greater control over the full site experience.
Themeable site settings will be shown for all themes, whether the theme
changes
the value or not, and have a similar UI to custom theme settings.
We are also introducing a new page at
`/admin/config/theme-site-settings` that
allows admins to see all possible themeable site settings, and which
themes
are changing the value from the default.
### Configuration
Theme authors can configure initial values themeable site settings using
a section in the `about.json` file like so:
```json
"theme_site_settings": {
"search_experience": "search_field"
}
```
These values will not change when the theme updates, because we cannot
know if admins have manually changed them.
### Limitations
Themeable site settings are only really intended to control elements of
the UI, and when retrieving their value we require a theme ID, so these
limitations apply:
- Themeable site settings cannot be used in Sidekiq jobs
- Themeable site settings cannot be used in markdown rules
- Themeable site settings will be cached separately to client site
settings using theme ID as a key
- Themeable site settings will override keys on the `siteSettings`
service on the client using the application preloader
- `SiteSetting.client_settings_json` will not include themeable site
settings, instead you can call `SiteSetting.theme_site_settings_json`
with a theme ID
### Initial settings
There are only two site settings that will be themeable to begin with:
* `enable_welcome_banner`
* `search_experience`
And our new Horizon theme will take advantage of both. Over time, more
settings that control elements of the UI will be exposed this way.
- Add indexes in some places where we were seeing bottlenecks
- Remove redundant ILIKE query
---------
Co-authored-by: Gerhard Schlager <gerhard.schlager@discourse.org>
We want to add the ability to enable/disable users selecting Gravatar for their avatar.
This change adds a site setting to enable/disable the option (default to enabled.) This will prevent users from configuring Gravatars from that point on. It does not affect already configured avatars.
We're also taking this chance to hide some of the advanced settings from the UI.
* Fixes capitalisation for *My messages*, *My posts*, and *My drafts*
sidebar links.
* Hides *My messages* link for anonymous users.
* Hides *My messages* link for users who can’t access messages.
* Adds active state for *My messages* link (applies to all child routes:
personal, group, and tags).
Post edits need to inform the backend if the locale is changed and is
sometimes set as `""`. This PR prevents the locale from being set to
`""` in the database, and includes a migration to purge the empty
strings.
We want to deprecate the enabled/disabled toggle for this setting and rely entirely on the presence of a URL.
This change:
- Deprecates and hides the enabled/disabled setting.
- Updates all code paths and tests that rely on the old setting.
- Adds a migration that clears the URL if the enabled/disabled setting is set to false.
`SiteSerializer#post_action_types` and `SiteSerializer#topic_flag_types`
both call the `Flag.used_flag_ids` method which executes queries that
becomes very slow on sites with alot of records in either the
`post_actions` or `reviewable_scores` table.
On the `post_actions` table, we execute `SELECT DISTINCT
post_action_type_id FROM post_actions`. On the `reviewable_scores`
table, we execute `SELECT DISTINCT reviewable_scope_type FROM
reviewable_scopes`. The problem with both queries is that it requires
the PG planner to scan through every single row in those tables.
For our use case, all we actually need is to check if a flag is being
referenced by a record in either the `post_actions` or
`reviewable_scores` tables. This commit updates the `Flag.used_flag_ids`
to accept a `flag_ids`
argument and use the argument to check whether the flag ids are
referenced in the `post_action_type_id` or `reviewable_scope_type`
foreign keys.
This PR takes the localization features out of "experimental" to prep
for the announcement
- rename settings and gives them its own area
- `experimental_content_localization` to `content_localization_enabled`
- `experimental_content_localization_allowed_groups` to
`content_localization_allowed_groups`
- `experimental_content_localization_supported_locales` to
`content_localization_supported_locales`
- `experimental_anon_language_switcher` to
`content_localization_anon_language_switcher`
- migration
- related to https://github.com/discourse/discourse-ai/pull/1439
| screenshot 📸 |
|---|
| <img width="964" alt="Screenshot 2025-06-17 at 5 06 32 PM"
src="https://github.com/user-attachments/assets/9a8b2c38-c846-4fc9-8ddd-815c45cc3d0e"
/> |
Introduction of system themes. System themes are local themes which:
- Cannot be deleted;
- Cannot have “custom code” added, components only;
- Cannot have uploads;
- Cannot edit color palettes;
- Are updated on deploy, like core plugins.
This PR added the Foundation system theme, which is an empty theme like
Default. The Foundation theme will be added in the next PR.
In a development environment, when system theme files are
changed/added/deleted, the theme is reuploaded and the page is reloaded
to make it a good experience for the engineer working on improvements.
System themes are not visible until
`SiteSetting.experimental_system_theme` is enabled.
In #33012 we phased out the site settings for:
- disable_avatar_education_message
- sequential_replies_threshold
- warn_reviving_old_topic_age
This change is a follow up migration to delete the site settings from
the database.
We phased out the site setting for `max_similar_results` in #32934 -
this change is a follow up migration to delete the site setting from the
database.
As part of the review queue refresh, we'll be adding the ability for moderators to make notes on individual reviewable items. As a first step, this change adds the new model and associated backend code.
Application code should not be used in migrations since we want
migrations to be idempotent. Since these migrations were added 4 years
ago, the application code is safe to be removed.
This will allow me to make changes to the
`FileStore::S3Store#update_upload_ACL` without having to worry about
these migrations.
Previously we had omitted determining the locale of categories, as
unlike posts, categories are usually single words and are usually only
translated once.
Since there is no locale, a category called "Staff" would also have an
English translation. With LLMs that perform poorly, we see that
translating "Staff" to English may result in something entirely
different (like "Personnelle" or "Personal").
Thus adding locale support to categories can mitigate this issue due to
the uncertainty.