Given that blocks get calculated after the content of the page, it would make sense to point the user login block at the 'user' node instead of at the current page (with destination set properly) This would have 2 benefits:
1. if the page that the user is on takes a long time to generate, it doesn't get called as the user is logging in.
2. it should be possible to get rid of some code -- the code that was specific to handling the user login block form submit.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | user_login_block-point_to_user-49124-8.patch | 1.29 KB | pillarsdotnet |
| #1 | user-block-action-bug49124.patch | 1.09 KB | Wesley Tanaka |
Comments
Comment #1
Wesley Tanaka commentedComment #2
webchickI don't particularly like this, if I understand this properly... so basically everytime I logged in w/ the login block I'd be taken back to ?q=user?
But if we do that, if I'm trying to check out from a shopping cart and am prompted to login, I'll be taken completely out of the "flow" and have to go back there. That seems bad, and the performance benefit seems very small compared to the user annoyance factor.
Comment #3
webchickAlso, patch no longer applies.
Comment #4
Wesley Tanaka commentedWhat's described in #2 does not happen. From a user's perspective, the behavior is exactly the same, but the code to run your shopping cart page gets run once (post-login) instead of twice (during login and then post login again)
Comment #5
Wesley Tanaka commenteds/code to run/code to generate/
Comment #6
ricabrantes commentedany news about this?
Comment #7
Jaza commentedMoving.
Comment #8
pillarsdotnet commentedRe-rolled; needs testing.
Comment #10
drupal_was_my_past commentedI agree with webchick in #2 on this. I think that being sent off to /user when logging in using the login block is bad user experience. In addition, even were I to think that this was good user experience, patch in #8 doesn't achieve the desired result. It causes an error where you are sent to /user without being logged in.
I think we should mark this closed (won't fix).
Comment #11
bleen commentedI have to agree with webchick (#2) and rocket_nova (#10)
As further evidence that this should be "wont fix" I'd like to point out that this benefit statement from the original post
is completely arbitrary. Who's to say that the /user page wont be the heaviest page on the site?
Comment #12
Wesley Tanaka commentedThe original issue was one of where the POST goes when the user presses the log in button -- does that POST go to /user or does it go to the page that the user is currently on. In either case, the user should get redirected back to the page that they're already on.
Comment #13
Everett Zufelt commentedAs this is a performance bug, can we please get some data to support the assertion that the proposed solution improves performance?
Comment #14
bleen commentedEverett - as I said in #11, the claim that this is a performance bug is completely arbitrary. If you log in (using the login block) while on an extremely heavy page, then the login process will be slow because the page you're on will be reloaded. On the other hand, if your /user page is extremely heavy then the proposed solution is just as bad in terms of performance.
I think its safe to mark this is "wont fix"....
Comment #15
bleen commentedWeird .. my response to Everett is missing but the status change I made remains ... Anyway, my response was something along these lines:
Everett, as I said in #11, the claim of a performance bug here is completely arbitrary. If a user logs in (using the login block) while on an extremely heavy page, then the login will seem slow because the page needs to reload. On the other hand, if the /user happens to be an extremely heavy page, then the solution offered in this issue will cause *all* logins to be slow.