#Info about state mismatch issues

9 messages · Page 1 of 1 (latest)

viral gyro
#

Hi All.

I've seen this issue a lot, where the state of the form as I see it doesn't match what is posted back. We can cause this by entering some information, and then navigate away, and then navigate back. I have an example, this site uses the standard login from filament:
https://beta.clublaunchpad.com/login
Enter an email address, navigate away (Forgot password link), navigate back and see the first screen shot, fill in a password, and submit, and you get the second screenshot.
Is this expected behaviour? Am I doing something wrong? Are there some docs I've missed.

Any help appreciated.

image.png image.png
rapid moonBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

viral gyro
#

If anyone is unclear what I'm on about here, please let me know. I'm keen to understand what's going on

polar fox
#

I’m wondering if it’s the browser populating the field vs livewire remounting the form? Ie, hitting back uses browser cache instead of refreshing the page.

craggy geyser
#

Can you provide the code? I suspect you are resetting the states but not doing in with a set command and so it's not handling it in the livewire form

viral gyro
#

@polar fox Well I think it's a failure to store the state. It's interesting enough that no one is saying "Oh yes, this is an issue with all forms". I subclassed the Filament\Auth\Pages\Login class and it seems to have moved on. I think maybe I should look at reworking that code. Or just doing a fresh filament app to see if it's happening there. @toeknee , I've added the code. I don't think there's much to see really. Thanks for your input, it has provided a fresh idea.

📎 Login.php 📎 login.blade.php
craggy geyser
#

Your form fill is filling it with $redirect and anything else from the url. IF you remove the $ and do [] on failure does it work as epxected?

viral gyro
#

@craggy geyser Thanks for the advice, that did not work. I did find the issue though I don't really understand exactly what it is. But somehow as I was learning I didn't pick up on the AppPanelProvider::login() function although I did see the register() one, and I added the Login class in my own way. This seems to have caused the issue, and explains why the rest of the world was happy whereas I was strugglging. Thanks for your time @polar fox thanks for your time too. So, in the end, I fixed it by reducing the Login code way down so that only the authenticate code is OOP subclassed, and that's only to remove one line so I can have users login who do not have panel access. And then I added that custom class to the AppPanelProvider::login() call.

rapid moonBOT