- Ruby 58.5%
- JavaScript 35.5%
- HTML 3.1%
- SCSS 2.8%
d925a0da13
This is for small migrations where running the separate `disco upload` step first is more hassle than it's worth. Until now `disco import`'s uploads step just skipped when no files.db was configured. Now, when there's no files.db, it uploads the source files itself, straight into the live target site, using the exact same upload-creation code that `disco upload` uses. To share that code without duplicating it, I pulled the upload creation out of `Tasks::Uploader` into a few plain collaborators under `uploads/`: - `SourceFileLocator` — finds a file under the configured root_paths (with path_replacements), or writes a tempfile from an inline data blob. - `FileDownloader` — the URL download, cache dir, and #33546 error taxonomy. The original-filename store is injected: files.db-backed in `disco upload`, a plain in-memory Hash inline. Either way the cache dir works the same. - `UploadCreationService` — the seam. Given one `upload_sources` row it locates or downloads the bytes, runs core's `UploadCreator`, checks the file actually reached the store, retries the few things worth retrying, and returns a frozen result. No queues, no DB writes — each caller persists its own way. `Tasks::Uploader` is now a thin consumer of that service; its written rows and behavior don't change, so the existing uploader and pipeline specs still pass unchanged. For inline mode the results land in the mappings DB instead of files.db: `mapped.ids` (type UPLOADS) for id resolution, and a new `mapped.upload_markdown` table (migration 003) for the rendered reference. That gives the posts placeholder resolver one uniform read path — `files.upload_results.markdown` when files.db is attached, else `mapped.upload_markdown`. I only create and populate the table here; the maps object on the in-progress posts branch reads it, so that side needs to land the read path. On ownership: `disco upload` uploads everything as the system user and the copy step reassigns the real user afterwards. Inline mode has no later copy step, so I resolve the mapped importer user (system user as a fallback) up front and pass it to `create_for`, so the upload is owned correctly at creation time. Keeping `user_id` a plain argument to the service is what lets both paths share it. Image processing is CPU-heavy, so inline mode reuses the existing `Pipeline` (with the adaptive worker gate) rather than a sequential loop. The catch is that the step's IntermediateDB connection (with `mapped` attached) isn't thread-safe. So I materialize the whole pending work list into memory on the step thread first, then start the pipeline where only its single writer thread touches that connection — the step thread just waits for `pipeline.run` to return. This assumes the work list fits in memory, which is fine because inline mode is for small migrations (documented at the call site). Settings: `disco import` runs on the live target site, whose upload settings (extensions, size limits, S3 credentials) are already real, so inline mode leaves them alone. The one thing it does set is `clean_up_uploads = false`, otherwise the cleanup job would sweep these freshly created uploads before the later post steps attach them. Inline mode needs `root_paths` (plus optional `path_replacements` and `download_cache_path`), which go in a new `uploads:` section under `config:` in importer.yml. If there are uploads to import and neither a files.db nor that section is set, the run stops with a message telling you to configure one or the other. `Steps::OptimizedImages` stays a no-op without a files.db (a rebake regenerates them) — PR 8's skip already covers that, no change needed. |
||
|---|---|---|
| .agents | ||
| .claude | ||
| .cursor/rules | ||
| .devcontainer | ||
| .github | ||
| .skills | ||
| .vscode | ||
| .zed | ||
| app | ||
| bin | ||
| config | ||
| db | ||
| docs | ||
| frontend | ||
| images | ||
| lib | ||
| log | ||
| migrations | ||
| patches | ||
| plugins | ||
| public | ||
| script | ||
| spec | ||
| stylelint-rules | ||
| test | ||
| themes | ||
| vendor | ||
| .annotaterb.yml | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .ignore | ||
| .jsdoc | ||
| .licensed.yml | ||
| .licensee.json | ||
| .npmrc | ||
| .pnpmfile.cjs | ||
| .prettierignore | ||
| .prettierrc.cjs | ||
| .rspec | ||
| .rspec_parallel | ||
| .rubocop.yml | ||
| .ruby-gemset.sample | ||
| .streerc | ||
| AGENTS.md | ||
| AI-AGENTS.md | ||
| Brewfile | ||
| CLAUDE.md | ||
| CODEOWNERS | ||
| config.ru | ||
| CONTRIBUTING.md | ||
| COPYRIGHT.md | ||
| d | ||
| discourse.sublime-project | ||
| eslint.config.mjs | ||
| Gemfile | ||
| Gemfile.lock | ||
| GEMINI.md | ||
| lefthook.yml | ||
| LICENSE.txt | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| Rakefile | ||
| README.md | ||
| stylelint.config.mjs | ||
| translator.yml | ||
| tsconfig-base.json | ||
| tsconfig.json | ||
| versions.json | ||
The online home for your community.
You can self-host Discourse on your own infrastructure. But if you'd rather skip the setup, maintenance, and server management, we offer official Discourse hosting.
👉 Learn more about Discourse hosting
Discourse is a 100% open-source community platform for those who want complete control over how and where their site is run.
Our platform has been battle-tested for over a decade and continues to evolve to meet users’ needs for a powerful community platform.
With Discourse, you can:
-
💬 Create discussion topics to foster meaningful conversations.
-
⚡️ Connect in real-time with built-in chat.
-
🎨 Customize your experience with an ever-growing selection of official and community themes.
-
🤖 Enhance your community with plugins, from chatbots powered by Discourse AI to advanced tools like SQL analysis with the Data Explorer plugin.
To learn more, visit discourse.org and join our support community at meta.discourse.org.
Here are just a few of the incredible communities using Discourse:
👉 Discover more communities using Discourse
Development
To get your environment set up, follow one of the setup guides:
- Docker
- Dev Container in VS Code (recommended)
- CLI
- macOS
- Ubuntu/Debian
- Windows
Before you get started, ensure you have the following minimum versions: Ruby 3.4+, PostgreSQL 15, Redis 7.
For more information, check out the Developer Documentation.
Setting up Discourse
If you want to set up a Discourse forum for production use, see our Discourse Install Guide.
If you're looking for official hosting, see discourse.org/pricing.
Requirements
Discourse supports the latest, stable releases of all major browsers and platforms:
| Browsers | Tablets | Phones |
|---|---|---|
| Apple Safari | iPadOS | iOS |
| Google Chrome | Android | Android |
| Microsoft Edge | ||
| Mozilla Firefox |
Additionally, we aim to support Safari on iOS 16.4+.
Built With
- Ruby on Rails — Our back end API is a Rails app. It responds to requests RESTfully in JSON.
- Ember.js — Our front end is an Ember.js app that communicates with the Rails API.
- PostgreSQL — Our main data store is in Postgres.
- Redis — We use Redis as a cache and for transient data.
- BrowserStack — We use BrowserStack to test on real devices and browsers.
Plus lots of Ruby Gems, a complete list of which is at /main/Gemfile.
Contributing
Discourse is 100% free and open source. We encourage and support an active, healthy community that accepts contributions from the public – including you!
Before contributing to Discourse:
- Please read the complete mission statements on discourse.org. Yes we actually believe this stuff; you should too.
- Read and sign the Electronic Discourse Forums Contribution License Agreement.
- Dig into CONTRIBUTING.MD, which covers submitting bugs, requesting new features, preparing your code for a pull request, etc.
- Always strive to collaborate with mutual respect.
- Not sure what to work on? We've got some ideas.
We look forward to seeing your pull requests!
Security
We take security very seriously at Discourse; all our code is 100% open source and peer reviewed. Please read our security guide for an overview of security measures in Discourse, or if you wish to report a security issue.
Security fixes are listed in the release notes for each version.
The Discourse Team
The original Discourse code contributors can be found in AUTHORS.MD. For a complete list of the many individuals that contributed to the design and implementation of Discourse, please refer to the official Discourse blog and GitHub's list of contributors.
Copyright / License
Copyright 2014 - 2025 Civilized Discourse Construction Kit, Inc.
Licensed under the GNU General Public License Version 2.0 (or later); you may not use this work except in compliance with the License. You may obtain a copy of the License in the LICENSE file, or at:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Discourse logo and “Discourse Forum” ®, Civilized Discourse Construction Kit, Inc.
Accessibility
To guide our ongoing effort to build accessible software we follow the W3C’s Web Content Accessibility Guidelines (WCAG). If you'd like to report an accessibility issue that makes it difficult for you to use Discourse, email accessibility@discourse.org. For more information visit discourse.org/accessibility.
Dedication
Discourse is built with love, Internet style.
For over a decade, our amazing community has helped shape Discourse into what it is today. Your support, feedback, and contributions have been invaluable in making Discourse a powerful and versatile platform.
We’re deeply grateful for every feature request, bug report, and discussion that has driven Discourse forward. Thank you for being a part of this journey—we couldn’t have done it without you!
