This commit drops the `before_action :preload_json` callback in `ApplicationController` as it adds unnecessary complexity to `ApplicationController` as well as other controllers which has to skip this callback. The source of the complexity comes mainly from the following two conditionals in the `preload_json` method:
```
# We don't preload JSON on xhr or JSON request
return if request.xhr? || request.format.json?
# if we are posting in makes no sense to preload
return if request.method != "GET"
```
Basically, the conditionals solely exists for optimization purposes to ensure that we don't run the preloading code when the request is not a GET request and the response is not expected to be HTML. The key problem here is that the conditionals are trying to expect what the content type of the response will be and this has proven to be hard to get right. Instead, we can simplify this problem by running the preloading code in a more deterministic way which is to preload only when the `application` layout is being rendered and this is main change that this commit introduces.
This PR raises an error on any deprecated icon names being converted by
svg_sprite.rb, which will result in any deprecated icons being processed
by the ruby lib to fail tests.
While introducing the new drafts dropdown menu component, we also made
some changes to how the sidebar link works for Drafts. However, after
following user feedback and internal discussions we decided to revert
back to the shared link approach that combines My Posts and My Drafts.
Before this commit it was complicated to render a `Checkbox` outside of
a `CheckboxGroup` as you would get no title, no description, no optional
hint and not tooltip.
This commits makes all of this possible by adding a special case for
checkboxes, and sharing code for tooltips and optional hint.
This commit also uses this opportunity to refactor part of the code to
use curryComponent and reduce code duplication.
This change adds a sidebar link for each plugin that fulfils the following criteria:
- Does not have an explicit admin route defined in the plugin.
- Has at least one site setting (not including enabled/disabled.)
That sidebar link leads to the automatically generated plugin show settings page.
Previous upgrade had a runaway CPU issue due to
overly aggressive GC running.
MiniRacer was running V8 GC every 2 seconds.
New change fixes the parameter so it only issues a GC
if 2 seconds past since last MiniRacer eval.
This experiment hides the list of categories in the inner
sidebar for the main site settings page if the admin sidebar
is enabled. It also defaults the list of settings to "All"
instead of a specific category.
Our theory here is that people who use this page are using
it to find an exact setting, not to go through the categories
one by one. Our admin sidebar also has several groups of important
settings already too, so that can be used for browsing.
Finally, the input on the page focuses when you load it, so
filtering is faster.
due to an issue with LEFT JOIN, we were enqueue a "chat summary" email
for every new messages in a channel, instead of for every new mentions 😬
This bloated the sidekiq queue with a lot of unecessary jobs as seen in
- https://meta.discourse.org/t/-/347197
- https://meta.discourse.org/t/-/346542
Thankfully, it wasn't sending those emails as the query for listing the
unread mentions and dms was correct when generating the chat summary
email.
Due to a recent regression the selection management was failing in
drawer mode for threads. We were not correctly setting the active
thread.
This commit fixes the issue and adds a spec.
`topic-list-columns` expects consumers to mutate the DAG, not return a
new one. This change means that themes/plugins do not need to remember
to `return columns` when using the transformer.
Also removes the exception when someone returns a value to a mutable
valueTransformer. This is essential for backward-compatibility.
Rake allows env variables to specified in arguments, so we need to use
the list of top_level_tasks which excludes those env
Followup to c8718a64dd7a26165efe91706ce5507e6999044a.
By design, db:create initializes the Rails app with SKIP_DB=true. That
means that SiteSettings get set up with the LocalProcessProvider instead
of the DBProvider. In other words: any calls to site settings will
return the default, rather then the actual value in the database.
Running db:migrate in the same rake invocation means that rails will not
be re-initialized, and so skip_db will remain true. Site settings
accessed during migrations and fixtures will therefore return incorrect
values.
One example of this is that running bin/rake db:create db:migrate
repeatedly in a development environment will cause the FAQ topic to be
seeded repeatedly, because the seed logic does not have access to the
site setting which stores the already-seeded topic id.
This commit will automatically re-exec the Rake command if any tasks are
specified after `db:create`
Related to
https://meta.discourse.org/t/double-button-inconsistencies-post-menu/349845
This does some general clean up...
* **Moves shared mobile/desktop styles into /common**
We had some mobile hover states for some reason, and desktop hover/focus
states can be moved to common and gated with `.discourse-no-touch`...
this means we're applying them on capabilities rather than device type
* **Adds some `-d-post-control-` variables to make theming easier**
Theme authors can replace the variables without worrying about selector
specificity
* **Removes an overridden fade-out class from likes**
We were overriding the effect here anyway
* **Fixes a janky hover transition effect on the like button**
This was being incorrectly inherited from another button
...and fixes some issues
* **Corrects border radius on double buttons (likes, flags)**
* **Corrects double button height issues for flags**
* **Adjusts the flag count to avoid the lumpy circle CSS problem**
* **Removes lingering post-tap focus/hover states on mobile by applying
`.discourse-no-touch` and `focus-visible`**
Tested both glimmer and legacy.
This PR refactors the use of the UsernameValidation mixin to a helper
class for the SignupController component. We'll extend this to the
CreateAccount modal and InvitesShowController in follow-up PRs.
- `@height` was supported but not working correctly, this is now fixed
and tested
- `@preview` was not supported, we would always hide the preview in form
kit. You now have control over this, default `false`.
