Ok, I'm not sure if this is just my problem or not since I haven't seen other issues relating to this one. The problem I've been having for a while is that on my custom content types having CCK fields the field data appears to not be saved when I first create a node. Then I have to go in and edit the node and resave it for the data to show up.

I decided to debug this after getting frustrated for a while and found even more frustration when Drupal.org was down yesterday evening. Made it very hard to search for similar problems. ; )

What it came down to was a matter of caching data for CCK fields. Here's the order of execution for the node creation process:

  1. I click create content and select my custom node type.
  2. I fill in all the fields, custom ones included, and hit submit.
  3. Drupal, in submitting the form, first invokes hook_submit in content.module.
  4. Drupal then invokes hook_load to grab the node details. This in turn invokes the content field function to load the current data... but because no INSERTs have been made in the DB yet, this loads up nothing. But here it caches the results, which are empty arrays.
  5. Now, Drupal invokes hook_insert using the form data, so the content field data is actually getting saved to the DB.
  6. Then when displaying, Drupal invokes hook_load again to display the results... BUT because the data was cached before the field data was actually saved to the database, my nodes are showing up as empty.

So, what I found out is that the data is actually being saved, but it's getting cached before it's being saved. So subsequent loads appear to have disregarded the initial save.

Now, about the fix. Looking at hook_insert in content.module, I saw where cache_clear_all is used to remove the cached data. This is why editing and reentering the data appears to save it for the first time. The initial empty cache is deleted and the fields are saved as expected.

What I have done is copy the call to cache_clear_all to the function content_insert so the cache is also emptied when the node is first saved. This solves the problem of empty data being cached until the next update.

function content_insert(&$node) {
  _content_field_invoke('insert', $node);
  _content_field_invoke_default('insert', $node);
  cache_clear_all('content:'. $node->nid .':'. $node->vid, 'cache_content');
}

What I'm curious is if this is an issue for anyone else? (I ask this because I couldn't duplicate the issue on a second test site.) And also why wasn't cache_clear_all being used in content_insert already?

Comments

yched’s picture

yched commented
Status: Active » Closed (won't fix)

I can't reproduce the behaviour you're experiencing. It's most probably a conflict with some other module you are using on your site.

Off the top of my head, I'd say the strange part is :
- hook_submit
- hook_load
- hook_insert

I do not see why hook_load would be called at that point. AFAIK, this is not drupal's standard behaviour.
There might be an himplementation of hook_nodeapi 'submit' or 'insert' op in some module that triggers a node load.
I incline for 'insert', since new nodes do not have any nid before that, and thus there is nothing to call node_load with...
A node_load in 'insert' definitely seems like a strange thing to do.

Anyway, closing this as 'won't fix'...

rszrama’s picture

rszrama commented

No problem, thanks for the follow-up. I figured it was probably a module conflict but wanted to be sure. ; )

amariotti’s picture

amariotti commented
Version: 5.x-1.5 » 5.x-1.7

Have you been able to figure out where the module conflict was coming from? I'm having the same issue and it's really killin' me here.

mrcalc’s picture

mrcalc commented

I have also experienced this problem, and the solution of adding a call to cache_clear_all fixes the problem, but as yched has implied, this is the wrong place to fix it.

Some more investigation shows that on my 5.10 installation, the Remove non-viewable menu items module is causing the problem.

It seems that in the function remove_nonviewable_menu_items_menu, the module uses node_load, which is causing the cck fields to be lost when the cache is generated for the newly submitted node. The cck fields haven't been stored yet when this call happens, so the node is cached without the extra cck field data.

The only solution I have found is to disable the Remove non-viewable menu items module.
It seems like this could be fixed by changing the weight of the Remove non-viewable menu items module, but I have tried this without any success.

amariotti’s picture

amariotti commented

I do have that same module loaded. It's good to know where the problem is coming from. Probably should submit an issue to that module...

yonailo’s picture

yonailo commented

I've been experiencing the same behaviour. As we are using a lot of contributing modules and a great deal of custom hacks, I don't
have interest in trying to figure out where the bad behaviour is coming from.

I will give a try to the patch rszrama is proposing.

Thanks.

Chris Gillis’s picture

Chris Gillis commented

I also have this issue on Drupal 6.22.
I am not using the Remove non-viewable menu items module.
Like #6 I have a lot of modules and a massive custom module specific for this site. I have been hunting this bug for three days, and finally decided, in my custom module, when I first node_load to just do this:

    $node = node_load($nid);
    cache_clear_all('content:'. $node->nid .':'. $node->vid, content_cache_tablename());
    $node = node_load($node->nid);