Logging form after upgrade

colak · 2020-06-22 18:12:21

Done:)

Bloke · 2020-06-22 18:38:20

Thank you.

phiw13 · 2020-06-23 06:54:57

An odd experience

So, on dev up-to-date, I have a few (5) languages installed. Front is set to En(GB), back-end was set to En(GB). After updating to the latest code, the login panel comes up using… Farsi. Logged in without changing anything, just to see what happens… Farsi for the admin side, nothing surprising. Heading to the languages panel, En(GB) and French needed updating. Done. Switched to En(GB), going to another panel to make sure the pref “sticks”, and logging out we go.

Login panel shows up in French¹.

The whole time the front-end or “site language” was set to En(GB).

I am not sure if that is the experience I’d like to see. I think I’d prefer always defaulting to site language.

–^–^–^–

¹ as it happens, last, most recent updated language.

Last edited by phiw13 (2020-06-23 06:56:08)

Bloke · 2020-06-23 07:45:34

Hmmm, are you sure this isn’t your cache thing rearing its head? Check the logout link by hovering over it as you navigate the admin side. It’s meant to track the admin language, though the link’s constructed from JavaScript for reasons I’m not entirely sure.

Bloke · 2020-06-23 07:47:16

We could default to site language if there’s no lang set in the URL, instead of defaulting to the first one in the list. That makes sense so I’ll do that.

Edit: done.

Last edited by Bloke (2020-06-23 08:16:42)

phiw13 · 2020-06-23 08:25:16

Bloke wrote #323922:

Hmmm, are you sure this isn’t your cache thing rearing its head? Check the logout link by hovering over it as you navigate the admin side. It’s meant to track the admin language, though the link’s constructed from JavaScript for reasons I’m not entirely sure.

Ok, the logout panel shows En(GB) – after yet another round of force reload (both browsers, Firefox is set to clear everything on quit, but I had other stub in tabs, did not want to reload everything). the logouts button shows indeed the URL with the &lang thingie. However, if you go to the login panel… nope nothing French all the way.

phiw13 · 2020-06-23 08:29:23

Bloke wrote #323923:

We could default to site language if there’s no lang set in the URL, instead of defaulting to the first one in the list. That makes sense so I’ll do that.

Edit: done.

had not seen this while commenting before. You didn’t yet check it in on dev, right, only 4.8.2 ?

It does make sense, I think.

Bloke · 2020-06-23 10:19:47

phiw13 wrote #323925:

had not seen this while commenting before. You didn’t yet check it in on dev, right, only 4.8.2 ?

Yeah, I’ve just merged to dev too.

phiw13 wrote #323924:

the logout panel… shows indeed the URL with the &lang thingie. However, if you go to the login panel… nope nothing French all the way.

The logout panel is the same as the login panel, but I think I get your drift :)

This is the expected behaviour:

The login panel immediately after logging out: logout=1&lang= will be in the URL, so the select list/the UI components will be in the language you were just using on the admin side.
The login panel from any bookmark that doesn’t include the lang= in the URL: the select list/the UI components will be rendered in the current front-end site language.
The login panel from any link that includes the lang= in the URL: the select list/UI components will be rendered in the nominated language from the URL if that language is installed. For this and the above items, if the language designator is in any way mangled or represents a language that is not installed, the public site language will be used to render the UI components and select list default value.
The forgotten password panel: the same language as in use on the login panel from which the link was clicked. No ability to change the language, short of altering the URL lang= parameter by hand.
The activate account/reset password panel: interface components will appear in the language given in the URL’s lang= parameter. This is derived from the language that the administrator has set for the new user when their account was created. If the language designator is in any way mangled or represents a language that is not installed for that installation, the current public side language will be used.
Messages emailed to authors when resetting password/activating account: These will be in the language nominated by the administrator when that account was created OR the current admin-side language for that author (if they’ve already logged in and have set/changed their admin-side language). If neither are set, the default language (TEXTPATTERN_DEFAULT_LANG that may be overridden in config.php) will be used to render the message. If that’s not installed, then the current public side language will be used.

I think that covers everything. Hope that behaviour makes sense but if there are any scenarios not covered, or if anyone thinks things could be improved, please speak up.

Last edited by Bloke (2020-06-23 10:23:13)

phiw13 · 2020-06-24 06:47:19

Bloke wrote #323926:

Yeah, I’ve just merged to dev too.

Thank you; that makes it much easier for me to test.

This is the expected behaviour: […]

I think that covers everything.

As far as I can tell (modulo my local testing playground does not send email) – I think everything works fine and your list covers most of potential issues. The initial language of the login panel (site_default) makes much more sense now.

Textpattern CMS

Textpattern CMS support forum

#37 2020-06-22 18:12:21

Re: Logging form after upgrade

#38 2020-06-22 18:38:20

Re: Logging form after upgrade

#39 2020-06-23 06:54:57

Re: Logging form after upgrade

#40 2020-06-23 07:45:34

Re: Logging form after upgrade

#41 2020-06-23 07:47:16

Re: Logging form after upgrade

#42 2020-06-23 08:25:16

Re: Logging form after upgrade

Bloke wrote #323922:

#43 2020-06-23 08:29:23

Re: Logging form after upgrade

Bloke wrote #323923:

#44 2020-06-23 10:19:47

Re: Logging form after upgrade

phiw13 wrote #323925:

phiw13 wrote #323924:

#45 2020-06-24 06:47:19

Re: Logging form after upgrade

Bloke wrote #323926:

Board footer