This commit removes the feature flag for the new /about page, enabling it for all sites, and removes the code for old the /about page.
Internal topic: t/140413.
This PR:
- Removes components from being displayed in the card
- Adds a DMenu to house previous footer actions
- Allows themes to be updated from this grid, with an animation and different border to show the update is happening
- Stops position of cards changing when default changes
- Fixes outline colour not changing when default changes
- Show a global notice on the page when previewing a theme
- Allows updating a theme from the grid, and showing an indicator of what theme needs to be updated
- Moves "Set as default" to the dropdown for the theme
- Show screenshot for theme if it is available
- Prevent page reloading when updating the theme
- Fixes theme install modal on grid page
- Temporarily remove sorting of default theme to the top
Followup 30fdd7738e
Adds a new site setting and corresponding user preference
to disable smart lists. By default they are enabled, because
this is a better experience for most users. A small number of
users would prefer to not have this enabled.
Smart lists automatically append new items to each
list started in the composer when enter is pressed. If
enter is pressed on an empty list item, it is cleared.
This setting will be removed when the new composer is complete.
This commit allows themes to define up to 2 screenshots
in about.json. These should be paths within the theme's
git repository, images with a 1MB max file size and max width 3840x2160.
These screenshots will be downloaded and stored against a theme
field, and we will use these in the redesigned theme grid UI.
These screenshots will be updated when the theme is updated
in the same way the additional theme files are.
For now this is gated behind a hidden `theme_download_screenshots`
site setting, to allow us to test this on a small number of sites without
making other sites make unnecessary uploads.
**Future considerations:**
* We may want to have a specialized naming system for screenshots. E.g. having light.png/dark.png/some_palette.png
* We may want to show more than one screenshot for the theme, maybe in a carousel or reacting to dark mode or color palette changes
* We may want to allow clicking on the theme screenshot to show a lightbox
* We may want to make an optimized thumbnail image for the theme grid
---------
Co-authored-by: Ted Johansson <ted@discourse.org>
This adds several improvements to the signup/login forms. Some of them include:
- Added a minimal signup progress bar design for mobile.
- Made the signup/login modals full height on mobile.
- Improved the activation, account creation, and login-required pages on mobile.
- Removed the subheader and emoji from the welcome component.
- Removed most input instructions.
- Used consistent font size for text below the inputs.
- Displayed input instructions only when the field is focused.
- Improved the vertical alignment of input labels.
- Increased the spacing between inputs.
- Fixed label positioning for custom fields.
- Moved the "(optional)" text for the name input outside the instructions.
- Disabled buttons during login to prevent layout shifts.
- Reused the CTA component for modals as well.
- Matched the invite CTA styles with the signup form.
---------
Co-authored-by: Jan Cernik <jancernik12@gmail.com>
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Background
When creating webhooks on a site without the Discourse Category Experts plugin installed, the category_experts_unapproved_event and category_experts_approved_event webhook events are getting automatically added to webhooks without a way to disable them.
The category_experts_unapproved_event and category_experts_approved_event webhook events are associated with the Discourse Category Experts plugin so I am moving these webhook events into the Category Experts plugin.
Changes
This PR deletes Category Experts plugin specific webhook event types added into core.
The new style is called `categories_only_optimized` and it is designed
to show only the parent categories, without any subcategories. This
works best for communities with many categories (over a thousand).
The visitor stats on the /about page were previously showing as `NaN` immediately after enabling the `display_eu_visitor_stats` site setting because the stats for the /about page are cached and updated once every 30 minutes in a sidekiq job. The `NaN` would go away upon the next run of the relevant sidekiq job, but it's not good UX to display a cryptic `NaN` until the job runs. So, this commit ensures that the visitor stats is not displayed at all until the visitor stats is calculated and available.
Internal topic: t/128480.
This commit brings back some reports hidden or changed
by the commit in 14b436923c if
the site setting `use_legacy_pageviews` is false.
* Unhide the old “Consolidated Pageviews” report and rename it
to “Legacy Consolidated Pageviews”
* Add a legacy_page_view_total_reqs report called “Legacy Pageviews”,
which calculates pageviews in the same way the old page_view_total_reqs
report did.
This will allow admins to better compare old and new pageview
stats which are based on browser detection if they have switched
over to _not_ use legacy pageviews.
Toggle the button to enable the experimental site setting from "What's new" announcement.
The toggle button is displayed when:
- site setting exists and is boolean;
- potentially required plugin is enabled.
This PR adds the feature where three or more image uploads in the composer will result in the images being surrounded by `[grid]` tags. This helps take advantage of the grid feature (https://github.com/discourse/discourse/pull/21513) and display images in a more appealing way immediately after upload.
This commit simplifies the initial state of the invite modal when it's opened to make it one click away from creating an invite link. The existing options/fields within the invite modal are still available, but are now hidden behind an advanced mode which can be enabled.
On the technical front, this PR also switches the invite modal to use our FormKit library.
Internal topic: t/134023.
* UX: More additions
* UX: more
* DEV: Add admin/config/themes route
* UX: Use admin config card
* syntax merge fixes
* cleanup
* cleanup
* checkbox
* more
* error
* save on click
* more
* fix setter
* DEV: Implement vanilla checkbox
* cleanup
* UX: save themes as default
* DEV: Add component list to card
* DEV: Add placeholder for no screenshots
* DEV: Fix default theme reactivity
Also add content/optionalAction yields to config area
card and put the theme user selectable checkbox there,
along with adding styles.
* DEV: Change to generic "look and feel" config area
* DEV: Auto redirect to themes on base look and feel route
* UX: Remove computed from sorted themes
* linting
* UX: Turn update icon into button that routes to settings
* DEV: remove unused function
* UX: center icons with title
* DEV: Lint
* UX: Hook up theme preview button
* DEV: Minor fixes
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
This adds dedicated routes for /login and /signup, replacing the use of modals. Currently, this is behind the experimental_full_page_login feature flag. It also includes some small consistency fixes related to formatting, spacing, icons, and the loading of certain elements
* Add migrations to ensure password hash is synced across users & user_passwords
* Persist password-related data in user_passwords instead of users
* Merge User#expire_old_email_tokens with User#expire_tokens_if_password_changed
* Add post deploy migration to mark password-related columns from users table as read-only
* Refactored UserPassword#confirm_password? and changes required to accommodate hashing the password after validations
When a post has some replies, and the user click on the button to show them, we would load ALL the replies. This could lead to DoS if there were a very large number of replies.
This adds support for pagination to these post replies.
Internal ref t/129773
FIX: Duplicated parent posts
DEV: Query refactor
Recently we updated the icon library from Font Awesome `5` to `6.6.0`. Since we were running Font Awesome 5 for a long time while 6 had already been released, we often specified in the codebase with the text _"FontAwesome 5"_. However, now that we are in the latest version, there is no need for our API's/comments to keep specifying for version 5. This PR updates all instances of FontAwesome 5 or FA5 and removes the version number to be the more generic: "FontAwesome"
We are going to start making section landing pages
for admin for each sidebar section. This lays the framework
with routes and simple components that can be further
refined by a designer, but I have taken the base CSS from
AI which Kris made.
The initial section landing items will be used in AI to replace
the placeholders added in this commit b8b3c61451
This commit introduces a feature that allows an admin to delete a user's
associated account. After deletion, a log will be recorded in staff
actions.
ref=t/136675
his is a new feature that lets admins dismiss notices from the dashboard. This helps with self-service in cases where a notice is "stuck", while we work on provisions to prevent "sticking" in the first place.
* removed periods from one-liner instructions on signup form
we want to skip periods and unnecessary punctuation on single sentence instructions in the UI, to make them easier to scan for users
* Update client.en.yml
Currently, when the custom flag has the same name as the system flag (which is disabled) then it is not displayed. To fix the problem, `custom_` prefix as `name_key` is used to distinguish between the system and the custom flag.
I considered writing a migration to fix existing custom flags name key. However, at the end of migration I would need to run rails code to reset cache `Flag.reset_flag_settings!`. I decided to skip that step as it is a very edge case. If someone has the same flag name as the system flag, then all they have to do is edit the flag and click save.
In addition, I made 2 small fixes:
- edit flag title was missing translation;
- flag form UI was not showing that description is the required field.
This commit adds a new `about_page_hidden_groups` setting to exclude members of specific groups from the admin and moderator lists on the /about page.
Internal topic: t/137717.
### UI changes
All of the UI changes described are gated behind the `use_legacy_pageviews`
site setting.
This commit changes the admin dashboard pageviews report to
use the "Consolidated Pageviews with Browser Detection" report
introduced in 2f2da72747 with
the following changes:
* The report name is changed to "Site traffic"
* The pageview count on the dashboard is counting only using the new method
* The old "Consolidated Pageviews" report is renamed as "Consolidated Legacy Pageviews"
* By default "known crawlers" and "other" sources of pageviews are hidden on the report
When `use_legacy_pageviews` is `true`, we do not show or allow running
the "Site traffic" report for admins. When `use_legacy_pageviews` is `false`,
we do not show or allow running the following legacy reports:
* consolidated_page_views
* consolidated_page_views_browser_detection
* page_view_anon_reqs
* page_view_logged_in_reqs
### Historical data changes
Also part of this change is that, since we introduced our new "Consolidated
Pageviews with Browser Detection" report, some admins are confused at either:
* The lack of data before a certain date , which didn’t exist before
we started collecting it
* Comparing this and the current "Consolidated Pageviews" report data,
which rolls up "Other Pageviews" into "Anonymous Browser" and so it
appears inaccurate
All pageview data in the new report before the date where the _first_
anon or logged in browser pageview was recorded is now hidden.