Previously, we were using multiple threads to run migrations for
multisite setups in parallel. However, it was discovered that
`db:migrate` is
not threadsafe and was not designed to be. As a result,
`multisite:migrate` was hardcoded to only support spinning up a single
thread.
This new attempt Uses the `parallel` gem with `in_processes` to run
migrations concurrently using multiple processes. Concurrency defaults
to 2 but can be configured via the
`DISCOURSE_MULTISITE_MIGRATE_CONCURRENCY` env. Example:
`DISCOURSE_MULTISITE_MIGRATE_CONCURRENCY=5 bin/rails multisite:migrate`
This commit introduces a new build system for plugins, which shares a
large amount of code with the recently-modernized theme compiler.
Plugins are compiled to native ES Modules, and loaded using native
`import()` in the browser, just like themes.
To achieve inter-plugin imports, each bundled plugin entrypoint
implements a custom 'module federation' interface. Each export from
internal plugin modules is made available as a specially-named export on
the entrypoint. When modules in another plugin's namespace are imported,
they are automatically rewritten to use these federated entrypoints.
This change should be almost 100% backwards-compatible. There are some
edge cases which will behave differently, since modules are now eagerly
evaluated according to the ESM spec, instead of being lazily required
via asynchronous-module-definitions (AMD).
The native ESM format should also provide a performance improvement. The
old AMD system involved lots of nested function calls when booting the
app. Now, all the source modules are bundled up into a single ESM bundle
with minimal stack depth.
The build system implements a filesystem-based cache. That means that if
the plugin javascript files are unchanged, they will not need to be
recompiled, even after restarting the Rails server. This mimics the
behaviour of the theme system. Similarly, in production builds, existing
files will be automatically reused if they exist. In future, we plan to
include pre-built copies of common plugins in our prebuild-asset
bundles.
Initially, this new compiler is disabled by default. To test it, we can
set the `ROLLUP_PLUGIN_COMPILER=1` environment variable. We'll continue
to test, improve and document the system before enabling it by default.
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
Co-authored-by: Chris Manson <chris@manson.ie>
When security fixes are staged for the main branch via the
`stage_security_fixes` task, the development version is now
automatically incremented (e.g. `2026.2.0-latest` to
`2026.2.0-latest.1`). This ensures each security fix batch gets its own
tagged version, allowing docker_manager to detect that installations on
`latest` need a critical update.
To support this, a new `ReleaseUtils::Version` value object encapsulates
version parsing, comparison, and manipulation logic that was previously
done through ad-hoc string splitting and `Gem::Version` comparisons in
release.rake. It understands Discourse's versioning scheme
(major.minor.patch-pre.revision) and provides methods like
`#next_revision`, `#same_development_cycle?`, and
`#next_development_cycle`.
All existing rake tasks have been refactored to use `Version` objects,
the unused `parse_current_version` helper and
`prepare_next_version_branch` task have been removed, and the release
specs have been rewritten following RSpec style guide conventions.
Previously, the asset-processor javascript was only cached in
production. In development, it would be built on-demand using esbuild
every time it was needed. Originally this was incredibly fast. But over
the years complexity has increased, and it now takes more than a second,
even on fast hardware.
This commit adds some caching logic, keyed on the filenames/content of
all known input files. In production, this will make things slightly
more efficient because the cache will be re-used if an up-to-date
version already exists. In development, it will be much more efficient,
because `esbuild` will only be invoked when changes are made to the
asset process source code.
A file-based lock is used to ensure multiple processes do not fight with
each other to generate the processor simultaneously.
We have a "Staff" option for upcoming change items that was sending
the `staff` group name to the server. I had assumed that our automatic
groups could not be renamed, but this is not the case. If your
`default_locale` for your site is changed, the automatic group names
change via `Group.refresh_automatic_groups!` in a background job.
This means that if you change your `default_locale` to `de` (German),
the `staff` group becomes `Team`, and the upcoming changes that are set
to "Staff" will now be looking for the `staff` group, which no longer
exists, causing errors.
This commit fixes the issue by always using the localized staff
automatic group name, both for the value of the dropdown, and in
successs messsages etc.
c.f.
https://meta.discourse.org/t/issue-with-enabling-upcoming-changes/395881/16
---------
Co-authored-by: Régis Hanol <regis@hanol.fr>
## Summary
- Instance-scoped temp paths so multiple instances don't clobber each other's data directory
- Extend binary discovery to cover RHEL/Fedora paths, widen version range to 10..30, and simplify path resolution
- Replace backtick calls with `Open3.capture3` so failures in `initdb`, `pg_ctl`, `createuser`, and `createdb` raise with descriptive messages instead of being silently swallowed
- Use `pg_ctl -w` (wait mode) instead of a sleep-poll loop with no timeout for server startup
- Save and restore `DISCOURSE_PG_PORT` so the env isn't left pointing at a dead server on failure
- Add explicit requires for `open3`, `securerandom`, and `tmpdir`
- Wrap `db:validate_indexes` in `begin/ensure` so the temporary database is always cleaned up on failure
These changes are needed for migrations-tooling (schema generation runs `TemporaryDb` during CI) and are a general reliability improvement for all existing callers.
`BaseStore#download` and `download!` previously returned open `File`
objects via `get_from_cache` (which called `File.open`). Nearly all
callers (14 of 16) only needed the `.path` and never closed the handle,
leaking file descriptors. Under load this can exhaust FDs and crash
with `Errno::EMFILE`.
This commit changes `download` and `download!` to return file path
strings instead of `File` objects. Since the cached file at
`tmp/download_cache/` persists on disk, callers that need to read
content can simply use `File.read(path)`.
The public API is simplified to two methods:
- `download`: safe, rescues all errors and returns `nil` (absorbs
the former `download_safe` behavior)
- `download!`: raises `DownloadError` on failure
A deprecated `download_safe` alias is kept for plugin compatibility.
The block/yield pattern is removed entirely since it's no longer needed.
There are no file handles to manage. All call sites are updated to
use the path directly, dropping `{ |f| f.path }` blocks. The two
callers that actually read file content are updated:
- `static_controller.rb` → `File.read(path)`
- `digest_rag_upload.rb` → `File.open(path)` (streams content)
Automatic group names (everyone, staff, admins, etc.) are translated
based on the site's default locale. However, the `AUTO_GROUPS` JS
constant had hardcoded English names which were used directly in several
places — most notably during category creation. This caused the
"everyone" group to always display its English name in the permissions
table, even on sites with a different default locale.
This removes the `name` and `display_name` fields from `AUTO_GROUPS`,
keeping only `id` and `automatic`. A new `groupsById` getter on the
`Site` model provides a lookup map built from server-provided group data
(which contains the properly localized names). All consumers now resolve
group names via `site.groupsById[groupId].name` instead of reading from
the constant.
The avatar-flair system is also refactored from name-based to ID-based
lookups, and group identity checks in `user.js` now compare by `id`
rather than `name`.
https://meta.discourse.org/t/395225
The `maxmind_thread` variable was declared but never referenced in the
task file. Removing it cleans up dead code, reduces confusion, and
aligns with linting rules that flag unused variables.
- Moves it from `version_bump.rake` to the new `release.rake`. This is
the last thing which was pending upgrade, so we can now delete the whole
`version_bump.rake` file & spec
- Adds support for release/* branches
- Adds an interactive prompt to choose which security PRs to include
- Creates & merges the PR using `gh` CLI. Less manual work.
"Backuper" is a spelling error. When adding "-er" to a word ending in a
consonant after a short vowel, the consonant is doubled: up → upper,
run → runner, backup → backupper.
Rather than "Backupper" (awkward), rename to "Creator" which:
- Is a real word
- Provides symmetry with BackupRestore::Restorer
- Matches naming patterns elsewhere (HostedSiteCreator, etc.)
BackupRestore::Backuper → BackupRestore::Creator
Also introduces a `versions.json` file which will be the source-of-truth
for versioning information for core automation, and for external systems
like `releases.discourse.org`.
We originally intended to format our new calendar-based version numbers
with leading zeros in the 'minor' (/month) segment. However, leading
zeros are actually invalid semver, and these version numbers will fail
to parse in some version-number libraries (e.g. npm's `semver` lib).
This commit switches the currently-in-development version from `2026.01`
to `2026.1`. No released versions are affected, because they were `.11`
and `.12`.
Allows admins and moderators to see users' upcoming changes
and the reason the user has that change enabled, or not enabled. It is
added to the existing page at `/admin/users/:id/:username`
It could either be because the change is enabled for Everyone, or
only for specific groups:
We give a shortcut link to each group so the admin can inspect it.
Previously, the `release`, `beta`, and `latest-release` tags were only
updated when a new version tag was created. This meant the tags could
fall behind the actual release branch HEAD.
Now these tags track the latest commit on release branches:
- New `release:update_release_tags` task updates tags when the commit's
version is >= the latest existing release (excluding prereleases)
- Renamed `release-prepare-bump.yml` to `release-branch-handler.yml` and
triggers on all pushes to release/* branches
- Separated release/* handling from main branch workflow
https://meta.discourse.org/t/383536/46
These were handled manually in the last release. `latest-release` and
`beta` should be exact synonyms of `release`, for backwards
compatibility.
https://meta.discourse.org/t/383536/47
This is a continuation of
https://github.com/discourse/discourse/pull/36885.
The rake task here backfills `topic_localization.excerpt` which may have
been empty (both `nil` and `""` are valid as checked on meta).
The reason why this can't be a migration is because we use
`Post.excerpt` which taps on a method in the post model which also uses
`PrettyText`.
When moderators (with `moderators_manage_groups` enabled) change a
group's visibility or members visibility to "Owners only" while not
being an owner themselves, they would permanently lose access to manage
that group. Similarly, removing themselves as owner when visibility is
set to "Owners only" would lock them out.
This adds confirmation dialogs warning moderators before:
- Changing group visibility to "Owners only"
- Changing members visibility to "Owners only"
- Removing themselves as owner when visibility is restrictive
- Removing themselves as member when they're also an owner
Also refactors the category lockout code from PR #36663 to use
async/await for consistency.
Ref: https://meta.discourse.org/t/391403
This PR implements stricter deprecation handling that enforces
deprecation-free tests for core and preinstalled plugins, while allowing
custom (non-preinstalled) plugins and themes to have deprecations
without causing test failures.
### Key Changes
#### CI Workflow Improvements
- Split plugin system tests into separate CI targets: `core-plugins`,
`official-plugins`, and `chat`
- Enhance `bin/turbo_rspec` to accept comma-separated exclude patterns
via `--exclude-pattern`
- Simplify workflow configuration with default `shell: bash` and
consolidated environment variables
#### Plugin Classification & Detection
- Centralize official plugins list in `config/official_plugins.json` for
unified backend and frontend access
- Detect preinstalled plugins by checking for absence of `.git`
directory
- Add `isOfficial` and `isPreinstalled` metadata flags to plugin info
- Add `data-preinstalled` and `data-official` attributes to all plugin
and theme script tags for runtime identification
#### Deprecation Source Tracking
- Track deprecation sources (core, plugin, or theme) through template
map and resolver to attribute deprecations correctly
- Improve `source-identifier.js` to detect admin UI plugin files in both
development and production environments
- Add source information to deprecation messages for better debugging
#### Test Infrastructure
- Modify `raise-on-deprecation` test helper to skip errors for custom
(non-preinstalled) plugins and themes
- Add `EMBER_RAISE_ON_DEPRECATION` environment variable to control
deprecation throwing behavior in Rails tests
- Automatically set `EMBER_RAISE_ON_DEPRECATION` for core and
preinstalled plugin/theme specs in `rails_helper.rb`
- Improve deprecation summary output for system specs with test/spec
origin tracking
#### Deprecation Workflow Enhancements
- Add `dont-throw` handler for selective deprecation bypassing in test
fixtures without raising errors
- Add `dont-count` handler for preventing deprecation counting in
specific scenarios (e.g., test fixtures)
#### Deprecation Fixes
- Fix pending deprecations across core plugins (chat, data-explorer,
discourse-subscriptions, gamification, house-ads, reactions,
rss-polling, styleguide)
- Update import paths and remove deprecated patterns
- Migrate deprecated Handlebars templates to JavaScript API
### Testing Strategy
With these changes:
- **Core and preinstalled plugins** must pass all tests without any
deprecations
- **Custom plugins and themes** can have deprecations without failing
tests
- Test fixtures can use `dont-throw` and `dont-count` handlers when
testing deprecation behavior itself
- System specs automatically configure deprecation enforcement based on
test file location
---------
Co-authored-by: David Taylor <david@taylorhq.com>
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
Implements date-based versioning, based on the RFC at
https://meta.discourse.org/t/383536
Manual version-bump tasks are removed, and replaced with new `release:*`
rake tasks. These are run in GitHub actions. Release process will work
something like:
1. Trigger `release-prepare-latest-bump` via workflow_dispatch. This
will create a PR which bumps the in-development version to the next
`-latest`
2. Merge that PR
3. `release-handler` will be triggered automatically, tag the commit
with `v0000.00.0-latest`, and cut a `release/xxxx.xx` branch from the
previous commit
4. `release-prepare-bump` will be triggered automatically, and create a
PR which bumps the version on `release/xxxx.xx` branch to remove the
`-latest` suffix
5. Merge that PR
6. `release-handler` will be triggered automatically, and will tag the
commit with `v0000.00.0`
In future, we will add handling for ESR, and new workflows for security
fixes.
After running migration scripts on multiple sites the following
improvements were added:
* avoid conflicting `background_image` and `background_image_light`
settings migration
* run db query once for `migrate_all` task
* match theme url with and without `.git` suffix
* abort the migration if more than one theme is installed
and code related:
* improve logging for cleaner output
* remove logging duplicates
* rename methods and vars to be more self-explanatory
* simplify logic for a clearer execution
Several sites still use outdated setting for `background_image` instead
of `background_image_light`.
Unsupported settings were silenced, which made me guessing what exactly
was not migrated?
### Changes
- include outdated `background_image` setting
- log explicitly setting name and value, which cannot be migrated,
because core welcome banner doesn't support it
|Before|After|
|---|---|
|<img width="704" height="206" alt="unsupported setting missing"
src="https://github.com/user-attachments/assets/0553c2f8-b51d-4bea-a10a-413a77289d5d"
/>|<img width="786" height="256" alt="explicit log and background_image
support"
src="https://github.com/user-attachments/assets/334cb45e-aa5f-4cba-ac2c-29edd25b70b4"
/>|
Prefixes numbers to `themes:advanced_search_banner` rake task names to
clarify their intended execution order:
* `migrate_settings_to_welcome_banner` =>
`1_migrate_settings_to_welcome_banner`
* `migrate_translations_to_welcome_banner` =>
`2_migrate_translations_to_welcome_banner`
* `exclude_and_disable` => `3_exclude_and_disable`
Also adds a combined rake task
`themes:advanced_search_banner:migrate_all` to run all three
sequentially. The output will look like this:
<img width="814" height="517" alt="migrate_all console output"
src="https://github.com/user-attachments/assets/5452c038-7d5f-4ae3-a1d0-3b40bf2cb4e6"
/>
The previous code did not include enough useful information that would enable
the user to make a report asking for assistance. We now include the actual
error class and message in the output.
Formatting of the actual output blocks now resizes to the user's terminal width
and is centrally handled.
Reworded the error messages for consistency and to offer additional advice.
Each of these scenarios outlined in the commit was tested using a corresponding
local setup to generate that error.
Prevents unexpected SSH/GPG agent invocation when running version bump
rake task tests locally by disabling GPG signing for git operations in
test mode.
Restoring a backup executes DB migrations after the DB is restored. Part of those migrations is a step for seeding content. That step might create uploads which depends on site settings. This change excludes the seeding from the DB migrations and runs it after site settings have been restored and reloaded.
Follow up PR to #34534 and #35699.
This fix adds a check if a site setting was not found. Allows to avoid
the following error:
```bash
rake aborted!
NoMethodError: undefined method `value' for nil (NoMethodError)
if site_setting.value == "f"
^^^^^^
/var/www/discourse/lib/tasks/migrate_advanced_search_banner_to_welcome_banner.rake:306:in `block in enable_welcome_banner'
```
Follow up of #34534.
Fixes the following issues identified during test runs:
1. Welcome banner theme site setting change should propagate properly
via `Themes::ThemeSiteSettingManager.call` instead of plain
`site_setting.update!`
2. Ensure the proper order for `process_theme_component(theme)` steps:
`enable_welcome_banner` should execute before `exclude_theme_component`,
otherwise it would never be run due to check `return if
not_included_in_any_theme?(theme)`
3. Reset `theme.parent_theme_ids = []` instead of excluding component per theme.
1. Changes translation to a more meaningful: `welcome_banner.search` =>
`welcome_banner.search_placeholder`.
* and passes along translation key, rather then `i18n` helper in
`<SearchMenu>` - to make translation handling more consistent
2. Transitions communities from the **Advanced Search Banner** (ASB)
theme component to the **core welcome banner** (CWB). It handles the
transition in three major steps:
* migrates site settings: task
"themes:advanced_search_banner:migrate_settings_to_welcome_banner"
* migrates translations: task
"themes:advanced_search_banner:migrate_translations_to_welcome_banner"
* excludes ASB from themes using it, enables CWB, disables ASB: task
"themes:advanced_search_banner:exclude_and_disable"
### Settings migration
1. Happy path
<img width="1029" height="192" alt="Screenshot 2025-10-29 at 12 40 51"
src="https://github.com/user-attachments/assets/5d29ef48-ce60-4222-b32a-217390967b8d"
/>
### Translations migration
1. Migrates overridden and default texts
<img width="1062" height="291" alt="Screenshot 2025-10-29 at 12 44 26"
src="https://github.com/user-attachments/assets/c43d51a4-59f8-4751-8abb-ae8824a7100f"
/>
### Exclude ASB, enable CWB, disable ASB
2. When ASB is not included in any of themes, all migrations are
skipped, except for disabling ASB
<img width="807" height="458" alt="Screenshot 2025-10-30 at 11 48 43"
src="https://github.com/user-attachments/assets/34e7bd5f-b334-4833-89a1-00d02faac23b"
/>
When Chrome isn't installed, running "bin/rails qunit:test" would fail
because it wouldn't be able to detect that Chromium was installed.
This fixed that and also pass the detected browser to testem
This task was failing to load rspec-core because `lib/tasks` are loaded
in full in prod environments and this was meant to be run only in
dev/test environments (the task it is overwriting is defined in a gem
that's only loaded in those environments).
If we add more tasks like this, we can create a new subfolder in `tasks`
to segregate such tasks in a clearer manner.
This creates an overriding `rswag:specs:swaggerize` rake task that also
adds plugin paths, and updates spec helpers to handle plugin paths.
Also adds the spec files for the discourse-calendar events index
endpoint.
### Testing
Running `rake rswag:specs:swaggerize` now generates the same
`openapi/openapi.yaml` file, with `/discourse-post-event/events.ics` and
`/discourse-post-event/events.json` GET documentation.
Description
When trying to fix migration issues for wrongly ordered posts by running
rake posts:reorder_posts, you may encounter errors like:
```
PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "post_timings_unique"
```
This happens if there are PostTiming records without a corresponding
Post. Currently, the code does not handle these records, and when
updating records to the new order, some values may collide, causing the
error.
Alan Guo Xiang Tan
Jarek Radosz
Loïc Guitaut
Martin BrennanandRégis Hanol
Gerhard Schlager
Sam
Jake Goldsborough
Natalie Tay
Yuriy Kurant
Michael Brown
Rafael dos Santos Silva
Kelv
Juan David Martínez Cubillos