Pretty much annoying, but D7 core hardcodes the cache_form lifetime to 6 hours:

/**
 * Stores a form in the cache.
 */
function form_set_cache($form_build_id, $form, $form_state) {
  // 6 hours cache life time for forms should be plenty.
  $expire = 21600;

  ...
}

Boost allows to cache pages for longer periods than 6 hours (admin/config/system/boost). This renders these forms invalid on Boost pages, after 6 hours of the cache entry creation.

We currently implement a custom cache class for cache_form, modifying & aligning the expire date for cache_forms to the Boost lifetime configured at admin/config/system/boost. Issue we have with this is that when the Boost cache (file) is removed, the cache_form entry remains untouched - resulting in the cache_form table growing very fast in size (up to several GB's - yes, we have a lot of forms).

People who faced this problem as well, and found a work-around? Or have another solution for the cache_form lifetime in conjunction with Boosted pages?

Comments

Anonymous’s picture

Anonymous (not verified) commented

Issue we have with this is that when the Boost cache (file) is removed, the cache_form entry remains untouched - resulting in the cache_form table growing very fast in size

That doesn't sound quite correct, surely the removal of the cached file would automatically regenerate the first time the page was visited again, and then only add one row to the table ?

I am not familiar with the cache_form interfaces

I can think of

  1. cron job to remove excess data in the table and the boost file every 6 hours
  2. excluding the form pages from boost
  3. javascript and an ajax call in the html output that would call a bootstrapped page to add the form to the expiry table (which would work creating a new entry every time the page (boosted or expired) was visited and would need to be combined with a cron job for which 6 hours seems reasonable)
rp7’s picture

rp7 commented

That doesn't sound quite correct, surely the removal of the cached file would automatically regenerate the first time the page was visited again, and then only add one row to the table ?

I'm not sure what you mean with "doesn't sound quite correct". 2 rows (form & form_state) per form & per page are added. Imagine running a site with ~10000 pages, with an average of 3 AJAX forms per page. That results in 60000 cache entries for the initial cached state.

The main culprit is that no relation is stored between the page and it's cache_form entries - the cid is solely a random hash. Deriving which cache_form entry belongs to a certain page (and thus remove it when the cached page is removed), is not possible.

#1 is what we want to avoid - our goal is to serve Boosted pages to every user at all times (we have a crawler crawling the whole site).
Since every page contains forms, #2 is a no-go.
#3 could be a possibility in our case (we can assume the user has JavaScript enabled), will investigate - thanks. However - for websites where JavaScript fallback is required...

znerol’s picture

znerol commented

However - for websites where JavaScript fallback is required...

No Javascript = No Ajax-Forms = No problem.

rp7’s picture

rp7 commented

Doh - you totally have a point there :)

rp7’s picture

rp7 commented
Issue summary: View changes

.