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.
A rework of https://github.com/discourse/discourse/pull/32460.
In the earlier PR that had to be reverted, we were directly deleting
cache (redis) and it was causing our image build to fail (see dev chat).
In this commit, we will rely on the existing method of invalid the keys
(which essentially will cause the next request to get the new site json
since the seq is not the same).
This PR makes the following key changes to the load-more component:
* Updating to a Glimmer component
* Changing from an eyeline/scrolling-based mechanism to an
IntersectionObserver to determine when to load
* Keeping track of a single invisible sentinel element to help trigger
the loadMore action instead of having to find and track the last item of
the collection upon every load
* The component can now be used without wrapping around some content to
be yielded - the intent is to use this for cases like
[DiscoveryTopicsList](f0057c7353/app/assets/javascripts/discourse/app/components/discovery/topics.gjs (L222))
where we might want more precise placement of the sentinel element.
* Added utility toggle functions to control observer behaviour in this
class for testing
We will replace the load-more mixin in DiscoveryTopicsList in another
PR.
https://github.com/user-attachments/assets/50d9763f-b5f8-40f6-8630-41bdf107baf7
### Technical Considerations
1. Keeping track of a single sentinel element simplifies the logic
greatly and is also more robust to changes in the collection that's
being loaded. (ref: a [previous
commit](2279519081)
that was following the previous approach of tracking specifically the
last item of the loaded collection); this also sidesteps odd edge cases
like if the tracked element is larger than the entire viewport.
2. Using
[isIntersecting](https://developer.mozilla.org/en-US/docs/Web/API/IntersectionObserverEntry/isIntersecting)
instead of calculating manually whether the element is in the viewport
is also less flaky - I ran into issues with the boundingClientRect
inconsistently being calculated as outside the viewport on different
sized screens.
3. We need to properly bind `loadMore` functions with the action
decorator, otherwise the way we pass the loadMore callbacks through to
the observe-intersection modifier results in attempting to call it on
the loadMore component context instead. I've done this for all such
functions except for the one in
[`category-list`](0ed4b09527/app/assets/javascripts/discourse/app/models/category-list.js (L117))
which uses `@bind` that should be equivalent in terms of binding to the
correct `this`.
- 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.
After adjusting an overflow on the rich editor placeholder, it started
being cut on mobile, as the parent paragraph can be smaller than the
area the placeholder takes.
This fixes it by returning the `position: relative` to the
`.ProseMirror` editor, which also fixes some weird positioning errors
for "fake" cursors (gap cursor, codemark cursor, drop cursor) and
absolute-positioned elements that relied upon the editor being
`position: relative`.