Gracias @EricGT por tus comentarios CTAs que no pueden realizar.
Esto se solucionará con
main ← hide-signup-in-read-only-mode
merged 06:05PM - 28 Jul 26 UTC
Previously, a site in read only or staff only mode still offered
anonymous visit… ors every way in: the header "Sign Up" button, the signup
call to action at the end of a topic, the create account link on the
login page, and the server-rendered header — including the one on the
read only error page itself. Account creation is blocked in both modes,
so all of them were dead ends. The banner made it worse by describing
what members lose (replying, likes) rather than what an anonymous
visitor is actually unable to do.
This change gates the JS `canSignUp` getter and its Ruby twin
`can_sign_up?` on read only state, which covers every signup entry point
at once. `canSignUp` had to drop its `@computed` decorator to do so:
with no dependent keys it cached permanently, so the new term would have
been evaluated once at boot and then frozen — leaving the button visible
if read only mode started later, and hidden long after it ended.
The "Log In" button deliberately stays, because staff can still log in
during staff only mode. Anonymous visitors now get banner copy naming
signup and login instead, a refused login says only staff can log in
rather than claiming login is disabled outright, and the email and code
login forms show that inline instead of a generic "an error occurred"
dialog.
It also fixes a pre-existing blank page. Both `/login` and `/signup`
aborted the transition when read only, which on a direct URL load left
the application template unrendered — and with it the dialog holder, so
the explanation never appeared either. They now redirect home when there
is no route to stay on, and keep aborting when there is.
Meta ref: /t/408703
6 Me gusta
Estoy de acuerdo en que debemos hacer lo posible por no frustrar a los usuarios anónimos con CTAs que no pueden realizar.