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.
I suspect the within is doing a memoization of the preview at a moment
where the emoji has not been rendered yet, when we render the emoji we
might have a different instance of the preview in the within which
doesn't have the emoji.
Im not super confident about this theory, but the within is useless here
so it seems like a good thing to try first.
The error we have is:
```
Failure/Error: super
Playwright::Error:
TypeError: Cannot read properties of null (reading 'namespaceURI')
at eval (eval at evaluate (:313:29), <anonymous>:17:12)
at UtilityScript.evaluate (<anonymous>:320:18)
at UtilityScript.<anonymous> (<anonymous>:1:44)
Call log:
[Screenshot Image]: /__w/discourse/discourse/tmp/capybara/failures_r_spec_example_groups_composer_using_review_media_does_not_flag_a_post_with_an_emoji_250.png
~~~~~~~ JS LOGS ~~~~~~~
ℹ️ Discourse v3.5.0.beta5-dev — https://github.com/discourse/discourse/commits/94932de163 — Ember v5.12.0
DEBUG: For more advanced debugging, install the Ember Inspector from https://chrome.google.com/webstore/detail/ember-inspector/bmdblncegkenkacieihfhpjfppoconhi
Failed to load resource: net::ERR_CONNECTION_REFUSED
~~~~~ END JS LOGS ~~~~~
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:1268:in `raise'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:1268:in `wait_until_resolved!'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:1482:in `value!'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/connection.rb:121:in `send_message_to_server'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel.rb:35:in `block in send_message_to_server_result'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel.rb:67:in `with_logging'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel.rb:34:in `send_message_to_server_result'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel.rb:20:in `send_message_to_server'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/javascript/expression.rb:10:in `evaluate'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright/channel_owners/js_handle.rb:19:in `evaluate'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/playwright-ruby-client-1.52.0/lib/playwright_api/js_handle.rb:46:in `evaluate'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-playwright-driver-0.5.6/lib/capybara/playwright/node.rb:885:in `block in path'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-playwright-driver-0.5.6/lib/capybara/playwright/node.rb:87:in `assert_element_not_stale'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-playwright-driver-0.5.6/lib/capybara/playwright/node.rb:884:in `path'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/element.rb:578:in `inspect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/queries/selector_query.rb:106:in `description'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/queries/selector_query.rb:115:in `applied_description'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/queries/selector_query.rb:180:in `failure_message'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/result.rb:114:in `failure_message'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/matchers.rb:112:in `block in assert_selector'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/matchers.rb:869:in `block in _verify_selector_result'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/base.rb:84:in `synchronize'
./spec/rails_helper.rb:421:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/matchers.rb:868:in `_verify_selector_result'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/node/matchers.rb:110:in `assert_selector'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/session.rb:774:in `assert_selector'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/rspec/matchers/have_selector.rb:18:in `element_matches?'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/rspec/matchers/base.rb:52:in `matches?'
./spec/system/composer/review_media_unless_trust_level_spec.rb:20:in `block (3 levels) in <main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/session.rb:366:in `within'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/dsl.rb:52:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/dsl.rb:52:in `within_element'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/capybara-3.40.0/lib/capybara/rspec/matcher_proxies.rb:15:in `within'
./spec/system/composer/review_media_unless_trust_level_spec.rb:20:in `block (2 levels) in <main>'
```
I suspect that by having an integer and not a float sometimes the value
we get is converted to 0.
This is the error we have atm:
```
Failure/Error: measurement = Benchmark.measure { example.run }
expected: 0.75
got: 0.0
(compared using ==)
```
This might not fix it, but it feels right to make this change.
A spec could potentially go so fast that it would attempt to fill in the
input before we have gone through the various redirects resulting in an
error.
```
Failure/Error: super
Playwright::Error:
TypeError: Cannot read properties of null (reading 'namespaceURI')
at eval (eval at evaluate (:313:29), <anonymous>:17:12)
at UtilityScript.evaluate (<anonymous>:320:18)
at UtilityScript.<anonymous> (<anonymous>:1:44)
Call log:
```
Now that we ensure that we have the current final state path we should
avoid this error.
Reported here:
https://meta.discourse.org/t/dashboard-freezes-until-sidebar-is-opened/366402
This is a follow-up to
https://github.com/discourse/discourse/pull/32651, when navigating from
the homepage to admin the hamburger gets force-hidden because we switch
from the dropdown to the sidebar nav but the scrollLock was
unintentionally left behind.
This makes sure we're only messing with hamburger state when the sidebar
is hidden (with ` {{hideApplicationSidebar}}`) and also removes the
scroll lock when the hamburger is force-hidden.
