[18:07:59] I have tried setting my own custom key-value pair (e.g. using $this->getRequest()->setVal( 'reasonConfirm', 1 ); ), but I cannot seem to retrieve it when the page reloads. I've tried both getVal (returns null every time) and getInt (always returns '0') to no avail. Is there a special way to set your own custom variables? [18:08:18] @Krinkle @James_F (?) [18:11:44] I don't think Request objects are meant to work like that? [18:12:48] @James_F but it works for setVal('reason', 'some value'); [18:12:56] just not anything custom it seems [18:13:16] Right. [18:14:52] wondering how I could accomplish something custom in regards to @Anomie 's suggested improvements with https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/539649/ [18:14:56] to get away from using JS [18:15:12] @James_F [18:15:41] need a value to persist for at least a reload. [18:17:15] just not sure how to accomplish that within mediawiki [18:28:27] TheSandDoctor: sorry to give a drive by rather than deep help, but fundamentally for data to be passed from page load to page load it need to either be encoded into the URI of the next page (like by being a form field for a POST request or being a URL parameter), be stored in the visiting user's PHP session, or be persisted in some other data store (mysql for example) where it can be looked up on the second page load. [18:29:42] @bd808: would a “regular” PHP post request be acceptable? [18:30:05] Or work? [18:33:35] I will say "probably" mostly because I do not have the full model of how that special page works in my head. But if it has form validation for inputs then it probably already has a GET->POST cycle and you should be able to extend that to add additional validation and data collection. [18:43:59] I'll give it a try tonight. Thanks @bd808 [18:44:39] I also took a look at the code in gerrit and I couldnt see anything obvious to extend, but will take a harder looktonight [18:44:42] look tonight* [20:20:16] TheSandDoctor: setVal definitely does not work that way [20:20:50] if you have seen code like that, that was probably some horrible hack to override what other parts of the application see within the same request [20:21:41] what you are looking for are session variables, probably [20:22:03] $this->getRequest()->getSession()->set( 'foo', 'bar' ) [20:27:53] Thank you so much @tgr! [20:28:34] I’m not able to check atm, but I assume get(‘foo’): would return ‘bar’? [20:28:47] (Aka I assume get is a method too) [20:34:04] yeah [20:34:21] although during the login process this is probably not the right way to do it [20:35:04] AuthManager provides an abstraction layer for working with authentication data and handles persisting it accross requests [20:35:19] see the AuthenticationRequest class and AuthManager::getRequests() [20:44:58] What about CreateAccount when logged in? [20:45:32] Getrequest->getsession still good? [20:54:35] no, if it's a multistep form, the data needs to be passed through the form in some way [20:54:58] maybe extend UserDataAuthenticationRequest? [20:55:18] no, that's a stupid idea [20:55:42] CreationReasonAuthenticationRequest would be the one [20:58:20] What I was picturing as a replacement for the JS was the email validation. If reason was a valid email, then set a variable. If they click “create account” (or whatever the method is) again and it still validates, let them go ahead [20:58:53] How does that sound @tgr? [21:00:09] maybe you could get away with a pure-JS solution that just shows a warning for valid email addresses? [21:00:50] then you just need to define a "valid email address" ;) [21:02:53] But JS isn’t always enabled. [21:03:05] That was the concern with my initial solution [21:03:44] https://emailregex.com/ [21:04:28] given that this seems to happen about 20-30 times a year and about 1% of our users have email disabled, that seems like an acceptably corner case [21:05:13] tgr: https://medium.com/hackernoon/the-100-correct-way-to-validate-email-addresses-7c4818f24643 :) [21:05:17] the thing is, it is very easy to break all kinds of things which assume the registration form works in some very specific way [21:05:39] MobileFrontend, mobile apps, bots etc [21:08:54] TheSandDoctor: if you want to do it on the backend then I guess the least bad way would be to use AuthManager::setAuthenticationSessionData [21:09:08] which is scoped to a single auth session, unlike normal session data [21:13:11] And then getAuthenticationSessionData ? [21:13:14] @tgr [21:13:21] yes [21:14:19] AuthManager::singleton()->setAuthenticationSessionData( 'reason-retry', true ); [21:14:27] AuthManager::singleton()->getAuthenticationSessionData( 'reason-retry', false ); [21:14:31] something like that