CCK Add Another Item causes fields to disappear

We're getting similar results with both tinytimymce and plain text fields.

a. We set a field number to unlimited
b. Two fields are presented (by default)
c. We click on the "Add more items" button
d. The two original fields disappear, along with the field label.

We've replicated this behavior with Zen, Garland and Bluemarine themes.

We're using RHE5 w/php 5.2: could there be something involving the underlying configuration of our server that's causing this?

Here's a new clue: it works on our dev server (CentOS), but not our production server, with exact same templates and seemingly corresponding drupal configuration.

We're also seeing this intermittently. I've done a bit of debugging, and it appears that when you click 'Add another item', there's a POST request to /content/js_add_more/article/field_internal_links. Most of the time this replies with several kilobytes of JSON. However, so far in June we've had 83 erroneous responses out of a total of 308 requests (and they're not distributed evenly). The erroneous response is just 14 bytes long, and is: { "data": "" }

I wonder if there's some sort of rebuilding going on which is only encountered occasionally.

Has anyone found a resolution to this / can suggest where I should go to debug this further?

Are you guys using memcache?

I believe it's a problem with using memcache for the cache_form table.

A project I am working on is reporting this issue but I have yet to be able to reproduce it.

To my knowledge we are not using memcache

But for those that can..

The part that is returning that empty data is likely in content_add_more_js
These will return empty data
1) Field is not multiple
2) $_POST['form_build_id'] is empty
3) form cannot be retrieved from form_get_cache based on the form_build_id

// Retrieve the cached form.
$form_state = array('submitted' => FALSE);
$form_build_id = $_POST['form_build_id'];
$form = form_get_cache($form_build_id, $form_state);
if (!$form) {
// Invalid form_build_id.
drupal_json(array('data' => ''));
exit;
}

?>

My guess is that number 3 is the issue; the cache is being cleared or invalidated somehow between adding this field.

Cache get is http://api.drupal.org/api/function/cache_get/6 what is getting the form from the field
My guess is that my problem derives, at least, from

 if ($user->cache > $cache->created) {
        // This cache data is too old and thus not valid for us, ignore it.
        return 0;
      }

Since the cache_flush is not on and CACHE_PERMANENT is not the expire on the form. Or the cache data has been deleted.

That $user->cache variable might be being resaved or the cache cleared in general in a call to cache_clear_all http://api.drupal.org/api/function/cache_clear_all/6

Question to those that can reproduce this, can you submit the form that has had fields disappear?

Jody - we are using memcache. Is there anything further I can debug here?

Hefox - do you think that the problem might be that some other user of the site performed an action that triggered a cache_clear_all at the same time as the first user was attempting to add another item?

rtsh: Attached is the patch we're using to exclude cache_form from memcache. I find lots of reports of people having problems with cache_form in memcache, but am not sure if there is an easier way to exclude it. cache_form is not a proper cache table because if it gets cleared problems arise, hence it's not really a true cache. So it's sort of a deeper Drupal core issue.

If you're not using memcache you can still run into problems like you're saying, perhaps if cron runs and clears your form cache, or some other action that clears form cache.

