Ticket #29 (defect)
Opened 2 years ago
Last modified 1 year ago
track down the late flash messages
Status: assigned
| Reported by: | grahack | Assigned to: | grahack (accepted) |
|---|---|---|---|
| Priority: | major | Milestone: | 1.1 |
| Component: | ui | Version: | 1.0.3 |
| Keywords: | flash redirect | Cc: | |
A problem that we see in FAL sometimes: a flashmsg is set, but no redirection is made. The message is then displayed one request later.
We'll have to track them...
And what if FAL_flash is off? I should have use FAL_flash_deny instead.
Now it may confuse the webmaster: FAL_flash doesn't disable ALL flash messages....
Change History
05/11/07 07:47:50: Modified by danfreak
05/18/07 17:03:57: Modified by grahack
No, won't solve.
What you sometimes did: you wanted to send a message to the user, you stored the message for the NEXT request, but then, you just loaded the view, within the same request processing.
What works is doing a redirect after setting the flash message.
05/22/07 16:09:44: Modified by grahack
- status changed from new to assigned.
- owner changed from danfreak to grahack.
- type changed from task to defect.
What I found in rev 242 (I'll work on these tomorrow)
note: x don't use flashMsg();
- admin/admins line 135
- admin/users line 134
- FAL_lib at lines
- 458 x (strange section)
- 471 x
- 552 x
- 647
05/23/07 09:50:30: Modified by grahack
- admin/admins line 135
- admin/users line 134
are fixed: now display a CI error (see [244])
05/23/07 09:52:57: Modified by grahack
sorry, in [244], there is also a change in the indentation
05/23/07 11:29:39: Modified by grahack
- milestone changed from 1.0.5 to 1.1.
in the FAL_lib
- line 458 is ok now, since redirection is done in FAL_front if TRUE is returned
- lines 471 552 647 now use the new flashsg() function (see [247]) BUT ARE NOT FIXED
no redirection is done at all, so the message will still display a request after the next request
Anyway, this may never appear since our FAL_validation do tests BEFORE, preventing us to have those bad cases we want to give notice about (see forgotten_password process, and I'm pretty sure it's the same in the login and register processes).
Well, the late flash messages are tracked now (three FIXME comments in FreakAuth_light). We can finish to fix this later, I move this ticket to 1.1
We must find them!
Well we must investigate further in the Db_session handling of FlashMessages? and n particular on the methods
According to Db_session library comments, keep_flashdata($key), "keeps existing "flash" data available to next request". Will this solve the problem?