sessionWatcher (better handling of session timeouts)

Note: This replaces my short-lived storedSessions contrib. It provides the same functionality but "storedSessions" was an inappropriate name and the methods required core-file edits. sessionWatcher does not.

sessionWatcher provides serves the following purposes:

1. To return a user to the page they were on after they log in using the "log in" links (but doesn't interfere with pages that have built-in history). This is more intuitive for the user.
2. To allow a user to not have to re-type data when submitting a form after their session has timed out. This can apply to the Contact Us page, the Write a Review page, or any page that a user is required to be logged in to submit, and could conceivably take longer than 24 minutes to complete (24 minutes is the default session time-out). For example, if they are a slow typer or they get distracted. Save your customers unnecessary work and frustration!

Features:

• No core file edits!
• Simple template edits to the forms you want to save
• No security problems! (although you can create some if you try hard enough - so follow the readme)

Simple yet very effective - just what a contrib should be. Your customers will appreciate this! Actually, they won't appreciate it... but they won't hate you for not having it! Understandably, they HATE having to repeat themselves. We've all been there... you take 20 minutes to type something out carefully, hit submit and BAM something went wrong and you have to start over! Well, that can still happen from server errors, connectivity problems, or browser bugs.... but at least it doesn't have to happen from an unexpected session time out.

24 minutes is way too short in some cases. However, increasing that timeout is dangerous for obvious reasons, so the admin here don't want you to do it. That is why sessionWatcher was created... to alleviate the problems with session timeouts, while retaining the security it provides.

note As stated in the readme, you should NOT apply this contrib to forms in your checkout process! Why? I'm not sure if there is a problem with it, but there hasn't been enough testing and the results of a side-effect there could be disasterous. I would appreciate testers to try it on a NON-LIVE site though, to see if we can identify and address any issues that do creep up.

I'll post a link to the download area as soon as the contrib is active (or look yourself for sessionWatcher in the other modules category)

• Steven

Here is the direct link

Have had no time to try it out yet, but the idea is great. It will not only save my customers some frustration but me as well :-)

I hope to have some time to try it out soon, and give some feedback.

Thanks, I look forward to the feedback.

