- 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.
Follow on from https://github.com/discourse/discourse/pull/32285:
This replaces the use of the scrolling-based load-more mixin in
DiscoveryTopicsList with the IntersectionObserver-based LoadMore
component.
I insert the LoadMore component in the parent template for more precise
control over where the sentinel element is placed - right after the List
collection.
Also lifted up the `loadMore` action to the topics glimmer component so
it can be passed directly into LoadMore, and refactored away the jquery
dependency.
This is a breaking change to the behaviour of DiscoveryTopicsList, so
it'll require updates to any other repositories depending on this
component.
This commit introduces various enhancements and refactoring to the
Glimmer Post Stream codebase, focusing on the integration and usage of
`PluginOutlet` components, improved handling of post attributes, and the
introduction of new properties and methods. Key changes include:
1. **`PluginOutlet` Integration**:
- Added `PluginOutlet` components across multiple files, such as
`post.gjs`, `post/avatar.gjs`, and `post-stream.js`, to allow plugins to
extend the functionality of posts, avatars, and metadata more
effectively.
- Introduced `postOutletArgs` to pass structured arguments, enabling
better customization and extensibility for plugins.
- Added PluginOutlet usage in `post/avatar.gjs` for avatar-related
customizations.
2. **Refactored Post Attributes**:
- Enhanced handling of post attributes by deprecating the
`includePostAttributes` method in favor of `addTrackedPostProperties`
for improved compatibility with the Glimmer Post Stream.
- Added a new `isSmallAction` computed property to the `Post` model to
identify small actions or split topics.
3. **Improved Query Parameters**:
- Introduced `topicPageQueryParams` to manage query parameters for
topics more effectively, facilitating smoother updates and interactions
in components that won't need to inject the topic controller or the
router service to get these parameter values.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
Extend the `import_site_settings` import step to enable the
`migrated_site` flag if possible.
It also includes an escape hatch via the
`SKIP_MIGRATED_SITE_FLAG_UPDATE` flag for cases where you really don't
want to toggle it on.
We are making this the only option for our login/signup
pages on April 29th, 2025, per
https://meta.discourse.org/t/introducing-our-new-fullscreen-signup-and-login-pages/340401.
This commit removes the `full_page_login` setting and any logic
around it, as well as deleting the old login and signup modals,
and removing leftover problem checks and settings from the database.
There is a bug now where the staff action log that shows up in the
user's locale when a user deletes themselves.
<img width="962" alt="Screenshot 2025-04-29 at 12 08 49 PM"
src="https://github.com/user-attachments/assets/c367831d-25e6-453a-bce8-312ef7451a5c"
/>
This commit fixes that issue by scoping it to the site's default locale.
This JS was used to wrap long usernames. Nowadays in core, we use a
simpler `word-break: break-all;` pattern, so it makes sense to use the
same simplification in the embedded comments view.
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 change does a couple of things.
Change in behaviour:
- Matches on the site setting name and keywords now get a higher ranking in search results.
- When counting gaps for ranking fuzzy matches, we no consider the smallest number of gaps.
Code organization:
- Extract a separate SiteSettingMatcher object for the matching logic.
- Flatten some conditionals to make control flow clearer.
- Higher weight now means higher in search results.
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.
When ordering categories,
af8e48c1e0/app/models/category_list.rb (L61-L68)
Only one of the flows do `.group("categories.id")`.
This was causing sites with `SiteSetting.fixed_category_positions=true`
to 500 when another site setting
`SiteSetting.experimental_content_localization` was enabled. (Related:
https://github.com/discourse/discourse/pull/32464).
This commit fixes the issue by also grouping on the other case.
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.
This is a bug introduced by me by thinking the lonely operator is redundant here. It is not. Sometimes the param keys are not sent, and when they aren't we should preserve the existing attribute value, not null it out.
This PR fixes that and also adds a regression test explaining why it's needed.
