This seems to only happen if the email is changed. Eg,
https://forum.{mySite}.com/u/{user}/preferences/email
Confirmation email link template:
%{base_url}/u/authorize-email/%{email_token}
Actual confirmation email link:
https://forum.{mySite}.com/u/authorize-email/{someHash}
Can you repro this @tshenry?
It happened on ours too this week, just as described above.
You probably customized that email before we changed the link.
Please go to /admin/customize/email_templates/user_notifications.confirm_new_email and make sure that link in there looks like
%{base_url}/u/confirm-new-email/%{email_token}
instead of
%{base_url}/u/authorize-email/%{email_token}
It might be a good idea to add a migration after all. This came up multiple times already.
cc @sam
That took care of the broken link… sort of; now, it just redirects the user to the login screen.
Although it’s good this came to my attention to ensure folks can change their email, how come there’s no way for an admin to edit email from the admin panel? The only way was to impersonate >> profile >> change email? That’s what I read, anyway - is that truly the legit way to do this?
I can delete an account and impersonate but not change an email? Seems a bit counter-intuitive~
%{base_url}/u/confirm-new-email/%{email_token}
My link looks like that and it’s still sending people to an Oops error message. Are you saying it should be the other way round?
For me, %{base_url}/u/confirm-new-email/%{email_token} redirects people to login page without activating the account. The other one is the “oops” page.
This is weird but:
It was this:
%{base_url}/u/confirm-new-email/%{email_token}and gave an error message
I changed it to this:
%{email_token}/u/authorize-email/%{base_url} . and it still gave an error message
I changed it back to this:
%{base_url}/u/confirm-new-email/%{email_token} manually (not by resetting it)
and now it works! 
edit: oh and now it doesn’t again.
I would like to punt on this for a bit longer.
What about a backwards-compatible (deprecated) mirror link? Or a replacement script for a few versions? Could replace() the old %{} with new %{} next ver? If already migrated, nothing would happen.
But either way – my issue isn’t resolved… or, so it seems: It just shoots them to login screen without activation.
https://forum.{mySite}.com/u/confirm-new-email/{someHash}
^ Is this correct? The person insists they used incognito and showed screenshot of a login screen. Upon inspection, I can see that the old email address is still showing in admin.
I am not following, why not simply delete all your relevant locale customization and start from scratch?
Because like me and others – they have no idea this even happened. It’s not like the “Click to update” button had flashing lights telling us to change our email template.
I did exactly that, but:
Heck, I’ve had an account here and I still had no idea about this and had to dig for a fix. Imo, it’s unacceptable for the Discourse admin experience compared to any other update (it’s the first “intentionally breaking” update I’ve experienced). I’m not asking for me since I resolved it as you said – but for others.
Who knows how long this was happening on my forum. I wonder how many new-users we lost because we had no idea x update had a breaking template change? There’s no way I’m going to be the only one.
Just wanted to follow-up on this
Non l’ho mai personalizzato. Contiene %{base_url}/u/confirm-new-email/%{email_token} come hai consigliato, ma nell’email effettiva il link contiene /authorize-email/. Quindi immagino che qualcosa vada storto tra il pannello di amministrazione web e un file di configurazione nascosto nel cuore di Discourse. Sto eseguendo la versione 2.5.0.beta6
Modifica: ancora più strano: quando un amministratore modifica l’indirizzo email, la conferma inviata al vecchio indirizzo contiene %{base_url}/u/confirm-new-email/%{email_token}, mentre quella inviata al nuovo indirizzo contiene %{base_url}/u/authorize-email/%{email_token}
@Willemb2 abbiamo riscontrato sulla nostra istanza che il problema si presentava solo per gli utenti che avevano l’interfaccia impostata su una lingua specifica. Quindi, non importa quante volte ho provato a impostarla nella lingua che stavo utilizzando, non ha fatto alcuna differenza per chi parlava francese. Ho dovuto impostare la mia interfaccia in francese e improvvisamente mi ha permesso di personalizzare la versione francese, e da allora non abbiamo più avuto il problema.
@gh_irina Ho controllato, ma succede anche per gli utenti con la lingua predefinita (nel nostro caso: olandese).
Oh, che seccatura. Mi dispiace.
Ho appena riscontrato questo problema in un forum di cui sono membro. Sono riuscito a risolverlo modificando manualmente il link. Per queste modifiche che interrompono la compatibilità, perché non includere un gestore per il vecchio link per avvisare l’amministratore?