To contradict the accepted answer given by Mołot , I'll note that hacking core to change this expiry-time is not necessary; I was able to achieve this using a database-trigger. (I actually increase the expiry-time by 18 hours in the code I show here, but you can modify it to suit your needs).
Note that you will need to check settings.php to determine what <PREFIX>
should actually be below.
If the connected database is MySQL:
delimiter //
CREATE TRIGGER form_state_lifetime_hack BEFORE INSERT ON <PREFIX>_cache_form FOR EACH ROW
BEGIN
SET NEW.expire = NEW.expire + (18*3600);
END;//
delimiter ;
For PostgreSQL it would be more like:
CREATE OR REPLACE FUNCTION form_state_lifetime_hack() RETURNS trigger AS
$$
BEGIN
NEW.expire = NEW.expire + (18*3600);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER form_state_lifetime_hack BEFORE INSERT ON <PREFIX>_cache_form
FOR EACH ROW EXECUTE PROCEDURE form_state_lifetime_hack();
Note also that Drupal stores data for both $form
and $form_state
variables in cache_form
, so you might want to add an IF
block within your trigger, depending on which one you want to target. You can do this based off of the "cid"
column:
+-------------------------------------------------------------+
| cid |
+-------------------------------------------------------------+
| form_form-bCxaf_A-P5-IRAmXv6K7gadd0zFF3C-UoLsIyovQMvI |
| form_form-VV8a20AjZHWE9TkhXb1urlNNjzLmnibHulO3oH8QJiw |
| form_form-ZQGYHDpBMqrNsQlxDoVovuiqcH_oVduYHnaqf4VijAI |
| form_state_form-4mn85-8W5mDpsqXcTVHNsNy2Jk5G20onUt1CgropnY8 |
| form_state_form-ZQGYHDpBMqrNsQlxDoVovuiqcH_oVduYHnaqf4VijAI |
+-------------------------------------------------------------+
In an ideal world, changing this expiry-time could be done in a more native way using db_update()
from a hook_form_alter()
or hook_submit()
implementor-function, but unfortunately these calls occur before calls to form_set_cache()
, meaning the relevant row you want to modify won't yet be present.... even if it were, you wouldn't have the new build-ID which would allow you to identify it.
For modules you plan to distribute to others, you'd need to include the appropriate CREATE TRIGGER
language in the your_module_name.install-file, and decide which SQL-flavor to use based off of the local settings.