rtsh, that is the only thing I can think of; or something made it seem like the cache was cleared. That is why I was wondering if forms can still be submitted without the field, ie is the form still valid in cache after the failure? To my understanding, validation only works on valid form ids gathered from cache, but I could be wrong (drupal execute being able to submit makes me think I'm wrong).

I wish I could reproduce this to try and fix it, but no luck so far! :(. I've tried clearing cache, starting new Add soso, and tons of fields, rapid clicking, etc. but to no luck so far.

Hefox - do you think that the problem might be that some other user of the site performed an action that triggered a cache_clear_all at the same time as the first user was attempting to add another item?

I can reproduce the disappearing fields by clearing the cache (through truncating every cache table). However, the bug I see when clearing the cache is that the field itself disappears. In other instances where I see this bug "in the wild", every field between down to the last field above the submit buttons all disappear, including the field itself.

I can reproduce the disappearing fields by clearing the cache (through truncating every cache table). However, the bug I see when clearing the cache is that the field itself disappears. In other instances where I see this bug "in the wild", every field between down to the last field above the submit buttons all disappear, including the field itself.

I was incorrect here. Removing all subsequent fields was an old bug that I must have confused this bug with.

I was able to reproduce this in production by opening up the node edit form, waiting for quite awhile (presumably for a different user to trigger a different action), and then clicking the add-another-field button.

I suppose the next step is to discover all actions that will clear the cache?

In our case it's authcache clearing it's cache on cron. :/

It seems this issue should be reported to these cache related modules?

I believe there's little CCK can do here. Caching the form is necessary for the add more items button to work properly.

I'm setting this issue to won't fix because it's not a CCK bug. It's a problem related to caching systems, and I opened a ticket for it #512026: Move $form_state storage from cache to new state/key-value system

If a cache module messes with cache_form table, that's a serious bug in the module. cache_form is not a cache bin like the others. You cannot rebuild the info you flush out. In this sense, it's not really a 'cache' and is famously mis-named :-)

I believe I've resolved this in Authcache beta7. If anyone is using Cache Router (which Authcache uses), here is more info on the fix: #266588: Obey "expire" value on cache_clear_all(), like Drupal core

subscribe

I'm also having this issue using cck 2.8 + cacherouter dev (with apc) + authcache. However, it works again when disabling cacherouter and authcache.
I'm a little confused since I try it with user 1 which doesn't get cached pages.

Every advice is very appreciated, thanks!

haggins, have you tried using CacheRouter RC1?

yes, first I was using CacheRouter RC1 and updated to dev later.

I'm wondering where you made the changes you suggested here: #266588: Obey "expire" value on cache_clear_all(), like Drupal core (#3)?

Those changes are part of the CacheRouter APC engine (apc.php).

Thanks Jonah! Sadly it doesn't solve the problem. It looks as it's not possible to use Authcache + CCK in my case.

I have this problem sometimes - especially when multiple users are logged into edit pages.

For me it happens with no caching mechanism (no drupal core caching and no other caching)

to reproduce
put a cck textarea with unlimited values on page content type with WYSIWYG tinymce editor
go to create new page
fill in the first two textareas and then press ADD ANOTHER ITEM
the new textarea is presented but other two are empty now

GiorgosK, try this: tinymce ahah module

thanks haggins
had to actually install
http://drupal.org/project/wysiwygcck and problem goes away

I am getting this when autcache is enabled.
it is a little frustrating.

i am having the same problem.
I could explain it in my case.
i have two cck fields(unlimited).
one having a background(background image added for a particular field by an external css.) and another does not have a bg.
When i click add another item in the field which don't have a background
The field disappears.
But it is not the case with the other one.
The field which do have a background does not making the field disappears but another field is not adding.

Closing again. Please read the thread, visit the correct issues, and post new issues in the right module queues if you still have a problem.

Just wanted to post this quick in case it helped someone else. I was chasing down this issue and then finally figured out that I was seeing this issue because of a JavaScript issue on the page. In my particular instance, I have a Facebook block on my site. When I've switched over to one of my "pages" profiles I get JS errors like the following on the page:

Unsafe JavaScript attempt to access frame with URL http://[mysite].com/node/13769/edit from frame with URL http://www.facebook.com/login/plugin_roadblock.php?target_url=http%3A%2F.... Domains, protocols and ports must match.

Long story short, if I switched back to my profile on Facebook these errors went away and the "Add another item" button started working again. I'm sure it's not directly related to this specific error and is likely the result of a JS error occurring on the page and interfering with the form somehow. So, if you're seeing this issue fire up your browser JS console and clean those first.

I had the same issue and when I turned my cache OFF it worked fine, then I turned it back to ON and set Min Cache Lifetime to and that fixed the issue.

My site also has the same issue. I've boost and memcache installed. But even when I turned both of them off, the problem was still there.

OK, I was wrong. Turning off AND REMOVING memcache setting from settings.php DO fix the problem. So it is a cache problem.

If you are using last dev version of Memcache API and Integration, you can use setting like:

$conf = array(
  ...
  'memcache_servers' => array('10.0.0.1:11211' => 'default'),
  'memcache_bins' => array('cache' => 'default',
                           'cache_form' => 'database'),
);

to bypass cache_form from being cached by memcache.