This issue affects Drupal 7.0 (current CVS HEAD) and Drupal 6.20. This and similar problems seem to be lingering issues with the caching system and forms (ie: cache_form).

What are the steps required to reproduce the bug?

  • set 'Minimum cache lifetime' to any value other than '<none>' at /admin/config/development/performance
  • begin editing or creating a node with a multi-valued field (Node 1)
  • edit and save another node of any type (Node 2)
  • press 'Add another item' on Node 1

What behavior were you expecting?

  • To get another text field after clicking 'Add another item'

What happened instead?

  • All of the text fields disappeared

Related issues described previously:

The immediate issue is that when saving Node 2, the cache is cleared causing the user's last cache flush to be updated to the current time. The 'Add another item' functionality then attempts to load the Node 1 form from the cache, but fails to do so because the form appears to be stale in the cache (see thought 1 below).

While the demonstrated bug ultimately occurs in ajax.inc -> ajax_get_form() (or in CCK's content.node_form.inc content_add_more_js() for Drupal 6), I believe this issue is actually a problem with cache.inc.

Options:

  1. When making the 'Minimum lifetime check' in DrupalDatabaseCache.prepareItem($cache), it seems like the function should take the configured cache_lifetime into account:

    Currently:

    if ($cache->expire != CACHE_PERMANENT && variable_get('cache_lifetime', 0) && $user->cache > $cache->created) {

    Should be:

    if ($cache->expire != CACHE_PERMANENT && variable_get('cache_lifetime', 0) && $user->cache > ($cache->created + variable_get('cache_lifetime', 0))) {

    This won't resolve the underlying issue, but will fix the immediate problem w/adding another item to a multi-valued field.

  2. It seems like the broader issue here is in the use of a global timestamp to store the current user's cache setting. When node.module clears the cache after saving Node 2, the system writes a single timestamp for all cache types, not all cache types are necessarily cleared:

    $user->cache = REQUEST_TIME;

    It may be helpful to make this value more granular:

    $user->cache[$this->bin] = REQUEST_TIME;

I've attached a screencast reproducing the issue and a patch for Option 1 above.

CommentFileSizeAuthor
#1 form-cache-issues-1060054-1.patch921 bytespembertona

Comments

pembertona’s picture

pembertona commented
StatusFileSize
new form-cache-issues-1060054-1.patch921 bytes

Patch for Option 1 as mentioned above.

pembertona’s picture

pembertona commented

Screencast: http://www.twitvid.com/BIGQY

pembertona’s picture

pembertona commented
Title: Form cache issues cause multi-valued fields to break » Form cache issues causes 'Add another item' to break
Status: Active » Needs review

The steps I provided to reproduce are the simplest I can break this problem down. It may seem less likely to happen when editing two nodes at the same time, etc. but is much more likely when editing node reference or image fields in modal popups, etc.

Also, the ultimate fix should be back-ported to D6.

pembertona’s picture

pembertona commented
Priority: Major » Critical

Ping. Note that if users have any positive 'cache lifetime' value set, this will break all modal modules that create nodes.

catch’s picture

catch
he/him
Primary language English
commented
Status: Needs review » Closed (duplicate)

This is duplicate of two issues:

#1079518: When one cache table is cleared, cached items from other tables invalidated

#512026: Move $form_state storage from cache to new state/key-value system

The fix here can't be committed, because the $user->cache variable exists precisely so that the current user bypasses minimum cache lifetime and gets fresh content, it just happens that it's broken.