Logging form after upgrade

colak · 2020-06-22 06:22:53

Sorry to be the devil’s advocate here but I seem to remember some posts in this forum about the security of front end cookies. Isn’t this effectively the same thing as the language preference will be there even after logout?

Bloke · 2020-06-22 07:17:25

phiw13 wrote #323881:

Would that widget benefit of loosing the select-widget UI and displaying everything on one line ?

Yes! That’s brilliant. Phil, do we have a design pattern for that? I can’t check right now. But I’ll look later if you don’t have time right now.

Bloke · 2020-06-22 07:26:06

colak wrote #323882:

the security of front end cookies. Isn’t this effectively the same thing as the language preference will be there even after logout?

For clarity, there’s no cookie stored. No localStorage either. If everyone feels that having the last used language in the URL is a privacy risk (let’s face it, the username is still available too in the login box) then we can easily lose the lang=. The only loss of functionality would be that the language selector returns to the first one in the list.

phiw13 · 2020-06-22 08:05:20

Bloke wrote #323883:

Yes! That’s brilliant. Phil, do we have a design pattern for that? I can’t check right now. But I’ll look later if you don’t have time right now.

(not Phil…) Not directly I think; the closest thing is the select widget just above the textarea on the Write panel. But that uses JQUI stuff. Could reuse the code though, me thinks. The below is enough, IE 11 has some light quirk, maybe.

select { border: none; background-color: transparent; padding: 0; padding-inline-end: 2em; }

gaekwad · 2020-06-22 08:56:15

phiw13 wrote #323881:

I couldn’t test the other change(s) you mention as user management/creation is mostly disabled on the demo site (for good reasons!)

It’s funny you mention that, I was looking at the logs the other day, there are all kinds of things happening on those demo sites: evidence of fuzzers, XSS attempts, they’re a great source of interest to people who want to break stuff!

Bloke · 2020-06-22 08:58:47

phiw13 wrote #323886:

the closest thing is the select widget just above the textarea on the Write panel. But that uses JQUI stuff.

Thank you for the code. Yeah, that’s a bit more involved to set up than a simple select, but I’m willing to do it that way if necessary because your proposed layout is miles better than the clunky ‘orrible select box.

If Mr Wareham could kindly advise on suitable markup for the side-by-side layout then we can go from there. And if there’s a nifty class available for styling it too, that’d be even better!

phiw13 · 2020-06-22 09:08:44

Bloke wrote #323888:

Thank you for the code. Yeah, that’s a bit more involved to set up than a simple select, but I’m willing to do it that way if necessary because your proposed layout is miles better than the clunky ‘orrible select box.

I don’t think you need all that JQUI machinery just to style that widget a little. The less JQUI, the better imho.

Bloke · 2020-06-22 09:08:52

phiw13 wrote #323881:

I couldn’t test the other change(s) you mention as user management/creation is mostly disabled on the demo site

Yeah, the only thing you can do is search for the user name you were assigned as a login and change your own language from the Users panel.

gaekwad wrote #323887:

there are all kinds of things happening on those demo sites: evidence of fuzzers, XSS attempts, they’re a great source of interest to people who want to break stuff!

I bet! In my daily logwatch report, I had one last week where I could barely even see the scrollbar height. It just went on and on as someone had tried every SIP port for every major protocol to try and exploit VOIP loopholes or use my server as a free call relay. Yealink, Well, autoprovisioning, bootstrap, cfg, defy, phone, …

Bloke · 2020-06-22 09:09:26

phiw13 wrote #323889:

I don’t think you need all that JQUI machinery just to style that widget a little. The less JQUI, the better imho.

Absolutely! If we can get away with a simple CSS class/container for it, that suits me perfectly.

Bloke · 2020-06-22 09:13:59

Tell you what, I’ll mock it up now with an inputLabel() so we get side-by-side and see if it works. We (Ahem, Phil) can then look at adding some CSS to de-emphasise the select (or advise if we already have it available).

EDIT: Uhh, wait, I’m already using inputLabel() but it’s coming out stacked. Hmmm. Must be missing something.

Last edited by Bloke (2020-06-22 09:17:52)

phiw13 · 2020-06-22 09:23:58

Bloke wrote #323892:

Tell you what, I’ll mock it up now with an inputLabel() so we get side-by-side and see if it works.

HTML code wise, you don’t need to do anything., Just a little of CSS to align things (display: flex; flex-flow:row wrap and restyle the select as above. PhilWareham can fine tune to taste.

Bloke · 2020-06-22 09:29:05

phiw13 wrote #323893:

CSS to align things

Yeah, just looked at your code in the inspector and seen what you’ve done. Sorry. Brain not switched on this morning yet.

Rather than do it inline, I’ll try and find any classes in the design patterns that might help.

Last edited by Bloke (2020-06-22 09:29:28)

philwareham · 2020-06-22 10:09:31

Just seen this thread – I will create and provide an additional class for use on select fields that will remove various parts of the UI chrome. I’ll roll it into 4.8.2 branch and also 4.9.0 master, since they have diverged a bit in last few days.

Bloke · 2020-06-22 10:42:29

philwareham wrote #323896:

Just seen this thread – I will create and provide an additional class for use on select fields that will remove various parts of the UI chrome.

Woot! Thank you.

I’ll roll it into 4.8.2 branch and also 4.9.0 master.

That’ll make merges tricky. Tell you what, I’ll just commit the 4.8.2 branch to dev now, then you can add the CSS to both and it won’t (shouldn’t!) complain in future merges.

EDIT: done. Go for it whenever you’re ready and tweak the class in txp_auth too if you wish.

Last edited by Bloke (2020-06-22 10:48:36)

philwareham · 2020-06-22 10:44:50

Bloke wrote #323899:

That’ll make merges tricky. Tell you what, I’ll just commit the 4.8.2 branch to dev now, then you can add the CSS to both and it won’t (shouldn’t!) complain in future merges.

I have a 4.8.x branch of the admin themes (as the 4.9 themes have been extensively changed) so I’ll just add the code to both theme branches and pull each in accordingly.

Textpattern CMS support forum

#16 2020-06-22 06:22:53

Re: Logging form after upgrade

#17 2020-06-22 07:17:25

Re: Logging form after upgrade

phiw13 wrote #323881:

#18 2020-06-22 07:26:06

Re: Logging form after upgrade

colak wrote #323882:

#19 2020-06-22 08:05:20

Re: Logging form after upgrade

Bloke wrote #323883:

#20 2020-06-22 08:56:15

Re: Logging form after upgrade

phiw13 wrote #323881:

#21 2020-06-22 08:58:47

Re: Logging form after upgrade

phiw13 wrote #323886:

#22 2020-06-22 09:08:44

Re: Logging form after upgrade

Bloke wrote #323888:

#23 2020-06-22 09:08:52

Re: Logging form after upgrade

phiw13 wrote #323881:

gaekwad wrote #323887:

#24 2020-06-22 09:09:26

Re: Logging form after upgrade

phiw13 wrote #323889:

#25 2020-06-22 09:13:59

Re: Logging form after upgrade

#26 2020-06-22 09:23:58

Re: Logging form after upgrade

Bloke wrote #323892:

#27 2020-06-22 09:29:05

Re: Logging form after upgrade

phiw13 wrote #323893:

#28 2020-06-22 10:09:31

Re: Logging form after upgrade

#29 2020-06-22 10:42:29

Re: Logging form after upgrade

philwareham wrote #323896:

#30 2020-06-22 10:44:50

Re: Logging form after upgrade

Bloke wrote #323899:

Board footer