## 🔍 Overview
Previously we added the ability to translate existing posts in different
languages: https://github.com/discourse/discourse/pull/32564. In this
update we add the ability to set a post language upon initially creating
a post.
Internally, we also clean-up/improve a few things, like:
- adding a `PostLanguageSelector` component
- Adding a `available_content_localization_locales` onto `SiteSetting`
so it's available in the service (without needing to parse the JSON to
access it)
- fix issues with the translation-editor not working due to some
regressions from here: https://github.com/discourse/discourse/pull/32869
- ensure everything works for replies/drafts/edits
## 📷 Screenshots
The moment locale files expect `this.` to be the window object. In a
type=module, `this` is `undefined`. This commit wraps the
moment-timezone definitions in an IIFE to resolve that.
Also adds a system spec to prevent future moment-timezone regressions.
Followup to a2b0c193dff40278c0a93995cc9b97b05dc8abb2
We will be moving towards `type="module"` for all of Discourse's JS
bundles in the near future. This commit makes a start by applying the
change to translation bundles.
This was previously merged, but the lack of `apply_cdn_headers` on the
locales controller led to CORS errors on sites with CDNs.
Previously we would check the request for a matching CDN hostname before
applying the `Access-Control-Allow-Origin` header. That logic requires
the CDN to include its public-facing hostname in the `Host` header,
which is not always the case.
Since we are only running this `apply_cdn_headers` before_action on
publicly-accessible asset routes, we can simplify things so that the
`Access-Control-Allow-Origin: *` header is always included. That will
make CDN config requirements much more relaxed.
At the moment, this is primarily relevant to the HighlightJsController
routes, which are loaded using native JS `type=module`. But in the near
future, we plan to expand our use of `type=module` to more critical JS
assets like translations and themes.
Also drops the `Access-Control-Allow-Methods` header from these
responses. That isn't needed for `GET` and `HEAD` requests.
This commit removes the color palette dropdown from the theme page and replaces it with a new "Colors" tab where the theme's color palette can be edited directly in that tab on the theme page. With this change, a theme's color palette is strongly tied to its theme and can't be linked to other themes and it can't be selected by users without using the theme as well.
All of the changes are behind a feature flag. To enable it, turn on the `use_overhauled_theme_color_palette` setting.
Co-authored-by: Ella <ella.estigoy@gmail.com>
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.
### Description
When accessing a category via
`<baseUrl>/c/<categoryId>.json?page={pageNumber}`, it issues a redirect
to `<baseUrl>/c/<categorySlug>/<categoryId>.json?.....`. During this
redirect, any numeric occurrence matching the categoryId in the query
string is also rewritten - including the page parameter - causing
incorrect behavior (e.g., `page=5` becoming `page=community/5`).
This PR fixes the logic ensuring that the query parameters remain
intact.
### How to reproduce?
Try opening this link https://meta.discourse.org/c/10.json?page=10 in
the browser. It will throw a 400 Bad Request error. When we inspect the
url, we will notice the page number has been replaced by the
`slug/categoryId`
## 🔍 Overview
This update includes some small improvements to post localizations. In
particular:
- we only show add translation button if user is part of
`experimental_content_localization_allowed_groups` and
`SiteSetting.experimental_content_localization` is `true`
- we no longer load `post_localizations` on every post until the post
localization globe is clicked
- we move the post localization indicator to be an menu item in the
post-action-buttons instead of being in the post meta data
- we remove the `SiteSetting.content_localization_debug_allowed_groups`
in favor of using a single setting:
`experimental_content_localization_allowed_groups_map`
## 📷 Screenshots
In some cases, Google crawlers don't output the meta description but
rather they output the first bit of text in the UI. Sometimes that is a
mix of table headings, topic titles and excerpts, which don't reflect
the site's mission. Adding the description to the homepage header might
help.
Internal ticket t/154372
These lines of code would output "Period - Site name" as the page title
for the crawlier view only for Top routes. This is too specific and
unnecessary, since the top route isn't highly prioritized for crawlers.
Without this, the page title defaults to "Site name" for these routes.
One major advantage of this change is that when the homepage is set to
the Top route, the page title for crawlers on the homepage is now "Site
name", which is a lot better.
This improves the error message(s) displayed when an error happens while
using a social login to log in / sign up into a Discourse community.
Unfortunately, we can't be super precise in the reason behind the error
(it can be the user clicked "cancel" during the authorization phase, or
any of the plethora of other possible errors) because the reason isn't
provided (either for security reasons, or because it's just hard to do
so in a reliable & consistent way accross all social logins).
The best I could do was to
- add the name of the "social login" provider in the error message
- tweak the copy a bit for the different cases handle
- fix the CSS/HTML to match the one used by the main application
In order to show the name of the provider, we use either the "provider"
or the "strategy" query parameter, or use the name of the authenticator
(if it's the only one enabled).
Internal ref - t/153662
---
**BEFORE**
**AFTER**
`strict_loading` was added to prevent it happening in the future. Few
adjustments had to be made:
- include color_scheme and color_scheme_colors, also for parent and
child themes;
- internal translations were using preload_fields, but it was too deep
to correctly use preloaded tables. I had to pass
`preloaded_locale_fields` manually;
- include theme in color_scheme.
Before:
<img width="663" alt="Screenshot 2025-05-15 at 3 43 47 pm"
src="https://github.com/user-attachments/assets/b55ce11e-80cb-43eb-8e31-940b0e9859f3"
/>
After:
<img width="665" alt="Screenshot 2025-05-16 at 11 29 00 am"
src="https://github.com/user-attachments/assets/f00bac19-f64b-4048-b220-4d0a9d90a929"
/>
Check to see if the user needs to be added to any groups before redirecting. To avoid introducing a CSRF issue, force the user through the normal invite acceptance flow, ensuring there's user interaction before being added to any groups.
This change also tweaks the behaviour of 2e10fe9 to not follow redirects of expired invitations.
Co-authored-by: Krzysztof Kotlarek <kotlarek.krzysztof@gmail.com>
a complement to the :post_destroyed event - customer needed an action to
happen just once when the wrench icon was used to delete one or more
posts ...
Detects the `redirect` queryParam on the /login route. If the user is
already logged in, navigates to that page. Otherwise, sets the
"destination_url" cookie so that the user will be redirected after
logging in.
If the param doesn't start with a single slash, ignore it and follow
previous behavior (navigate to "/" or log in then navigate there)
Respects subfolder configs.
We want to merge the theme component that allows admins to display extra groups on the about page. The settings for this are now under About your site.
All the code is lift-and-shift, with some minor adjustments, e.g. theme components can't use the group_list setting type, but it has been converted to that here.
Also the system tests for the admin controls are new.
This whole thing is gated behind a hidden site setting to avoid double rendering while we deprecate the theme component.
**Description**
As part of a customer request, we have added the option to search groups
by ID when doing API calls. However, in doing so we have decided to
correct the confusion around the group's routes. Previously the route
would look like `g/:id` while taking the `name` of the group as the
param. For example, when getting a group the route would be like this:
```
GET /g/admins
```
This would make the code in the controller seem as if it was handling
the group IDs instead of names. With these changes, this should be
addressed.
In development mode, when 'DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE' is
enabled, and going to /session/:username/become, we will now show an
error message when trying to impersonate an inactive user.
This was not obvious why trying to impersonate a user wasn't working
locally because I would hit the URL and be redirected back to the index
without any error and without being logged in.
## 🔍 Overview
This update adds the ability for users to manually add translations to
specific posts. It adds a 🌐 icon on the post menu where you can click to
add translations for posts.
It also introduces a new site setting:
`content_localization_debug_allowed_groups` which is convenient when
debugging localized posts. It adds a globe icon in the post meta data
area along with a number of how many languages the post is translated
in. Hovering over the icon will show a tooltip with access to editing
and deleting the translated posts.
## 📸 Screenshots
<img width="1234" alt="Screenshot 2025-05-07 at 13 26 09"
src="https://github.com/user-attachments/assets/9d65374d-ee3e-4e8b-b171-b98db6f90f23"
/>
<img width="300" alt="Screenshot 2025-05-07 at 13 26 41"
src="https://github.com/user-attachments/assets/6ee9c5e6-16ed-4dab-97ec-9401804a4ac8"
/>
The new themes listing page at `/admin/config/customize/themes`
currently has poor performance compared to the components page
(`/admin/config/customize/components`) due to various N+1 issues,
loading all themes and components from the server when only themes are
needed, and serializing data/attributes that aren't needed for rendering
the themes grid.
This commit improves the performance by eliminating all N+1 that are
currently present, excluding components from the page payload, and
reducing the amount of data transmitted for each theme when loading the
page.
This commit makes various changes and improvements to the new color palettes
page that was introduced in
https://github.com/discourse/discourse/pull/32379. Specifically, it:
* Removes the ‘Logos and fonts’ banner
* Removes the icon from the palette names in the list
* Moves the ‘new’ button to the top of the palette list
* Excludes theme-owned color palettes from the color palettes page since
these will be editable directly from the theme page
* Makes the name the primary text if a color has no description
* Adds a button next to the name field to save just the name
* Adds a ‘Delete’ button alongside the existing ‘Duplicate’ button
* Adds a ‘Revert’ button to change a modified color back to its default
value (based on the base palette of the palette)
This commit is replacing the system specs driver (selenium) by
Playwright: https://playwright.dev/
We are still using Capybara to write the specs but they will now be run
by Playwright. To achieve this we are using the non official ruby
driver: https://github.com/YusukeIwaki/capybara-playwright-driver
### Notable changes
- `CHROME_DEV_TOOLS` has been removed, it's not working well with
playwright use `pause_test` and inspect browser for now.
- `fill_in` is not generating key events in playwright, use `send_keys`
if you need this.
### New spec options
#### trace
Allows to capture a trace in a zip file which you can load at
https://trace.playwright.dev or locally through `npx playwright
show-trace /path/to/trace.zip`
_Example usage:_
```ruby
it "shows bar", trace: true do
visit("/")
find(".foo").click
expect(page).to have_css(".bar")
end
```
#### video
Allows to capture a video of your spec.
_Example usage:_
```ruby
it "shows bar", video: true do
visit("/")
find(".foo").click
expect(page).to have_css(".bar")
end
```
### New env variable
#### PLAYWRIGHT_SLOW_MO_MS
Allow to force playwright to wait DURATION (in ms) at each action.
_Example usage:_
```
PLAYWRIGHT_SLOW_MO_MS=1000 rspec foo_spec.rb
```
#### PLAYWRIGHT_HEADLESS
Allow to be in headless mode or not. Default will be headless.
_Example usage:_
```
PLAYWRIGHT_HEADLESS=0 rspec foo_spec.rb # will show the browser
```
### New helpers
#### with_logs
Allows to access the browser logs and check if something specific has
been logged.
_Example usage:_
```ruby
with_logs do |logger|
# do something
expect(logger.logs.map { |log| log[:message] }).to include("foo")
end
```
#### add_cookie
Allows to add a cookie on the browser session.
_Example usage:_
```ruby
add_cookie(name: "destination_url", value: "/new")
```
#### get_style
Get the property style value of an element.
_Example usage:_
```ruby
expect(get_style(find(".foo"), "height")).to eq("200px")
```
#### get_rgb_color
Get the rgb color of an element.
_Example usage:_
```ruby
expect(get_rgb_color(find("html"), "backgroundColor")).to eq("rgb(170, 51, 159)")
```
Follow-up to https://github.com/discourse/discourse/pull/31742
This commit adds a color palettes list to the new color palette edit page
that was introduced in the linked PR to allow navigating between color
palettes. It reuses the same UI that we already have in the legacy color
palette UI (`/admin/customize/colors`), but we may redesign the page in
the future.
There are instances of posts being deleted by system_user where the context is left blank in the staff action logs, leading to confusion about why exactly they have been deleted.
This change deprecates using the PostDestroyer as system_user without providing a context, and adds a context to all call sites currently missing it in core. Plugins to be done after this is merged.
Previously we were compiling core and theme CSS into two targets:
Desktop and Mobile. The majority of both files was the 'common' css.
This commit splits those common styles into their own targets so that
there is less duplication. This should improve compilation times + cache
reuse, as well as opening the door for experiments with
media-query-based mobile-modes.
The only functional change is that we can no longer use `@extend` to
copy 'common' rules in core to mobile/desktop. This is probably for the
best. Duplication and/or mixins are a more native-css pattern for this.
Plugins already have a common / mobile / desktop pattern, so are
unchanged by this commit.
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 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.
This PR addresses the issue discussed in
https://meta.discourse.org/t/failed-error-when-trying-to-un-star-the-bug-reporter-badge/330523
1. Fixed an issue in `user_badges_controller.rb` where the
`toggle_favorite` method could incorrectly treat badges already marked
as favorite as not being favorite.
2. Automatically synchronize the `is_favorite` status for new badges
when a user is granted a multiple-grant badge.
Previously, clicking "Groups" on the admin dashboard would bring you to the public groups page. Historically, the public and admin actions have been mixed together on that page.
This is a bit of a frustrating experience when working on the admin dashboard, and also prevented us from adding a "Settings" tab for group-related site settings.
This PR adds an "admin groups" page, which is just an exact copy of the public groups index for now. This allows us to add the "Settings" tab, and lets us gradually work un disentangling the public- and admin parts of groups.
Adds support for a tag-chooser in form templates. It supports single tag
and multi tags. The source of the displayed tags has to be a tag_group
name.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Don't require password to create users with previous authentication in
the session, regardless of email/email verification during user creation
Before my changes we were calling `user.password_required!` in
`UserAuthenticator.authenticated?` based on whether authentication
session data contained a matching email address and email verified
externally. I believe `authenticated?` is intended for our own email
validation during the activation process, but shouldn't be a gate for
password requirement.
Even when we were setting `user.password_required`, then during user
creation we were creating random passwords to get around the blank
password restriction when creating accounts with external auth.
After my change we can remove the random password creation because we no
longer require a password when the session has previous authentication
info at all.
Looks like this extra password requirement may have been introduced as a
side effect during a previous refactor of `UserController` here:
51eff92170
Before that change, password requirement was simply based on whether
session[:authentication] existed, but after that change it was based on
the email/email_valid fields as well.
This commits changes the language for components that aren't used on any themes to be "used/unused" instead of "active/inactive" throughout the new components listing page.
On sites with many components, serializing and rendering all components
in one-go on a page can take quite a bit of time. The new components
listing page that was introduced in
https://github.com/discourse/discourse/pull/32164 currently loads all
components in one-go, so this commit implements infinite-scrolling
pagination for the page to address this performance issue for sites with
many components.