I've been testing it all day. I've got it running on every form there is that requires typing (I didn't bother on ones that are simple checkboxes like newsletter signup) and it has worked flawlessly.

By the way...

To test the functionality without waiting 24 minutes for your session to timeout... open up your DB in phpmyadmin and click on your sessions table. In the upper right, click on "Empty" and confirm. This will destroy all active sessions (so don't do this on a live site... but you shouldn't be testing on a live site anyway). This simulates timing out. After you've done that, submit the form with and without my contrib to see the difference.

I think you'll appreciate that the way it is handled with my contrib is far more friendly and intuitive to the customer than without. And its not only because their data is saved... the default method results in some pretty wonky behaviour for some forms because only a select few are programmed to go to the time-out page (most go to the login page, which can be confusing as there is no explanation). With my contrib, any page that uses it will instead be directed to the timeout page, with (of course) the option to have their data re-posted.

• Steven

Hi Steven I just installed this mod on a 1.3.6 testshop and it works great. I did not modify any of the templates yet though, so I did not test the "remember form values" part yet.

Only the information pages seem not to be remebered when logging in. Or is that related to "but doesn't interfere with pages that have built-in history"? So that is intentional maybe?

Hmm... not sure. I'll look into that. I can't see any reason why those would have their own history. However, Zen's a collaberative effort, and because of that I've noticed a lot of inconsistancies in coding. I'll report soon.

• Steven

update

Confirmed! It doesn't work on the pages linked from the Information side box. I haven't looked at the code yet, so I'll try to figure out what's causing that. Thanks Paul!

Sorry it took so long...

it seems to be that any page that has a "back" button won't work. However, since the back button typically is very buggy, its probably not a bad idea just to get rid of it.

Look for this in the respective template files:```
zen_back_link()

For obvious reasons, sessionWatcher takes a back seat if the page itself sets a navigation snapshot, and that's what is happening with the zen_back_link function.

 - Steven

Hi Steven,

that's great. The back buttons are very buggy indeed (and thus often annoying to customers sometimes), I already planned to throw these buttons out, just didn't get to it yet.

thanks!

Off-topic here... but another annoying button is the "Continue Shopping" button in the shopping cart. It is basically a "back" button too... which is stupid, because you can access the shopping cart from more places than "shopping" pages. It is made worse because during the checkout process you are given the opportunity to "edit" your cart... which is cool, but then if you edit the cart and hit "continue shopping" it takes you back to the checkout, which obviously is not where the user intended to go if they wanted to shop.

I'd suggest getting rid of it (because it is supremely redundant considering users have access to the menu/categories from every page) or hardcoding it to link to whatever page is most suitable on any given shop (probably the category listing page for most people... or perhaps the search page).

Anyway, that has nothing to do with this contrib :) Just saying.

• Steven

I just uploaded a new version. Very minor change with significant impact...

Zen 1.3.6 has a bug that makes new customers return to the account creation success page after creating an account during checkout (it should send them to the checkout page). It turns out, that SessionWatcher bypassed that bug, but introduced the exact same behaviour independently. So the newly updated version now handles that situation correctly.

• Steven

Hi Steven,

Zen 1.3.6 has a bug that makes new customers return to the account creation success page after creating an account during checkout (it should send them to the checkout page)
currently I only have this running on my testshop, not on any live shop yet. But I am hope to add it to my live shop soon, and so I was wondering: does your new version fix the formentioned 1.3.6 bug? Or would you say the bug needs to be fixed separately?

note: I had not noticed this bug yet (but I have no doubt that you are right) so thanks for mentioning it :-)

I hadn't seen the bug either until it was mentioned in the bug reports forum. Then I tested it and sure enough, same thing happened to me. But then I confused myself :) Because I realized that I had caused the problem.

So then I did a fresh install and the bug was still there - just caused differently, but same result.

Anyway... to answer your question. If you have sessionWatcher installed (the latest version) there is no need to do a seperate fix - although that fix shouldn't interfere either.

• Steven

Steven:

Just a suggestion...

I have added the following line to the top of my init_sessionWatcher.php

if (!defined('ENABLE_SESSION_WATCHER') || ENABLE_SESSION_WATCHER == 'false') return;

and executed the following sql in the patch tool:

INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added) VALUES ('Enable Session Watcher contribution?', 'ENABLE_SESSION_WATCHER', 'true', 'Enable the Session Watcher contribution?', '1', '25', 'zen_cfg_select_option(array(\'true\', \'false\'), ', now());

Which adds a config switch under My Store which is useful in those rare instances where you want to be able to disable sessionWatcher when debugging certain issues... :blush:

Hope this helps!
Jeff

Excellent idea! Thank you.

I've incorporated that into my code, but I won't upload a new version until I have more significant changes... so anyone wanting that functionality for now, just apply it as per Jeff's instructions. It will be included in the next release.

• Steven

TESTING Session Watcher & Tell-a-Friend

Hi Steven,

1. Installed latest Session Watcher 1.01 on fresh Zen Cart 1.36.
   (uploaded Session Watcher files, did the SQL patch).
2. Made the required edit in tpl_tell_a_friend_default.php
   2a. Implemented edits as recommended by JeffD in thread above.
3. Logged into a shop customer account.
4. Visited product info page and clicked Tell-A-Friend button.
   4a. Filled in Tell-a-Friend contact form filling in all form fields.
5. Let the completed Tell-A-Friend form page sit idle in browser window over night.
6. Next day clicked the form submit button.
7. As expected Zen Cart redirected browser to login page.
8. Successfully logged in and as expected Zen Cart redirected browser back to Tell-A-friend form page.
9. But all Form fields were empty and the following errors were highlighted in red at top of the tell-a-friend form page:
   Error: Your name must not be empty.
   Error: Your email address does not appear to be valid. Please try again.
   Error: Your friend's name must not be empty.
   Error: Your friend's email address does not appear to be valid. Please try again.

Using Firefox 2.0

I understood Session Watcher was specifically designed to prevent this particular situation? Thoughts on the issue? Thanks.

Woody

It does :)

If all instructions were followed correctly, the page they were sent to shouldn't be the regular login screen, but instead the timeout screen... and a modified version, at that. You should have seen something like this:

Incidentally... a MUCH faster way to test a timeout (rather than actually waiting 24 minutes) is to go into phpmyadmin and empty the table "Sessions". Obviously you don't want to do this on a live site in case you have customers currently browsing, but on a test site it simulates a time-out.

• Steven

s_mack:

Incidentally... a MUCH faster way to test a timeout (rather than actually waiting 24 minutes) is to go into phpmyadmin and empty the table "Sessions". Obviously you don't want to do this on a live site in case you have customers currently browsing, but on a test site it simulates a time-out.

• Steven

Thanks for the tips Steven. I saw that you posted the same tip previously. I was just at the end of the day so thought it would be good time to take a pause ;-)

Thanks for the screenshot. Yes I did not see the timeout screen. I will retrace my Session Watcher install steps and see what I can come up with.

Woody

Hey Steven,

Just checking if current version of Session Watcher 1.01 is completely compatible with Zen Cart 1.37, or if required any changes, or if it is now even necessary in version 1.37. That is, has ZC 1.37 been updated to include same or similar sessionWatcher functionality? Thanks.

Woody

Woodymon:

Hey Steven,

Just checking if current version of Session Watcher 1.01 is completely compatible with Zen Cart 1.37, or if required any changes, or if it is now even necessary in version 1.37. That is, has ZC 1.37 been updated to include same or similar sessionWatcher functionality? Thanks.

Woody

Can anyone please reply? I will too appreciate an answer to this question.

Thanks,
Alex