Similar to https://github.com/discourse/discourse/pull/32526.
Reviewer note: There had been some deliberation if we should just take
the `topic.first_post.locale` instead of having a `topic.locale`.
Ultimately, titles may be of a different language of the post itself,
and secondarily in some cases it could be faster without having to load
the first_post at all.
Previous to this change when we used to specify format it could get an
image
in the incorrect format.
Also... allows image magick to decode svg
---
There remains a bug where the crop / resize information is not stored in
optimized images
this means that sometimes when asking for a cropped image you may get a
resized one.
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.
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.
When a reviewable is auto-claimed, this actually claims all reviewables in a given topic, rather than just the specific post that the reviewable is about. Particularly for sites that require all posts to be reviewed, this can quickly result in many reviewables being unintentionally claimed by the first moderator to review a post in a given topic.
Unfortunately, due to `ReviewableClaimedTopic` being originally built to claim by topic, we can't fully fix this without significant re-architecture. In the mean time, however, we can ensure that reviewables are unclaimed once they've been handled, so that the next reviewable from a topic won't be automatically claimed.
When multiple admins are working in the review queue, it's quite easy for two people to try and handle the same reviewable at the same time. This change addresses the two major situations where this can occur.
The `ReviewableClaimedTopic` model has been extended to allow the system to mark a reviewable as claimed as soon as the first moderator starts handling the reviewable, even when the `reviewable_claiming` setting is disabled. This ensures that reviewable actions with client-site activity (for example, `agree_and_suspend`) will lock the reviewable before another moderator starts working on it.
When someone handles handles a reviewable, we now use `MessageBus` to inform other moderators that it's changed. If any of the other moderator have that reviewable open (either individually, or on the list screen), it will automatically refresh that data.
This PR renames a couple of settings related to anonymous mode:
1. `allow_anonymous_posting` → `allow_anonymous_mode`. This setting is
used as a switch for the entire anonymous mode feature, so it makes
sense to give it a generic name that better reflects what the setting
does.
2. `allow_anonymous_likes` → `allow_likes_in_anonymous_mode`. The new
name is clearer and will match a new setting that we'll add to allow
anonymous users to post in chat.
Internal topic: t/148088.
This is a stripped-back version of the Search Banner
component https://meta.discourse.org/t/search-banner/122939,
which will be renamed to Advanced Search Banner,
see https://github.com/discourse/discourse-search-banner/pull/84.
This welcome banner interacts with the header search.
When `search_experience` is set to `search_field`, we only
show the header search after the welcome banner scrolls
out of view, and vice-versa.
Only new sites will get this feature turned on by default,
existing sites have a migration to disable it.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: Jordan Vidrine <jordan@jordanvidrine.com>
This is a follow up to 6820622467.
This commit addresses migrations that uses `remove_index` with the
`if_exists: true` option to drop an existing index before creating an
index using the `concurrently` option.
This commit also reruns two migration which may have caused indexes to
be left in an `invalid` state.
### Reviewers Note
Plugin tests are failing due to
https://github.com/discourse/discourse-translator/pull/251
The previous version of the migration is not idempotent and can result
in indexes created but marked as "invalid" by Postgres.
Per postgres documentation:
If a problem arises while scanning the table, such as a deadlock or a
uniqueness violation in a unique index,
the CREATE INDEX command will fail but leave behind an "invalid" index.
This index will be ignored for querying
purposes because it might be incomplete; however it will still consume
update overhead. The recommended recovery
method in such cases is to drop the index and try again to perform
CREATE INDEX CONCURRENTLY.
When the upgrade process from 29a8c6ee49 is run, there's a deployment race condition where old code can write a Reviewable to the database without a `type_source` (incorrectly defaulting it to "unknown").
This change adds a post-deploy migration script that populates any such Reviewables with the correct `type_source` value.
We are developing our new composer, and it would be useful
if we could know how posts are being created by members.
To this end, we are going to start storing the following
on post_stats, which are created at the same time as a post
is created:
* writing_device - Based on `BrowserDetection.device`, which in
turn is based on user agent. Will store .e.g iphone, android,
mac, windows etc.
* writing_user_agent - Stores the full user agent (truncated at
400 chars) of the device/browser the member used to write the post.
* composer_version - Either `1` for our old composer, or
`2` if the new rich composer is enabled in site settings and
the user has toggled it on
Currently, after creating an API key, there is no way in the UI to see what scope the key has. To do this we need to first store the selected scope mode when creating a new key.
In this PR we:
- Convert scope_mode from a transient attribute to a database backed enum.
- Ship the possible values through the javascript:update_constants rake task instead of hard coding in front-end.
In follow-up PRs we will:
- Backfill existing API keys based on their associated api_key_scopes records.
- Start showing the scope mode in the UI.
When a post is flagged due to matching watched words, it can be difficult to know what you're looking for, particularly if you have a lot of watched words built up over a long period of time.
This change stores the list of matched words, and later displays them in the review queue, listing which Watched Words were responsible for the flag. Because watched words can change, this is recorded at the time the post is flagged. For posts that were flagged prior to this feature landing, it tries to guess the relevant words based on the current Watched Words set.
Redesigned page to update site logos. `AdminBrandingLogoFormComponent`
is attached to the old logos page and the new branding page. In the next
steps, branding will replace the logos page.
A new `AdminConfigAreaCardSection` component was added hidden and less
frequently used settings.
An image placeholder was also needed because many additional logos have
a fallback to the site logo.
Finally, `twitter_summary_large_image` was renamed to
`x_summary_large_image`.
Desktop
Mobile
As we’re currently using a namespace for Sidekiq, in order to upgrade to
the latest version, we need to drop it as it’s not supported anymore.
The recommended way is to use a different Redis DB for Sidekiq.
This patch uses a different config for Sidekiq and also takes care of
migrating existing jobs (in queues and the retry and scheduled sets).
This change adds a new `type_source` field to the `Reviewable` model, indicating whether the Reviewable type was registered by `core`, a plugin, or an `unknown` source.
When a plugin that registered a Reviewable type is disabled, this allows us to tell the user which plugin they need to re-enable to handle any orphan reviewable items.
This PR adds two attributes (`op_can_like` & `op_liked`) to
`TopicListItemSerializer`.
We've also added `serialize_topic_op_likes_data` theme modifier so that
these two attributes are only added when a theme or component needs this
data.
Rename `min_first_post_typing_time` to `fast_typing_threshold` and
provide admin 4 options:
- disabled
- low - 1 second
- standard - 3 seconds
- high - 5 seconds
Related PRs:
- https://github.com/discourse/discourse-zoom/pull/112
This commit narrows down the list of fonts we offer
in our setup wizard and simplifies things to only
show a single font dropdown. This selection will then
set the `base_font` and `heading_font` site setting to
the same value.
For existing sites that may have set different values,
we will still show 2 dropdowns when visiting the wizard.
We are also changing our default font to the more modern
selection Inter, replacing Arial. Arial is very dependent
on system installed fonts, whereas Inter we can package
to everyone in Discourse.
Finally, for existing sites that have not changed their default
from Arial, we will keep that value via a migration so we do
not surprise site owners with a completely new font.
This is a very narrowly scoped migration to update badges.icon for two
deprecated names `smile` and `share-alt`. Following on from this PR that
updated the Badge seed fixture used as part of site creation:
https://github.com/discourse/discourse/pull/30942
The migration logic closely follows that of the [previous DB
migrations](https://github.com/discourse/discourse/pull/30100) that
updated all deprecated FA icon names, just that we reduce the mappings
to only look for `smile` and `share-alt`.
This PR raises an error on any deprecated icon names being converted by
`icon-library.js`, which will result in any deprecated icons introduced
in JS-land to fail qunit/system tests.
We'll do the same for `svg_sprite.rb` once I've resolved pre-existing
deprecated icons in core/plugins that's caught by the same exception
logic.
We're embarking on a project for overhauling the color palette and theme
systems in Discourse. As part of this project, we're making each color
palette include light and dark modes instead of the status quo of
requiring 2 separate color palettes to implement light and dark modes.
This commit is a first step towards that goal; it adds a code path for
generating and serving `color_definitions` stylesheets using the
built-in dark variant of a color palette. All of this code path is
behind a default-off site setting `use_overhauled_theme_color_palette`,
so there's no change in behavior unless the setting is enabled.
Internal topic: t/141467.
Related to https://github.com/discourse/discourse/pull/30893
As part of the theme overhauling project, we're making each theme fully
own/control its color palette which can be edited directly on the theme
page. To make this possible, we need to introduce a special type of
color palettes that are marked as "owned by a theme" in the database
which aren't displayed in the admin color palettes page and can't be
edited from it. This commit is the first step of this change; it adds a new
join table to associate a color palette with a theme. For now, we're
keeping the relationship one-to-one (hence the `UNIQUE` indexes), but we
may later change it to one-to-many.
Internal topic: t/141648.
This PR is a follow-up to #30636.
The previous change altered the `data_type` of the `base_font` and
`heading_font` site settings, but didn't update the corresponding
entries in the `site_settings` table to match.
Follow up from https://github.com/discourse/discourse/pull/27712.
Currently, we already add `noindex` to /u routes. However, due to
robots.txt blocking this, search engines are not able to see the header.
This commit removes /u from our robots.txt to allow search engines to
see the header. This commit also includes a migration to remove the /u
from admins who have overridden the file. I had contemplated not
including this migration, but seeing there are existing site admins who
are trying to remove errors from their dashboard, they would probably
welcome this change.
The migration replaces overridden text at this area, and will not modify
if additional routes have been added in-between:
<img width="500" alt="Screenshot 2025-01-15 at 11 28 43 AM copy"
src="https://github.com/user-attachments/assets/60db64c9-ed33-48a5-a917-a10545282a5c"
/>
Side effect note: This might potentially result in more pageviews* from
GoogleBot (for example) for a period of time as Google starts visiting
the user routes they have been denied before.
Followup 3187606d34
Fix full_name_requirement INSERT by adding ON CONFLICT DO NOTHING,
on sites that already have this setting this migration will fail.
This commit replaces the `full_name_required` setting with a new `full_name_requirement` setting to allow more flexibility with the name field in the signup form. The new setting has 2 options, "Required at signup" and "Optional at signup", which are equivalent to the true/false possibilities of the old setting, and a third option "Hidden at signup" that hides the name field from the signup form, making it effectively optional too.
New sites will have the "Hidden at signup" option as the default option, and existing site will continue to use the option that maps to their current configuration.
Internal topic: t/136746.
This commit starts the rollout of the Glimmer post menu:
- default to `auto`: after the upgrade, it will be enabled on all discourse instances that do not have incompatible customizations
- unsilence the deprecation messages in the console
- removes the setting `glimmer_post_menu_groups` as it's no longer in the test phase
This commit adds a new column full_move to the moved_posts table. This is useful to look back at history and determine if a whole topic was moved or partial.
This commit also adds an apply_modifier to skip the creation of the moved posts small action.
This is a follow-up to e6fdfcdcd2 which
did not remove the site setting from `config/site_settings.yml` and drop
the site setting value from the database.
Natalie Tay
Krzysztof Kotlarek
Sam
Martin Brennan
Gary Pendergast
Sérgio Saquetim
Roman Rizzi
Osama Sayegh
Kevin Hwang
Alan Guo Xiang Tan
Ted Johansson
Loïc Guitaut
Arpit Jalan
Kelv
Mark VanLandingham
Bianca Nenciu
