We use ampersand to concatenate sidebar sections, e.g. Login & authentication, Logs & screening, etc.
This updates Themes & components to have the same.
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
Currently, topic excerpts are not localized.
This commit adds the excerpt column into topic_localization and displays the
localized excerpt if present.
```
rspec --seed 52075 spec/models/site_spec.rb spec/lib/freedom_patches/translate_accelerator_spec.rb
Randomized with seed 52075
....................................................F
Failures:
1) translate accelerator plugins loads plural rules from plugins
Failure/Error: self.locale_no_cache = value
I18n::InvalidLocale:
:foo is not a valid locale
# ./lib/freedom_patches/translate_accelerator.rb:254:in 'I18n.locale='
# ./spec/lib/freedom_patches/translate_accelerator_spec.rb:118:in 'block (3 levels) in <main>'
```
This is because setting `I18n.config.available_locales` is equivalent to
hard coding the
locales for the entire process. It should not be set so that `I18n` will
fallback to `backend.locales`.
Some cases are more complex than the default behavior of
`this.router.isActive(this.args.route)`, in this case you can give use
`@currentWhen` on your `NavItem` component.
Example:
```gjs
get isItCurrent() {
return true;
}
<template>
<NavItem @i18nLabel="test" @currentWhen={{this.isItCurrent}} />
</template>
<template>
<NavItem @i18nLabel="test" @currentWhen="foo" />
</template>
<template>
<NavItem @i18nLabel="test" @currentWhen="foo.show foo.index" />
</template>
```
No test as I can't write a component test for this as it relies on the
router.
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**
This error sometimes includes a filepath in the middle, which has a
random tmp/ prefix. To workaround this, we can just assert for the
"Missed semicolon" part
Technically we want to follow DDAU but most of our usage in the code
base are just mutating `@checked`. This will eventually get converted to
form-kit but in the meantime we can just remove this bit of code as it's
doing two times the same thing and you could even end up in the
situation where they both fight for what is the correct value.
- Add a safeguard until we implement pagination for the index, it
ensures we won't try to load more than 500 automations ever.
- Includes the fields of the automation so we don't have an N+1 and also
filter them in ruby land instead of doing two additional queries
- Ensures a field object in the field serializer is capable to find the
loaded automation associated to it instead of trying to reload it
- Includes pending_automations to avoid an N+1
…Outlet (#32742)"
This reverts commit 707a91243c35ea1693b80249e1c00fb5320f47cb.
This is causing some unexpected re-rendering. Reverting while we
investigate
Fixes for recent regressions:
- da6b82f7767cbeb038dfbebda92a4474626ff1e8
- 2a18834db1cb6b9c8f071eeab8554257336b2802
These tests should stop it happening for a third time 😅
Historically, plugin outlet arguments had to be accessed like
`@outletArgs.foo` in templates, or `this.args.outletArgs.foo` in
javascript. Following this commit, outletArgs will be passed to
connectors at the top level, so they can be accessed like `@foo` in
templates or `this.args.foo` in JS.
`@outletArgs` remains available for compatibility, and there are no
plans to remove it.
For custom classic component connectors, these new arguments may clash
with functions/fields defined on the component class. This rare case
will be automatically detected, protected against, and a deprecation
will be shown.
This avoids making unnecessary database queries when routing to paths
that were positioned below this entry, e.g.
```
curl http://localhost:3000/form-templates
# SELECT 1 AS one FROM "permalinks" WHERE "permalinks"."url" = 'form-templates' LIMIT 1
# …
```
What is the problem?
When we construct the admin search component, we fire off a call to get data from the back-end. When this is done, there's an async callback that re-does the search. This can result in confusing flickering of the results.
This was compounded by a separate issue that caused the data endpoint to be extremely slow if we had two specific plugins installed at the same time. That issue has already been resolved.
The first time we construct the component (and fetch the data) we initialize it with a flag to indicate that data is still loading. Until the data is loaded, we will show the regular loading spinner if the admin starts typing.
On Meta the endpoint takes ~600ms. That countdown starts when you click or use the shortcut, then you need to start typing as well, so this delay shouldn't be a big issue.
`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"
/>
The proper fix was to apply what has been reverted in
7558e2c7cd
but we would have to break the API to apply this fix so I will just skip
these specs for now.
This test is about testing that we can set notification_level, which it
does correctly. The rest of the spec was testing some undefined behavior
which is flaky.
