Multipage form

[weaver]

On a multipage form (a bit of a long one, actually) how much time does a user have to fill it out before their session times out?

The behavior I'm getting is on some submissions with only the last page or two filled out, while other submissions have every page filled out. (Example, some submissions have pages 1-7 recorded in the database, but others only pages 6-7.) I've already ruled out users skipping the first few pages.

Any thoughts?

[Ben]

Hey Weaver.

Curious! You're using the API? The API works by submitting all the content to Form Tools on each page as the user progresses through the form, so the DB would be updated in stages. I guess it's possible that sessions are being garbage collected at step 6, but it seems like it would create a new submission ID for the user...

One thing to check: look at your database through phpMyAdmin or something like that & look for non-finalized submissions. If sessions are timing out you should see old unfinalized submissions in your form table that match the submissions that only have pages 6 & 7. In other words, look for submission IDs that are slightly lower (by say 1-5) than the submissions that have only 6 & 7 filled in. If you can see information for a single submission spread across two submission IDs, then yes, it sounds like sessions being emptied is at fault.

Assuming this is the problem, try adding this to the top of your form pages

PHP Code:

ini_set('session.gc_maxlifetime',7200); 


That will attempt to set the session timeout at 2 hours. Not all servers allow for this, but it's worth a shot!

- Ben

[weaver]

I can duplicate the error now by filling out the first page of a multipage form, letting the browser window sit overnight, and then finishing the rest of the pages and submitting. The result is only the most recently filled out pages.

I'm thinking this means my sessions are expiring, then a new one is getting created when I proceed to fill out the rest of the form.

I'm working on doing two things right now:
1) make sure database sessions are being used (since there seems to be a problem with the way my server handles file-based sessions)
2) Make sure the sessions are persistent, so a user can leave the window up as long as they want and when they finally finish everything will be submitted.

[Ben]

Yes, that definitely sounds like it's the cause.

I'd try that option I posted as well. If your server accepts it, it will extend the lifespan of a session from whatever the default value is. 2 hours should be sufficient! Plus bear in mind that the 2 hour limit will only be from the last time the server got any activity in that session. So technically, the user could take 1 hour 59 minutes to fill in each page & still use the same session.

Anyway, good luck with this!

- Ben

[weaver]

One thing to check: look at your database through phpMyAdmin or something like that & look for non-finalized submissions. If sessions are timing out you should see old unfinalized submissions in your form table that match the submissions that only have pages 6 & 7. In other words, look for submission IDs that are slightly lower (by say 1-5) than the submissions that have only 6 & 7 filled in. If you can see information for a single submission spread across two submission IDs, then yes, it sounds like sessions being emptied is at fault.

Good call...that is exactly what I'm seeing in my database.

---

When I look at the sessions table in my database, I don't see anything new created when I start filling out a form.

Started looking at this function in api/api.php

PHP Code:

/**
 * Initiates sessions. The session type (database or PHP) depends on the $g_session_type var
 * defined in the users config.php (or default value in library.php);
 */
function ft_api_start_sessions()
{
    global $g_api_header_charset;

    session_start();
    header("Cache-control: private");
    header("Content-Type: text/html; charset=$g_api_header_charset");
} 


How does it depend on the $g_session_type var? Looks like it should really just include the code in session_start.php

[Ben]

Hey Weaver,

The $g_session_type variable is currently only used internally - for the Form Tools admin section. The API still relies exclusively on PHP sessions. That'll be updated at some point.

- Ben

[weaver]

Hey Weaver,

The $g_session_type variable is currently only used internally - for the Form Tools admin section. The API still relies exclusively on PHP sessions. That'll be updated at some point.

- Ben

Here's my update to use database sessions in the API...seems to work.

PHP Code:

/**
 * Initiates sessions. The session type (database or PHP) depends on the $g_session_type var
 * defined in the users config.php (or default value in library.php);
 */
function ft_api_start_sessions()
{
    // old method...
    //global $g_api_header_charset;
    //session_start();
    //header("Cache-control: private");
    //header("Content-Type: text/html; charset=$g_api_header_charset");
    
    global $g_session_type;
    global $g_session_save_path;
    
    // Copied and pasted from global/session_start.php         --brw
    if ($g_session_type == "database")
         $sess = new SessionManager();

    if (!empty($g_session_save_path))
        session_save_path($g_session_save_path);

    session_start();
    
    header("Cache-control: private");
    header("Content-Type: text/html; charset=utf-8");
} 


I also added this line to config.php

PHP Code:

// Number of seconds before a session timeouts.
$g_default_session_timeout = 604800; 


and these lines to write(...) in sessions.php

PHP Code:

global $g_default_session_timeout;
$life_time = $g_default_session_timeout; 


Which gives me a week timeout. Since gc() is overridden in sessions.php, it should give me the full week. (I know it works overnight at least...)

As a final safety measure, it would be great to double check that the session id hasn't changed across forms, and if it does, to throw out some sort of error to the user that they should start over.

BTW, Your code is well written, which makes it pretty easy to trace through and update without breaking things. Nice work!

[Ben]

Nice! Thanks for posting your code - I'll include that in an upcoming release of the API, if that's okay.

- Ben

[weaver]

Nice! Thanks for posting your code - I'll include that in an upcoming release of the API, if that's okay.

By all means!

You may want to rename the timeout global though, since that will only work with database sessions.