From some days ago, this error

"An unrecoverable error occurred. This form was missing from the server cache. Try reloading the page and submitting again."

Appears every time y try to upload a file, I have try it whitout any kind of cache but the error is still here.

Please, someone can help me?

Members fund testing for the Drupal project. Drupal Association Learn more


quicksketch’s picture

This means that your server is not properly storing entries in the "cache_form" database table. If you're using MemCache or CacheRouter, they are likely misconfigured and not saving forms properly into the cache_form table/bin. FileField (and nearly all other AJAX requests in Drupal) are dependent on the cache_form table for security reasons. This table is used regardless of any cache settings you have anywhere in Drupal.

ahurtado’s picture

Thankyou very much for your reply.

What can I do if I dont use memcache or CacheRouter?

quicksketch’s picture

Make sure that your cache_table table exists and that there are entries in it. You might try emptying the table (it's all temporary storage) and visiting the node form. It should make a row in that table just by visiting the form. You might also try turning on Upload module even if you don't use it. This might trigger the form being stored in the cache. If this is the case, then it may be similar to other bug reports we have received.

tomlobato’s picture

I get this error when uploading images, but this happens only in IE (any version).
I didn`t find the 'cache_table' on my db, but only these:


Also, I do not use cache router ou memcache. My Upload module is enabled.

I tried some fixes suggested in another forums, as
$form['#cache'] = TRUE
in hook_form_alter. It stops the error message but hide the image form after sumitting.

I hope to contribute with theses symptoms for the resolution and I hope a light too.

quicksketch’s picture

Sorry I meant "cache_form" table, not "cache_table".

c_archer’s picture

Version: 6.x-3.2 » 6.x-3.3
Assigned: Unassigned » c_archer

I have the same problem, it seems to have started appearing after upgrading from filefield 6x-3.2 to filefield 6x-3.3. I am able to add a file by selecting the file then hitting save instead of upload, but once its uploaded I can't remove it.

tomlobato’s picture

My version is 6x-3.2.

AlanAtLarge’s picture

I have the same issue on both my local test server and my host.

Uploading images worked fine on both so it broke on one of the the upgrades.

I'm currently on ImageField 6.x-3.7, and the only user trying to do updates.

A workaround for me was to set Minimum cache lifetime to

sp_key’s picture

'Minimum cache lifetime to' to what? :)

sp_key’s picture

Hi quicksketch,

Many thanks for your support in trying to solve this issue for us.
I did what you suggested above; emptied the table, revisited the form and tried to upload an image.
As a result, I got the below field in my cache_form table:

Value: form_form-26217cc0a9a590e6a2113a74abcc5d79
expire: 1283649957
created: 1283649957

I can see 'created' and 'expire' values are identical, is this any useful information?

Like others, I don't use memcache or cacherouter neither do I have any cache optimization set up as I'm working on a staging version.

ispboy’s picture

Oh yeah~ I've found the key!

it's the problem of cacheroute(apc), when changed to cacheroute(memcache), no any error !

ari-meetai’s picture

popup_filter.module -

line 82: function popup_filter_form_alter($form, $form_state, $form_id){return;

...for now.

sp_key’s picture

How strange... I don't have the popup module, or cacheroute or memcahed or any cache optimizations on! This is an evil bug!

quicksketch’s picture

As a result, I got the below field in my cache_form table:

Value: form_form-26217cc0a9a590e6a2113a74abcc5d79
expire: 1283649957
created: 1283649957

I can see 'created' and 'expire' values are identical, is this any useful information?

There is something wrong here. These values should be 6 hours (21600 seconds) apart. In my cache_form table I have value such as this:

created: 1283639806
expire: 1283661406

That said, I have no idea why the created and expired times would be the same on your set-up.

sp_key’s picture

Great, thanks - at least I know whereabouts to look. Any ideas what kind of tests I should do further?

quicksketch’s picture

It's complicated to sift through all the code, but I'd try following the code stack within form.inc and cache.inc to see why this could be happening. You should also make sure that cache.inc is actually being used and not swapped out with some other cache handler. You don't actually need to use a module to swap it out, you can specify one directly in settings.php.

antgiant’s picture

Version: 6.x-3.3 » 6.x-3.7

In my research I have found that you can duplicate this by setting Minimum Cache Lifetime to some value and attempting to add a file to a piece of content via the Ahah method. Disabling JavaScript or setting Minimum Cache Lifetime to fixes the problem. In my searching it appears to be a core bug relating to the page load differences between an Ahah page load and a normal page load. Sadly that puts solving the problem beyond where I can track. Hopefully someone else can track it down and get it fixed. Here are some issues I believe might be related to the same problem.

blouhwtf’s picture

Assigned: c_archer » Unassigned
Category: support » bug

I have that same problem when trying to use the "reference existing" option. When clicking "select", the error message was displayed.
Debugging showed me where the problem was (at least for me).

In cache.inc / function cache_get

    // If enforcing a minimum cache lifetime, validate that the data is
    // currently valid for this user before we return it by making sure the
    // cache entry was created before the timestamp in the current session's
    // cache timer. The cache variable is loaded into the $user object by
    // sess_read() in session.inc.
    else {
      if ($user->cache > $cache->created) {
        // This cache data is too old and thus not valid for us, ignore it.
        return 0;

But I'm not sure why this happens...

antgiant’s picture

That is exactly what I found as well. For some reason an AHAH or AJAX page load does not properly set $user->cache so everything is always marked as expired. However, I utterly failed to find where $user->cache was supposed to be set much less why it wasn't set.

quicksketch’s picture

Are you guys using Memcache or Cache Router on your site? It sounds like your sessions aren't being handled properly. Even if this is a bug, I don't think it's one in FileField, since all cache handling is done for it by Drupal core or other modules that provide cache and session handling.

antgiant’s picture

For me Core Caching is all that is used. No Memcache no Cache Router. Nothing.

blouhwtf’s picture

Same as antgiant. Except I use Panels cache but i think it's using its own cache system ? And there is no way that i know to disable Panels cache easily on my dev environment. I tried to clear all cache with drush and remove useless data in the database though but it didn't help.

The problem occurs on my dev website, which has no cache enabled (except the panels one). The live one is working well with all kind of caches enabled. But still frustrating not being able to add some content on the dev one... Maybe drupal doesn't handle so well to go from cache settings enabled to cache settings disabled because that's what happen when i import the live database in my dev website ? I'm just guessing as i have no clue actually.

But I agree with quicksketch it doesn't seem a bug from filefield.

v77’s picture

Same problem here. I upload an image and i get the error "An unrecoverable error occurred. This form was missing from the server cache. Try reloading the page and submitting again."

This error does NOT occur when i'm logged in with the admin account. I'm not using MemCache or CacheRouter.

mikeytown2’s picture

subscribe; same error.
if I use

$conf['cache_inc'] = './sites/all/modules/memcache/memcache.db.inc';

then it works

If I use

$conf['cache_inc'] = './sites/all/modules/memcache/memcache.inc';

then its broken.

using 1.16 http://drupal.org/project/memcache going to try 1.17.. 1.17 doesn't fix this

bleen’s picture


I am using a fairly recent version of memcache module (dev branch) and some of my users are getting this error, but not all

In settings.php:

$conf['cache_inc'] = './sites/all/modules/memcache/memcache.inc';
dadderley’s picture

Hi all.
I just ran into this and found what was causing it in my case.

Filefield 6.x-3.7 was working for me.
Then I installed Popup 6.x-3.1

Filefield 6.x-3.7 stopped working for me and produced this error message:
"An unrecoverable error occurred. This form was missing from the server cache. Try reloading the page and submitting again."

I un-installed Popup 6.x-3.1 (without clearing any caches).
Filefield 6.x-3.7 started working again.

This is a dev site. I do not have Drupal's caching turned on.
I am not using Memcache or Cache Router.
Hope this info is useful for debugging.

Fidelix’s picture

Well... i'm having this problem and i dont have Popup module installed.

I dont know what to do anymore...

grincon’s picture

To me it turned out that my Performance settings were giving me trouble. I had changed caching mode to disabled, from enabled and Minimum cache lifetime set to 15 minutes. When I changed Minimum cache lifetime to none and "cleared cached data" the error was gone. I did not try to re-enable but I assume you have to be careful to keep these 2 in sync.

I hope this helps you guys out there.

German Rincon

Fidelix’s picture

It is VERY obvious that disabling cache will make the error go away. No need to comment that.

There is no need to change cache lifetime, if caching is disabled, this setting is irrelevant. However, no sane administrator, with a reasonable amount of pageviews per day, would be crazy enough to run the site without caching.

quicksketch’s picture

It is VERY obvious that disabling cache will make the error go away. No need to comment that.

It's actually not that obvious at all, since the cache setting at admin/user/performance is generally only for caching of entire pages for anonymous users. Those settings for for the "Page cache", not all caching in all of Drupal. Drupal does a significant amount of caching at all times that administrators are never allowed to turn off, including the form caching that FileField uses. Disabling the page cache should have nothing to do with the form cache, so it's actually rather interesting that it would have any effect.

The most helpful thing here would be a set of instructions on how to reproduce this problem starting with a fresh installation of Drupal. If I can reproduce the problem I can fix it, but right now only a few people are having this problem while most people are not, and no one knows how to cause it (other than the users who are having memcache/cacherouter problems, which FileField is unable to account for).

Fidelix’s picture

I do have memcache enabled, so maybe the problem isnt with filefield.

But it only happens when using a filefield widget, so i'm really not sure what or where to report.

mikebann’s picture

why do only some people get this error? I'm going through the nivo tutorial and after uploading the image I get this error. But lots of peeps son't get this error. how can it be a core issue. Has anyone found a fix?

also I run a site that gets a lot of hits with cache disabled and haven't had an issue yet. I do it because I need to support mobile tools and switch the them based on devices. hasn't choked yet. It also didn't solve the getting this error when trying to upload images

bleen’s picture

mikebann: It seems like (one of?) the main cause of this error is the cache_form table is being cleared *after* you have started filling out the form, but *before* you hit the "upload" button associated with your filefield (or the form submit button).

One of the causes of that can be the way you have configured memcache (etc...). But just as easy would be if you (for example) set up a cron job that clears the cache every n minutes. I would focus your efforts on figuring out when/why/how your cache is being cleared and/or not being set correctly.

guysaban’s picture

Interesting. I was working with a co-worker and he experienced the issue while I did not.

I was logged in as User 1 on a Firefox browser. No problems. Yet he got the error while using Firefox even as User 1. But when he tried Chrome he did not get the problem.

cedarm’s picture

Just figured this one out for our case. A filefield upload POST would fail similarly if cache tables were flushed (via devel), or even when some other user just saves a node (making the problem appear at "random"). Could not reproduce the problem when memcache is not used.

Solution: fix memcache_bins config. We had our memcache_bins configured incorrectly with bin names like 'form' and 'filter', and should have been 'cache_form' and 'cache_filter'. Works fine now. We're running memcache 6.x-1.4 (time to update).. not sure if this would happen with 6.x-1.5 or later.

BTW, from what I can tell the 'session' and 'users' bins are correct and should not be prefixed with 'cache_'. Memcache docs could be a little better here.

Fidelix’s picture

I was using latest version of memcache... rolled back to 1.5 and it's working so far.

abhinya’s picture

hi, i started getting this problem when i create custom fields under content types. the new types that i create are having this issue.
the two fields that i created are file fields.

marketacumen’s picture

This "bug" happened to me as well and the primary reason behind it was that caching was misconfigured. And to add to that, I'm not using memcache, or any of the other modules that are mentioned above.

Somehow in my sites/default/settings.php, this line was added:

$conf['cache_inc'] = 'includes/cache-install.inc';

Which effectively disables the cache, and the filefield_js requires some form of caching at a minimum.

You can also "SELECT * FROM variable WHERE name='cache_inc'" to see if it's a database setting as well.

In short: It's caching. Had to pull it up in a debugger to finally find it.

If you want to see if it's the issue, just rename "includes/cache-install.inc" to something else and see if it breaks the site (obviously, don't do this on a production site!)

The fix is to remove the line above from settings.php, or

DELETE FROM variable WHERE name='cache_inc';

Good luck.

quicksketch’s picture

Version: 6.x-3.7 » 6.x-3.9
Category: bug » support

Yeah I'm not sure how this keeps getting put in the bug report category. It may be a bug, but it's not one caused by FileField.

tic2000’s picture

Some users on a site I work on got this error too.
In my case the error it's kind of normal.
We allow very large file uploads. While with my home connection it took me 45 minutes to upload a 1.36Gb file when I was in Switzerland that took forever. When I tried to upload the same file on YouTube it said 14 hours. Any upload that takes above 6 hours will generate this error (6 hours being the hardcoded expire time set in form_set_cache).

Isn't any way for filefield to change the expire time at least when uploading using javascript?
For now I increased the form cache expire to 24 hours, but that means that all the forms will use that expire time and that I have to change that value every time I upgrade drupal.

timl’s picture

if you use memcache, this should resolve your problem (it did for me)

Here is an example configuration where the 'cache_form' bin is set to bypass
memcache and use the standard table-based Drupal cache by assigning it to a
cluster called 'database'.

$conf = array(
  'memcache_servers' => array('' => 'default'),
  'memcache_bins' => array('cache' => 'default',
                           'cache_form' => 'database'),
bleen’s picture

The suggestion in #41 is correct ... just make sure you are using the most recent version of the memcache module, otherwise that code will not work

tyjamessmith’s picture

Any luck on a server that doesn't have anything beyond the normal cache enabled?

rwhite’s picture

Also experiencing this problem on a server without memcache or cacherouter.

enjoylife’s picture

Also appears this problem on a server without memcache or cacherouter.

Narek’s picture

41. solved

eric.chenchao’s picture


gateway69’s picture

yea I also just ran into this.. im using project mercury (pressflow) and all its goodies, at the bottom of my settings file I found this

# Mercury Settings
# Alter With Caution :)
# Varnish reverse proxy on localhost
$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = array('');

# Memcached configuration
$conf['cache_inc'] = './sites/all/modules/memcache/memcache.inc';
$conf['memcache_servers'] = array(
     '' => 'default',
     '' => 'menu',
     '' => 'filter',
     '' => 'form',
     '' => 'block',
     '' => 'update',
     '' => 'views',
     '' => 'content',
     '' => 'apachesolr',
$conf['memcache_bins'] = array(
      'cache'    => 'default',
      'cache_menu'   => 'menu',
      'cache_filter' => 'filter',
      'cache_form'   => 'form',
      'cache_block'  => 'block',
      'cache_update' => 'update',
      'cache_views'  => 'views',
      'cache_views_data'  => 'views',
      'cache_content'  => 'content',
      'cache_apachesolr'  => 'apachesolr',

after switching

 'cache_form'   => 'form',


 'cache_form'   => 'database',

all seemed to work for me.

bserem’s picture

In my case the cache_form table needed repairs.
I suggest to everybody to check this first if they are not using memcache/cacherouter.

mr.j’s picture

Quoting myself on a related ImageField issue here:

I can reproduce this by editing nodes in multiple tabs. Go to a node list somewhere and click the edit links on several of them to open in multiple tabs. Once you have uploaded an image (or file in this case) to one and saved it, the upload of images to the others will fail every time until you reload their pages.

The kicker... it happens without using memcache or cacherouter, and with core page caching disabled. The same tabbed editing scenario works fine if the forms do not have an ImageField or FileField on them. Is it possible that core has a per-user form cache that is cleared after each form submission?

quicksketch’s picture

Once you have uploaded an image (or file in this case) to one and saved it, the upload of images to the others will fail every time until you reload their pages.

Note that this probably isn't a significant problem, because even if the upload did work, you wouldn't be able to save the node because Drupal will throw an error that saving the node is not possible because it has been edited by another user. Drupal does not allow users to edit the same node at the same time.

mr.j’s picture

They are different nodes, not the same node. Its easy to reproduce:

1. Click edit on several different nodes (that have FileField or ImageField on them) and open them in tabs / new windows.
2. Upload a new image or file and save the node in the first tab.
3. Repeat step 2 for the nodes on the other tabs. They will all fail with this error message until you manually reload their edit pages.

That is with a single user. I have just tried the same scenario only using multiple users with different browsers editing different nodes at the same time and there is no problem.

So it seems whatever causes the form cache to invalidate is user-specific.

cedarm’s picture

That sounds just like what I described in #35, but fixing the memcache config fixed it for us. I'm puzzled since you're not using memcache.

bserem’s picture

have a look at my reply in #49

mr.j’s picture

Thanks bserem but that doesn't help in my case. I can reliably reproduce this on both my dev and production environments after all tables have been repaired and optimised. And I have worked out why it happens.

Here is my procedure to reproduce:

- List content page at admin/content/node/overview
- Empty the cache_form table
- Click edit on node 1 (in new tab)
- Click edit on node 2 (in new tab)
- cache_form table now has 2 records
- Upload an image to an ImageField on node 2 and click Save.
- Node 2 is updated correctly with the new image.
- The same 2 records are still in the cache_form table.
- Now switch to the edit page for node 1 and attempt to upload an image to it and immediately get the error message.

I was expecting to see the cache_form records change (or be deleted) after uploading the first image and saving but they did not. This suggests the "form was missing from the server cache" error is not correct. So I debugged a bit and found out that cache_get fails on this block and returns 0 instead of the cached form:

    // If enforcing a minimum cache lifetime, validate that the data is
    // currently valid for this user before we return it by making sure the
    // cache entry was created before the timestamp in the current session's
    // cache timer. The cache variable is loaded into the $user object by
    // sess_read() in session.inc.
    else {
      if (isset($user->cache) && $user->cache > $cache->created) {
        // This cache data is too old and thus not valid for us, ignore it.
        return 0;

The only place $user->cache is set is during cache_clear_all() when it is called without a cache id.
So what happens is this:

- I edit node 1, upload an image and save, which works fine.
- node_save calls cache_clear_all(NULL, 'cache_page') in an attempt to clear the page cache if the cache lifetime has expired.
- That sets $user->cache to the current time which invalidates every cache (even in the non-page cache tables) for the user that was generated before cache_clear_all was called.
- I edit node 2 and attempt to upload an image and it fails as the caches for my user all fall into that code block above in cache_get that returns 0.

That is with page caching enabled. I am sure I have also seen this before with page caching disabled, which would be very strange as the $user->cache code should never be hit then.

The only thing I can think of to solve this is to stop using the cached form on the ajax request and build it manually instead, otherwise core's caching process is always going to win the fight.

mr.j’s picture

mikeytown2’s picture

mattwmc’s picture

Happening for me, too.

Using cacherouter.

Here's the settings.php code. Any ideas what to fix?

$conf['cacherouter'] = array(
    'default' => array(
    'engine' => 'apc',
    'servers' => array(),
    'shared' => TRUE,
    'prefix' => '',
    'path' => 'sites/default/files/filecache',
    'static' => FALSE,
    'fast_cache' => TRUE,
N00bPr0grammer’s picture

Hi all,

I experienced this problem when uploading an Image to a node. Luckily for you, i am a programmer, and this is what fixed it for me:

in the imagefield module, open 'imagefield.module'.

Go to the function : function imagefield_form_alter(&$form, $form_state)
(if it doesnt exist, you can create it)

Then add this code:
if( $form['#id'] == 'node-form' ){
$form['#cache'] = TRUE;

This code checks whether you are editing a node, and if so, it manually enables the cache. So far it works perfectly for me. PM me anytime you have a question about this issue.

mikeytown2’s picture

Status: Active » Needs review
375 bytes

Should be filefield_form_alter() in filefield.module.

Here is a patch based off of comment #59. Note that this patch has not been tested by me and according to #4 it might not be the best idea.

manxian’s picture

I am running filefield 6.x-3.10 (I realise this issue is logged for 6.x-3.9).
Symptoms are exactly as described.
Not using memcache, MySQL max_allowed_packet = 100M (for test purposes).

I can reliably produce/remove the error as follows:
I have a form with two fields:
- field_a : the file upload field
- field_b : field of #type = 'markup' which is populated using node_view(...) i.e. the teaser of a node is put into it.
In this case the file upload field shows the error whenever an attempt to upload is made.

BUT if I do not populate field_b i.e. do not call node_view(...) the file upload works correctly.

Applying patch #60 corrects the problem.

Can anyone tell me the risk of applying the patch or what it is effectively fixing? Just want to know what my exposure to any other problem may be.
Is there a reason the patch was not applied in 6.x-3.10?

Thanks to everyone for their work and mutual support.

quicksketch’s picture

Hm, interesting thanks @manxian for your feedback. I wonder if #60 would fix this problem for many people. I'm afraid of breaking more sites that it would be fixing. Anyway, it's an interesting option. Any one else experiencing this problem I'm curious if #60 solves the problem.

geberele’s picture

#41 works for me! Thanks

pwolanin’s picture

Version: 6.x-3.9 » 6.x-3.x-dev
Issue summary: View changes
Issue tags: +Needs issue summary update

Anyone willing to dive in and see if there would be negative side effects to this? I don't see why there would be except I'm not sure what the interaction with anonymous users would be. Please update the issue summary.

The #cache key isn't even documented: https://api.drupal.org/api/drupal/developer%21topics%21forms_api_referen...